How expensive are customisations to the ERP standard over time?

A customisation costs its development once and its maintenance permanently. The running cost arises with every update, with every process change and with every error investigation in which the customisation has to be checked as well. As orientation: expect a noticeable share of the original development cost per year for maintenance and regression testing. Across the life of a system that adds up to a multiple of the offer price.

What happens to customisations during cloud updates: customisations and cloud updates

Why a system should grow with you: Never starting over

The three kinds of cost of a customisation

The first kind is development. It is in the offer, it is negotiable and therefore discussed most intensively, although over the years it makes up the smaller part.

The second is maintenance. Business Central receives a major update twice a year, plus ongoing corrections. Every customisation has to be checked with each one, and occasionally adjusted because its basis in the standard has changed. That effort arises as long as the customisation exists, whether or not it is used.

The third kind is the hidden one: customisations slow down everything that comes after. Every later extension has to take them into account, every error investigation has to consider them, and every new employee has to learn them, because they appear in no standard documentation. These costs appear nowhere and in total are often the largest.

Why customisations multiply

Customisations rarely come alone. There is a structural reason: detaching one process from the standard also detaches the adjacent processes to a degree. A special pricing rule affects quotation, order, delivery note and invoice. What begins as one customisation ends up touching four places.

There is also a psychological effect. Once the first exception has been approved in the project, the bar for the second drops. The reasoning is understandable every time, and in total a system emerges that nobody wants to update any more.

The countermeasure is not a ban but a procedure. Every customisation gets a named owner, a justification for why the standard is not enough, and an estimate of the annual follow-up cost. The obligation to state the follow-up cost alone noticeably reduces the number of requests.

When a customisation is right nevertheless

There are good reasons for customisations, and avoiding them is not an end in itself. The clearest reason is differentiation: if a process is the reason customers buy from you, it does not belong pressed into the standard. A configurator for products nobody else offers that way is a sensible investment.

The second good reason are legal or contractual requirements the standard does not cover, for example customer requirements in the supply chain. Here the customisation is not a choice but a precondition for doing business.

What matters is the construction. A customisation that sits cleanly beside the standard and connects through defined interfaces survives updates considerably better than one reaching into the standard. The extra effort during building pays off from the second update onwards.

How to get rid of legacy customisations

Most companies carry customisations nobody needs any more. They come from a time when the standard could do less, or from a process that no longer exists. Each one keeps costing maintenance.

One approach that works is an annual review with three questions per customisation: is it used, and how often? Does the standard now cover it? What would happen if we switched it off? Usage can be measured, the second question is answered by a look at the release notes, and the third by a conversation with the business area.

Experience shows that a first such review lets you switch off or replace a notable share of customisations with standard functions. That not only lowers maintenance cost, it speeds up every future update.