What happens to your customisations in an update?

If your Business Central has its own customisations, it is natural to ask whether they survive an update. The answer is usually yes, but only if the code is kept up to date. Customisations in the online version are extensions, and Microsoft tests them for technical compatibility. The article explains what can go wrong and what you need to watch yourself. It is also a checklist for the conversation with your partner.

Extensions and responsibility

In Business Central online you do not customise the base code itself. Customisations are built as extensions on top of the standard product. Per-tenant extensions belong only to your environment, and apps from AppSource are for everyone. Because the standard product is not modified, Microsoft can update it without overwriting your work.

Microsoft Learn says that the publisher of an app or per-tenant extension is responsible for keeping the code up to date after every major and minor update. When a per-tenant extension is installed, the publisher accepts to keep it update-ready.

As a customer you should therefore know who the publisher of each extension is, and have an agreement on maintenance. Without one, you are on your own when an update fails.

Warnings and deprecated methods

According to Microsoft Learn, Microsoft communicates upcoming breaking changes at least a year in advance. The AL compiler warns about functions that are becoming obsolete, and analysers such as AppSourceCop can find problems before the update arrives.

Before a major update, Microsoft tests per-tenant extensions in existing environments for technical compatibility with the upcoming version. Findings are sent by email to the notification recipients in the admin center. Read them, and pass them on to your developer.

If an update fails

If an update fails because of a customisation, the environment returns to the old version, and a new attempt is scheduled seven days later. After the regular update period and a grace period, Microsoft can uninstall an extension that blocks the update, so that the update can succeed. The extension's data is not deleted, but the functionality disappears until a compatible version is installed.

Make updates a routine rather than an event.

Make a list of all extensions, publishers and the people responsible.
Test every major update in a sandbox, preferably on the preview about a month before release.
Make sure notification recipients are up to date.
Upload the new version of a per-tenant extension with installation at the next major update.
Remove extensions you do not use.
Consider whether standard functionality can now replace an old customisation.

What you can ask

Ask your partner how each customisation is built, whether it follows recommended practice and whether it uses functions marked as being phased out. Ask to be told when it was last tested against a new version and who has access to the source code.

The source code of a per-tenant extension should be kept somewhere you have access to, so that you are not dependent on a single supplier.

AppSource apps and unnecessary customisations

Apps from AppSource are updated by their publisher. If an app is incompatible with the latest version, it can be removed from AppSource, and customers may be notified. Check your supplier's plan for updates before you choose an app.

Some customisations were made because the standard product could not do something. Since then the standard product has often improved. Read the release plans, and ask whether a customisation can be replaced by standard functionality.

Fewer customisations mean fewer risks at updates, lower maintenance and less to explain to new employees.

Help with your customisations

Addverk is a new Business Central partner. We can review your extensions and plan how they are kept up to date. See our upgrade service and the prices page.