Blog
AL extensions vs modifying the base app: the upgrade-safe way to customise
The single most expensive mistake of the NAV era was editing the base application directly. It felt efficient at the time and quietly mortgaged the future. Business Central’s extension model exists to make that mistake impossible, and understanding why is worth ten minutes of anyone’s time.
How the old approach trapped customers
In classic NAV, customising meant opening a standard object in C/AL and changing its code in place. Your logic and Microsoft’s logic became one tangled file. That worked until the next version arrived, at which point every modified object had to be manually merged against Microsoft’s new code, line by line, conflict by conflict.
The more you customised, the harder and riskier every upgrade became. Many organisations simply stopped upgrading. They froze on an old version, missed years of features and fixes, and eventually faced a far larger migration than if they had stayed current. The customisation that saved a week in year one cost a quarter in year five. We still meet these systems today; unwinding them is a large part of our upgrade work.
How AL extensions keep you safe
Business Central does not let you edit the base app. Instead, your code lives in a separate extension that sits alongside Microsoft’s, never inside it. You add fields, pages and logic in your own objects, and you hook into standard behaviour through event subscribers rather than rewriting it.
codeunit 50100 "Sales Header Subscriber"
{
[EventSubscriber(ObjectType::Table, Database::"Sales Header", OnAfterValidateEvent, "Sell-to Customer No.", false, false)]
local procedure OnAfterValidateSellToCustomer(var Rec: Record "Sales Header")
begin
Rec.Validate("Shortcut Dimension 1 Code", GetDefaultDepartment(Rec."Sell-to Customer No."));
end;
}Microsoft publishes the event; you subscribe to it. Your code runs at the right moment without touching a single line of the base object. When Microsoft ships a new version of that object, your subscriber is unaffected because it was never woven in.
The boundary between your code and Microsoft’s is now hard and visible. Upgrades stop being merge marathons and become a matter of confirming your extension still compiles and behaves against the new base.
What this means for the twice-yearly updates
Business Central ships two major updates a year, and in SaaS they arrive automatically. With base modifications that cadence would be unmanageable. With extensions it is routine: you test your app against the upcoming release in a sandbox, fix anything the platform flags, and move on. You stay current by default, and the gap between your version and the latest never grows into a migration.
Standard first, custom second
The extension model rewards a discipline we apply on every engagement: reach for standard functionality before writing code. Each release, Business Central absorbs more of what used to require customisation: approvals, document email, bank imports, and more.
The cheapest extension is the one you never wrote. Every requirement met by configuration instead of code is something you do not build, do not test, and do not carry through future updates.
The long-term cost picture
Extensions cost a little more discipline up front, because you design around events and published interfaces rather than editing whatever is convenient. The payoff compounds:
- Upgrades become predictable, low-risk and frequent
- Customisations are isolated, testable and easy to hand over
- You can adopt new standard features without unwinding old code
The real cost of a system is not what you pay to build it but what you pay to live with it for a decade. The upgrade-safe approach keeps that long tail small, and the long tail is where most ERP money goes.
Carrying legacy modifications, or planning new customisations? Tell us your story and we will show you how to build them upgrade-safe.