Skip to content
Dynamics Development logo
← All insights

6 November 2025 · 6 min read

Per-tenant extensions vs. old-school customisations: keeping Business Central upgradeable

  • Development
  • AL extensions
  • Best practice

NAV earned its reputation for painful upgrades honestly: every customisation was a modification of Microsoft's own objects, so every upgrade meant merging your code with theirs. Business Central's extension model ends that — but only if extensions are built the way the model intends.

What a per-tenant extension actually is

A per-tenant extension (PTE) is a private AL app installed in your Business Central environment: your fields, pages, reports and business logic packaged separately from the base application. Microsoft updates the platform underneath twice a year; your extension stays untouched and simply recompiles against the new version.

The alternative for productised functionality is an AppSource app — the same technology with stricter validation, relevant for ISVs shipping the same solution to many customers.

The rules that keep you upgrade-proof

  • No base-app modifications — extend tables and pages, never copy-and-alter standard objects.
  • Attach logic through events and interfaces rather than rewriting standard flows.
  • Keep analyzers on: PerTenantExtensionCop and CodeCop warnings are early upgrade warnings, not noise.
  • Follow Universal Code requirements so the same app runs in the cloud — even if today you are on-premises.
  • Version and release through source control and pipelines, not by editing in production.

Why release waves make this non-optional

Business Central online receives two major release waves per year, plus monthly updates. Microsoft deprecates methods with notice, and the compiler tells you exactly where. A clean extension absorbs a release wave in hours of checking; a rule-bending one turns every wave into a mini upgrade project.

This is the quiet economic argument for doing extensions properly: the cost difference is invisible at delivery and very visible eighteen months later.

Governance for end customers

If external developers or multiple vendors touch your environment, put three things in writing: all custom work is delivered as extension source code you own, all changes flow through a repository and pipeline you can access, and each release wave includes a compatibility check of installed extensions.

That single page of governance is the difference between owning your system and renting your own customisations back from whoever built them.

When you still have old-style customisations

Organisations on NAV or older BC on-premises versions with baked-in customisations are one C/AL-to-AL conversion away from this model. The conversion is an investment — but it is the last upgrade of the old kind you will ever do.

Have a Business Central or NAV project on your roadmap?

Send a short description of what you need. You will receive a considered reply — and, where possible, a fixed-price estimate — within one business day.