In short
Customising refers to adapting off-the-shelf software to a company's processes without changing its program code: through configuration, parameterisation, extension points and add-on modules that survive an update of the base system.
In everyday use the term is applied generously, and that is precisely the cause of many expensive projects. "We only adapted the system a little" can mean that someone ticked a box in a configuration screen. It can also mean that someone rewrote the core of the software and thereby turned every future update into a project. Orders of magnitude of follow-up costs lie between these two cases.
The three levels: configuration, extension, modification
Anyone deciding on customising should always first clarify which level they are working on. The levels do not differ in the result for the user but in the price you pay years later.
Level 1: configuration within the standard
Everything that the software itself offers as a setting: company codes, number ranges, roles and permissions, tax codes, workflows, mandatory fields, document templates, pricing procedures. This is the route intended by the vendor, and it is update-proof because these settings are stored as data and not as code.
SAP has formalised this level most visibly: via the implementation guide, which is opened with transaction SPRO, a system is adapted to the organisation in thousands of individual settings, and in the SAP world the term customising refers to precisely this activity. Some of the settings are client-specific and some cross-client, and they move from the development system into the production system via the transport system. This is not a detail for administrators but the reason why SAP implementations drag on for months without a single line of code being written.
Level 2: extension via defined interfaces
What configuration cannot provide can be added in well-built systems via designated extension points: plugins, apps, events, hooks, custom fields, replaced services. The vendor undertakes to keep these points stable, and you are working within a documented contract.
Shopware 6 is a good example of this way of thinking. Adaptations are made via plugins or the app system, with services being decorated and events subscribed to instead of core files being edited. Microsoft took the same step for Dynamics 365 Business Central and replaced the former direct code adaptation with an extension model. The common idea: the adaptation sits next to the standard, not inside it.
Level 3: modification of the core
Here, shipped code is changed. This always works, which is why it is so tempting, and it creates a liability that hardly anyone factors in when deciding: every update has to incorporate the change again or is postponed. After two postponed major updates, a system is effectively frozen, and the purchased off-the-shelf software has become an organically grown in-house build for which nobody has maintenance contracts.
| Level | Means | Upgradability | Who does it |
|---|---|---|---|
| Configuration | Settings, parameters, rule sets within the standard | high, intended by the vendor | Business department, key users, consultants |
| Extension | Plugin, app, event, custom field, decorated service | good, as long as the interface remains stable | Development with vendor documentation |
| Modification | Change to shipped code | poor, rework with every update | Development, often under time pressure |
| Process adaptation | Your own process follows the standard | complete, nothing is adapted | Organisation |
The fourth row is missing from most project plans, even though it is often the most economical. Not every deviation between the standard and the process as it is lived is a competitive advantage. Some are merely habits that formed around a limitation of the previous system.
Why customising shifts the total costs
The licence price of off-the-shelf software is the figure that gets negotiated. The customising share is the figure that determines the project. In implementation projects for merchandise management and ERP systems, the effort for consulting, configuration, data migration, training and adaptation regularly exceeds the licence costs several times over. This is no scandal but the nature of the matter: you buy a foundation and pay for it to fit a specific house.
It becomes relevant where customising creates lasting obligations. Every extension is code that has to be maintained, tested and checked during updates. Every modification is a brake on future releases. Both end up in the total cost of ownership, and neither stands out in the first round of quotes because they only become visible from year two. Anyone who commissions customising without an operating concept buys into technical debt that they never booked.
The hidden item: testing
Every adaptation changes the behaviour of a system that the vendor has not tested with this adaptation. Part of the quality assurance therefore moves to the user company. Anyone with five extensions in use needs a list of the processes that must demonstrably work after every update: creating an order, generating an invoice, posting a payment, transferring via an interface. Without this list, every update becomes a spot check, and errors are noticed in day-to-day business instead of during preparation. The effort for this is manageable if it is planned in with the first customising, and unpleasant if it has to be made up for after the first incident.
When customising tips over
There is a usable heuristic for the decision that works without a spreadsheet. Check how much of the real process an off-the-shelf product covers without intervention:
- Well over four fifths covered: buy, configure, close the rest through process adaptation. The gap is smaller than the cost of eliminating it.
- Between half and four fifths: keep the standard as the core, close the gap via extensions, do not touch the core. This is the classic hybrid case.
- Under half: the product does not fit. Anyone who takes it anyway and then rebuilds it completely pays for the licence and custom development at the same time and gets the disadvantages of both worlds.
The hard version of this rule is: if customising becomes more expensive than targeted custom software for the process concerned, the product selection was wrong, and no further budget will correct that. This is exactly the point at which the make-or-buy decision belongs back on the table, instead of continuing to tinker with the standard.
A practical example: the one field that costs everything
A pattern that repeats itself in implementation projects: a company needs an additional field in the ordering process, such as an internal project number that is to be carried along on the document, delivery note and invoice. Level 1 checks whether the system offers free additional fields, which is usually the case with ERP systems and shops. Level 2 adds a small extension that carries the field over into the document print templates and the interface to accounting.
Level 3 looks different: because the standard printout does not show the field in the desired place, the shipped template is edited directly. With the next update, the vendor's version comes back, the field disappears, someone builds it in again, this time faster and without documentation. After three rounds, nobody knows any more which changes were deliberate and which were repairs. The effort for the field was never the problem; the problem was the level chosen.
Governance: documenting and limiting customising
Customising is less a technical than an organisational discipline. Four rules do most of the work:
- Every adaptation gets a business justification. Anyone who cannot write it down in two sentences probably does not need it.
- The level is decided explicitly. Configuration, extension or modification is a decision with cost consequences, not an implementation detail for development.
- Modifications need approval and an expiry date. If they are unavoidable, this includes the question of when they will be replaced by an extension.
- Before every update, the inventory of adaptations is checked. An up-to-date list of what deviates from the standard is the difference between an update and a project.
In larger landscapes, separation is also worthwhile: adaptations that affect only one process run as a separate module next to the standard and talk to it via an API. This keeps the standard clean and makes your own share replaceable. The Wikipedia entry on customising (in German) also provides a compact definition of the term.
A simple language rule in the project is also helpful: whoever says "adaptation" names the level as well. That sounds pedantic and prevents the most common wrong decision of all, namely a modification that nobody decided on as such.
Distinction from neighbouring terms
Configuration is the harmless subset of customising. Parameterisation means the same thing in a more technical tone. Custom development builds where nothing suitable exists, and is not an intensified form of customising but a different decision. And the widespread equation of customising with modification is precisely the language error that makes projects expensive, because it obscures the level at which work is being done.
Frequently asked questions
Is customising the same as custom software?
No. Customising adapts a third-party product whose further development lies with the vendor. Custom software is created for a specific process and belongs to the client. In practice the boundary only blurs because heavily modified off-the-shelf software at some point has to be maintained like an in-house build without having its advantages.
How much customising is too much?
A reliable indicator is not the amount but upgradability. As long as an update runs through without rework on the inventory of adaptations, the limit has not been exceeded. As soon as updates are postponed because of your own interventions, it has, even with just a single modification.
Who should be responsible for customising?
On the business side the process owner, on the technical side development or the implementation partner. What matters is a named person who knows every deviation from the standard and maintains the list. Without this role, an inventory of adaptations accumulates over the years that nobody can keep track of any more.
What does update-proof customising mean?
That adaptations are made exclusively via means that the vendor has provided for this purpose: settings, extension points, plugins, apps. Shipped code remains untouched. This is not a question of style but the condition for security updates and new versions remaining installable without a project.
Does this also apply to SaaS?
In principle yes, only with narrower limits. With a rented solution, level 3 is usually eliminated completely because nobody has access to the shipped code. What remains is configuration and the extension points that the provider releases, often tiered by plan. This looks like a restriction and is usually an advantage: the temptation to modify disappears. The price for this lies elsewhere. What the provider does not provide for is not negotiable, and the question of the missing extension point therefore belongs in the selection and not in the implementation.