Most Business Central Customizations Should Never Have Been Written
Most Business Central customization requests should be answered with a configuration change, a profile edit, or a conversation — not with AL code. The test is not whether the requirement is real, because it almost always is. The test is whether the difference it describes is a reason the business wins, because everything else you write becomes a standing obligation you renew twice a year, for as long as the code lives.
This is not an argument against custom development. We have built one of our largest AL applications precisely because no standard ERP could model what the business does. We have also delivered Business Central with effectively no custom code at all, because the standard served the business perfectly. The difference between those two projects was never scale or budget. It was whether anybody was willing to challenge the request before it became a ticket.
What actually counts as a customization in Business Central?
Far less than most people assume — and this is where the money leaks first. Business Central offers four distinct layers of change, and only the last one is code.
Personalization is per-user. Any user can open a page, enter personalization mode, and move, hide, freeze or add fields. It affects nobody else and it costs nothing.
Profile (role) customization is per-role and belongs to an administrator. It applies to every user assigned to that role, and it does something personalization cannot: it can surface fields that exist in the page’s source table or in extension tables but were never defined on the page object. That single capability answers a large share of the requests that arrive worded as “we need this field added to the sales order page.”
Designer is the browser-based drag-and-drop tool. It requires no code from you, but it is worth being precise about what it does: every time you start designing, you are effectively creating a new extension. The AL source it produces is downloadable, and the result is deployed like any other app. Designer is not a way to avoid the extension model — it is a friendlier way to enter it.
AL extensions are the fourth layer, and the only one that creates a permanent maintenance obligation. Everything above it is configuration you can undo on a Tuesday afternoon.
One constraint applies to all of it: you cannot customize a production environment directly. Changes are built and tested in a sandbox, then deployed as an app. There is no supported path where somebody quietly adjusts live code because a director asked nicely.
Which requests should never become code?
Four patterns account for most of the customizations we find and remove during a rescue.
Cosmetic and layout requests. “This field should be higher up,” “we never use these three columns,” “our buyers want a different order center.” All of it is personalization or profile customization. None of it is code.
Reports that are really views. A request for a custom report is very often a request for a filtered, grouped list somebody could save themselves. A custom report object has to be maintained; a saved view does not.
Fields that already exist under another name. Business Central models more than most implementations use. A “custom priority flag” is frequently a standard field nobody was shown during training. The fastest fix is not development but a session with the people who use the page daily.
Processes preserved out of habit. This is the expensive one. A company asks for code that reproduces the exact sequence of steps its previous system imposed — often a sequence that system imposed for reasons that no longer exist. Building that faithfully is how a fresh ERP inherits a decade of somebody else’s constraints on day one. If a process cannot be explained in plain language without referring to the old software, it is not a requirement yet.
What is the one test that decides?
Ask whether the difference is a reason the business wins.
Standard functionality exists because thousands of companies do something roughly the same way. If your company does that thing the same way too, doing it in standard is not a compromise — it is a free upgrade path forever. Custom code is justified when the difference is structural: a regulatory obligation nobody else carries, a physical or measurement reality the standard data model has no concept of, or a way of operating that is genuinely why customers choose you.
That is the line we hold, and it cuts both ways. One of the largest applications we have built covers a bulk-materials supply chain where deliveries are priced from laboratory measurements — moisture readings converted into calorific value and then into energy units — and where sustainability certification has to follow every load, contract and settlement. No standard ERP models that, and no configuration gets you there. It updates cleanly and stays maintainable, because the decision to build it was deliberate rather than accumulated.
The same discipline produced the opposite result on other programmes: a Business Central deployment with almost no custom code, because the standard genuinely fit. If your Business Central development partner never comes back with “we should not build this,” you are not buying engineering judgment. You are buying capacity.
What does a customization actually cost after go-live?
The build price is the smallest number in the equation, and nobody quotes the rest.
Business Central online ships two major updates a year, in April and October, with minor updates in the months between. Every extension you own has to keep working across that rhythm. When a major update becomes generally available, administrators get a five-month update period to schedule it. Then a one-month grace period — September for the April wave, March for the October wave — during which the update can no longer be pushed back. After that, the enforced update period begins, and any extension that is making the update fail may be uninstalled automatically so the environment can update. The extension’s data is not deleted and can be recovered by installing a compatible version, but until somebody does that, the code is simply not running and the data it was supposed to capture is not being captured. Where an incompatible extension blocks a critical security update, that window is much shorter: it may be uninstalled within 14 days.
Two details matter for honest budgeting. Microsoft communicates breaking changes at least a year in advance, so this is a planning problem, not an ambush. And Microsoft’s compatibility testing before a major release is technical — it checks that your code still compiles and installs against the new version. Functional and logical validation stays with whoever published the extension. Custom code can pass every automated check and still be quietly wrong after an update, in ways only the business will notice, usually at month-end.
The honest price of a customization is not the development quote. It is that quote plus a recurring obligation to test, adjust and re-deploy, twice a year, for the life of the system. Ten small customizations nobody challenged do not cost ten small amounts. They cost a standing commitment that has to be paid every wave, whether or not anyone budgeted for it. This is one of the most common root causes we find when a Business Central project has quietly stopped working — not one catastrophic decision, but dozens of reasonable ones.
Why do integrators keep saying yes?
Because saying yes is billable and challenging is not.
There is no conspiracy in this, just an incentive that points one way. A customization request arrives, it is specified, quoted, built, invoiced, and it generates maintenance revenue afterwards. Pushing back costs a difficult meeting, delays the signature, and reduces the scope of the work. An integrator who does it consistently is choosing a smaller invoice on purpose.
We think the division of labour is the other way around. The client’s job is to express a need clearly, in plain words, without jargon and without pre-writing the solution. Our job is to challenge that need — to clarify it, sharpen it, and shape it — before anyone opens a code editor. A client who arrives with a specification of what to build has usually skipped the only step that determines whether it should exist. When you evaluate partners, the useful question is not “can you build this?” It is “when did you last talk a client out of something?”
What do you do with a system that is already full of custom code?
You inventory it before you touch it, and you sort it into four buckets.
What is actually used — telemetry and a week of observation will tell you, and the answer is routinely a fraction of what exists. What duplicates standard functionality that has since caught up, because Business Central absorbs capabilities every wave and yesterday’s justified customization can become today’s redundant one. What is genuinely structural and should stay. And what was never justified but now holds data, which is the hard category: it cannot simply be deleted, it has to be migrated back into standard.
Retiring code is slower than writing it and nobody gets credit for it, which is exactly why it does not happen on its own. It is also the single most effective thing you can do to reduce the cost of the next two upgrades. Where an off-the-shelf app can replace something you maintain yourself, take that trade — some of the AL extensions worth knowing exist precisely to delete a category of custom code from your estate.
The Asio Services way
We do not treat “no custom code” as a badge. We treat every line as something that has to earn its place and keep earning it twice a year. Sometimes that means building a large, purpose-built application because the business genuinely operates in a way no standard product models. More often it means a configuration change, a training session, or a conversation that ends with the request being withdrawn — because it was a real frustration with an unreal solution.
If you are weighing a list of customizations, or you are living with a system that already carries too many, start with our clarity form. Clarity before code is not a slogan here; it is the order the work has to happen in.
FAQ
Is customizing Business Central a bad idea?
No. Customizing without a test for whether it should exist is the bad idea. Business Central’s extension model is designed to let you add functionality safely — the risk is not the mechanism, it is the absence of any filter on what goes through it.
How do I know if a request needs code or configuration?
Work up the layers before you cost anything: can a user do it with personalization, can an administrator do it as a profile customization, can it be done in Designer, and only then does it need AL. A surprising share of requests worded as development stop at the second question.
How often do Business Central customizations need maintenance?
At minimum twice a year, on the April and October major updates. An extension that blocks a major update can be uninstalled automatically once the enforced update period begins, and within 14 days if it is blocking a critical security update.
Does Microsoft test my customizations before an update?
Only technically. Microsoft checks compatibility so the update can proceed, but functional and logical validation remains the responsibility of whoever published the extension. Code that installs cleanly can still behave incorrectly.
Can we remove customizations we no longer need?
Yes, and it is usually worth it — but not by simple deletion. Anything holding data has to have that data migrated back into standard first. Start by measuring what is actually used, which is generally much less than what exists.