Business Central online updates itself. Microsoft ships two major releases a year, in spring and autumn, and smaller updates most months in between. For a standard system that is good news: new features and fixes arrive without an upgrade project. For a system with custom extensions, each update is a moment when something you rely on might stop working.
It does not have to be. Most extensions that break during an update break for a small number of predictable reasons, and each one can be designed out. This is how we build and look after Business Central extensions so updates stay routine.
Why extensions break
When an extension fails after an update, the cause is usually one of these:
- It used something Microsoft has since removed. Microsoft marks objects, fields, events and procedures as obsolete before removing them. An extension that ignored those warnings fails when the removal finally arrives.
- It depended on how standard code happens to behave, rather than on a published event or interface. When Microsoft refactors that code, the behaviour changes.
- It was never tested against the new version before the update reached production.
- Data changes were not handled. A new version of the extension changed a table but had no upgrade code, so existing data no longer fits.
- Another extension changed. An app from AppSource that your extension depends on was updated, and its behaviour moved.
1. Build on events and public interfaces only
In Business Central you cannot change Microsoft’s code; you extend it. The safe way to do that is through published events and procedures that Microsoft intends partners to use. We avoid copying standard logic into the extension, avoid relying on the order in which standard code happens to run, and avoid procedures marked internal. If something genuinely cannot be done through an event, we raise it with Microsoft as an event request rather than building a fragile workaround. It takes longer, but it lasts.
2. Treat obsolete warnings as work, not noise
When Microsoft plans to remove something, the compiler starts showing a warning, usually about a year before the removal. That year is the window to fix it calmly. We compile every extension against the latest version regularly, keep the list of obsolete warnings at zero, and fix new ones as part of normal maintenance, not on the night an update fails.
The code analysers that come with the AL tools (such as CodeCop and the per-tenant extension rules) catch many of these problems automatically, so they run on every build.
3. Test against the next release before it arrives
Microsoft makes the next major version available in preview sandboxes before it is released. That is the most valuable month in the extension’s life. We create a preview sandbox, install the extensions, and run the automated tests and the key business scenarios on it. Problems found here are fixed and released before your production environment is updated.
In the Business Central admin centre you can also choose the update window for production, within the period Microsoft allows. Pick a quiet time for the business, and make sure someone is watching on the day.
4. Automated tests for what matters
Business Central has its own test framework, and AL tests can run automatically in a build pipeline. We do not aim to test every line. We test the processes that would cost money if they broke: posting, pricing, integrations, approvals, anything that touches the ledger. Those tests run on every change to the extension and against every preview of a new version.
5. Handle data changes with upgrade code
When a new version of an extension changes its data, for example a field is split in two or a new table replaces an old one, it needs upgrade code that moves the existing data across when the new version is installed. Without it, the installation fails or, worse, succeeds with data in the wrong place. We write and test upgrade code for every change that touches stored data, on a copy of production data.
6. Keep extensions small and well defined
One large extension that does everything is hard to test and risky to update. Several smaller extensions, each with a clear purpose and clear dependencies between them, can be tested and released separately. The dependencies are declared with minimum versions in each extension’s manifest, so an incompatible combination cannot be installed by accident.
7. Know what is installed and who owns it
Many businesses we meet cannot say exactly which extensions are installed, which version, or where the source code is. That is the first thing to fix. For every per-tenant extension there should be source code in a repository the business controls, a version history, and a named person responsible for it. AppSource apps should be on a list with their publishers and support terms.
Signs your extensions need attention
- Updates are postponed for as long as possible because “something always breaks”.
- Nobody has the source code for an extension, or it is only on a former partner’s computer.
- The compiler shows dozens of obsolete warnings that nobody looks at.
- Testing an update means asking users to “try things” on the morning after.
None of these needs a reimplementation. An extension can usually be brought up to standard in stages: recover the source code, clear the warnings, add tests for the key processes, and set up a routine for each release.
We provide Dynamics 365 support, including extension reviews and testing against each Business Central release, and build new extensions as part of our Business Central services. If you are still on Dynamics NAV, see our article on planning an upgrade to Business Central.