What changed compared with older systems
Short answer: in Business Central, customisations do not modify the system. They live alongside it as extensions written in AL. That is why the two update waves Microsoft ships each year do not turn into a project.
In the previous generation of on-premises systems, a customisation edited the configuration itself. Every update meant a manual merge of changes. After a few years companies simply stopped updating, because the update cost more than it was worth. Extensions remove that trap.
They do not, however, make customisation free.
Why every customisation costs twice
The first cost is obvious — development. The second appears about six months later.
| Cost line | When it lands | What drives the amount |
|---|---|---|
| Development | Immediately | Logic complexity, number of processes touched |
| Testing | Immediately | How many scenarios need verifying |
| Update maintenance | Twice a year, forever | Number of extensions and depth of intervention |
| Rework | When processes change | How tightly the code is bound to one scenario |
The third line is the one nobody budgets. Microsoft ships two major releases a year, and every extension is verified against each. One small customisation is a few hours twice a year. Fifteen customisations is a standing cost comparable to support itself.
A question worth asking before signing. "What will it cost us to carry this extension through the next four update waves?" A partner who cannot answer has not thought past delivery.
When a customisation is genuinely warranted
Working rule: customise when the process is a competitive advantage and the standard does not cover it. Everything else is a reason to revisit the process, not to write code.
| Situation | Decision | Reasoning |
|---|---|---|
| The process is unique and makes money | Customise | It is your advantage; bending it to the standard destroys the point |
| A document layout required by a customer or regulator | Customise | Cheap, isolated, does not touch business logic |
| Integration with a bank, webshop or equipment | Usually warranted | Check AppSource first — a ready-made connector often exists |
| "We have always done it this way" | Revisit the process | Usually habit rather than requirement, and the standard may be better |
| Fields would be more convenient elsewhere | No code needed | Page personalisation is a configuration task |
| A report the standard does not produce | Often no code needed | Check financial reports, dimensions and Power BI first |
A healthy project covers 80–90% of processes with standard functionality. If customisations exceed that, the question is no longer about the customisations — it is whether the system was the right choice for these processes at all.
What a client should understand about the technical side
Not to write code, but to ask a partner the right questions.
- Extensions are isolated. One cannot break another, and none modify base objects.
- The code is readable. AL is an ordinary programming language; any competent team can pick up somebody else's extension.
- Development happens separately. A sandbox environment is distinct from production, so experiments never touch live data.
- Sandboxes are free. An idea can be tested without licence cost.
- Source code should be yours. This is contractual, not technical, and it is the single most important clause in a customisation agreement.
The key question to a partner: will we be able to hand this extension to another team without rewriting it? If the answer involves hesitation, you are buying dependency along with the feature.
How to reduce the cost of living with customisation
- Phase it. Go live on the standard, collect real complaints for two months, then customise what people actually hit. Half the pre-launch wish list evaporates.
- Check AppSource before commissioning. A published extension carries someone else's update maintenance rather than yours.
- Keep each extension narrow. Several small, single-purpose extensions survive updates better than one that touches everything.
- Document the why, not the what. Code explains what it does; only documentation explains which business rule made it necessary.
- Review annually. Processes change, and extensions written for a rule that no longer applies quietly keep costing money.
The pattern worth internalising: the cheapest customisation is the one you decided not to build after the process turned out to be habit. The second cheapest is the one that already exists on AppSource.
AL development is part of our implementation services.
Frequently asked questions
Do customisations break Business Central updates?
Not in the way they did in older systems. Extensions live separately from base objects, so updates do not require a manual merge. Each extension is still verified against every release, which is a recurring cost rather than a one-off risk.
How much does customisation cost?
Development is quoted per requirement, but the figure that matters is total cost over three years: development, testing, verification against two releases a year, and rework when processes change.
Can a project run with no customisation at all?
Often yes, for standard trading and service businesses. Document layouts and integrations are the two areas where some development is almost always needed.
How do we know we have too many customisations?
When standard functionality covers less than 80% of processes. At that point the question is whether the system fits the business, not whether the extensions are well written.
Do we need a developer in-house?
Not for most small and mid-sized companies. An in-house developer becomes worthwhile when extensions are numerous enough that waiting for a partner slows down operations.
Who owns the code of a custom extension?
Whoever the contract says. This is a commercial question rather than a technical one, and it determines whether you can move to another partner without rewriting everything.