What happens to our customisations with every cloud update?

Business Central receives a major update twice a year. Customisations that sit beside the standard as separate extensions generally keep running. Effort arises in three cases: when an extension uses a standard function that Microsoft changes, when a function you rebuilt moves into the standard, and when your extension is not maintained and therefore ages. The regular effort is testing, not repairing.

What customisations cost over the years: customisations to the standard over time

Who takes care after go-live: evolution after go-live

How updates work in Business Central

Microsoft delivers two major releases per year plus ongoing corrections. Cloud environments are updated automatically, with you influencing the timing within a window. Before the production run there is a preview phase in which you can test the update in a sandbox with your own data.

Technically, customisations are installed as extensions that sit beside the standard and connect at defined points. That is the decisive difference from earlier times, when code was changed directly in the standard and every update required a merge.

From this follows the normal case: the extension keeps running after the update, and your work consists of testing it. The exception is Microsoft changing a connection point you use. Such changes are announced in advance, which is exactly why it pays to look at the release plans.

The three cases where work genuinely arises

The first case is a changed foundation. If your extension uses a standard function that Microsoft rebuilds or deprecates, it has to follow. That is plannable, because deprecations are published with lead time, and in practice it affects few extensions per year.

The second case is the most pleasant and most often overlooked: a function you had to rebuild years ago is now part of the standard. In that case you should not maintain the extension but move to the standard. Anyone not checking pays permanently for something available for free.

The third case is lack of maintenance. An extension nobody has touched for years accumulates dependencies on old procedures. At some point the effort for a single update exceeds a rebuild. That is rarely an update problem and usually an operating model problem.

What to do before every update

The most effective protection is a short, always identical routine. First: review the release plan and check whether an announced change touches your extensions. Second: install the update in the sandbox and run through the critical business transactions, not just the extensions themselves.

Third: record the test cases so the routine gets faster next time. In practice it is usually between ten and thirty transactions that genuinely count: create an order, post a delivery, issue an invoice, allocate a payment, close the month, plus your specific workflows.

This routine costs a few person days per release and replaces uncertainty with a habit. Companies that have it experience updates as a date in the calendar. Companies without it experience them as a risk and postpone them, which makes the situation worse over time.

Why postponing is not an option

In the cloud updates can only be delayed to a limited extent, and on balance that is an advantage. Anyone suspending updates for years accumulates a backlog that eventually can only be worked off as a project. That is exactly how situations arise in which a technically current system suddenly needs a major migration after all.

The second reason is functional development. New capabilities, particularly around AI, arrive through the releases. Anyone not current does not take part in that development and thereby decides indirectly that their system stands still.

The third reason is security. Corrections arrive by the same route. A system kept old out of fear of updates is not more stable but more exposed.