Business Central Extensions and AL Development: Customizing Without Breaking Upgrades

For most of the history of enterprise resource planning, customization and upgradability were enemies. If you wanted the system to fit your business, you modified its code, and the moment you did, you had bought yourself a maintenance problem that never went away. Every vendor release forced a re-merge of your changes against theirs, a project in its own right, expensive and risky, and the fear of that project is the single biggest reason so many organisations ended up frozen on ancient, unsupported ERP versions. Microsoft Dynamics NAV, the product that became Business Central, lived that entire era. The move to the extension model was Microsoft deciding that the trade-off itself had to end, and once you understand how it works, you stop customizing the way you used to and start customizing in a way that survives.

The message up front: modern Business Central is never customized by editing the base application. It is customized through extensions, small apps written in a language called AL using Visual Studio Code, that add to and hook into the standard product without altering it. This one architectural decision is what makes the cloud version genuinely evergreen, upgrading itself on a schedule without breaking your tailoring. Grasp that and every other decision about how to change Business Central falls into place.

1. Why the extension model exists (the end of modified base code)

To understand why extensions matter, you have to feel the pain they were designed to remove. In the classic NAV world, a partner would take the standard product, open its objects in the development environment, and change them directly to meet a client's requirements. Add a field to the customer card here, tweak the posting routine there, rewrite a report to match a local statutory format. It worked, and it produced systems that fit their businesses beautifully. The catch arrived at upgrade time. Because your changes lived inside the same objects Microsoft shipped, every new version meant a code-merge exercise: take the old base, the new base, and your modified base, and reconcile three versions of thousands of objects by hand. That merge was slow, error prone, and genuinely dangerous, and it grew more expensive with every layer of customization a client had accumulated.

The consequence was predictable and corrosive. Upgrades became so costly that organisations simply stopped doing them. They sat on versions that were five, eight, ten years old, unsupported and insecure, because the business case for upgrading was always dominated by the cost of re-applying the customizations. The very thing that made the ERP valuable, the fact that it fit the business, was the thing that trapped it in the past. I have walked into more than one operation running a decade-old ERP that everyone knew was a liability, and in every case the reason was the same: the customizations were too deep in the base code to move.

The extension model exists to break that link permanently. The principle is simple to state and profound in its effect: your customizations must never touch Microsoft's code. Instead they sit alongside it as separate, self-contained apps that plug in through defined connection points. When Microsoft updates the base, your app is still your app, untouched, and it reconnects to the new base through the same connection points. There is no merge, because there is nothing to merge. Customization and upgradability stopped being enemies the day the base application became read-only.

2. What an extension is (an app that adds to, not alters, the base)

An extension is a packaged app. That is the whole idea, and it is worth holding onto because it reframes how you think about every change you make. When you add a field, a page, a report, a business rule or an entire module to Business Central, you are not editing the system, you are building and installing a small application that the system loads on top of itself. It is closer in spirit to installing an app on your phone than to modifying the operating system. The phone's core stays exactly as the manufacturer shipped it; your app adds capability without rewriting anything underneath.

Concretely, an extension can do a lot. It can add new tables to store data the standard product does not track. It can add fields to existing standard tables, so your customer records carry information Microsoft never anticipated. It can add new pages, or place additional controls onto existing standard pages. It can add reports, workflows, permission sets, and API endpoints. It can subscribe to events raised by the standard code and run its own logic in response. What it deliberately cannot do is reach into Microsoft's objects and rewrite them. The boundary is the point. An extension operates entirely through the surfaces the platform exposes for that purpose, which means the platform always knows exactly where your code connects and can keep those connections stable across versions.

This has a clarifying effect on architecture. Because everything you build is a discrete app, your customization has an identity: a name, a publisher, a version number, a set of dependencies, and a lifecycle of its own. You install it, you upgrade it, you uninstall it, all independently of the base product and of other extensions. A well-designed Business Central deployment is not a single monolithic customized system, it is the standard product plus a curated set of apps, each doing one coherent job. That modularity is not just tidy, it is what makes the whole thing maintainable at scale. For a fuller picture of how Business Central sits within the broader Microsoft platform it plugs into, see the Business Central and the Microsoft ecosystem pillar.

3. AL and the developer toolset (Visual Studio Code, the AL language)

Extensions are written in AL, the application language of Business Central, and the shift to AL was as significant as the shift to extensions themselves. In the NAV era, development happened inside a proprietary tool bundled with the product, editing objects in place. Modern AL development happens in Visual Studio Code, Microsoft's mainstream, free, cross-platform code editor, using an official AL extension that turns it into a full Business Central development environment. That change moved ERP development out of a niche, product-specific tool and into the same tooling ecosystem that professional software developers already use every day, and it brought all the habits of modern software engineering with it.

The practical picture for a developer looks like this. You install Visual Studio Code and the AL language extension. You point a project at a Business Central environment, a cloud sandbox or a local container, and the toolset downloads the symbols that describe the standard application, so the editor knows every object, field and event available to you. You write AL code with full editor support: syntax highlighting, autocomplete, inline error checking, and the ability to publish your app to the environment and see it run with a keystroke. The language itself is readable and purpose-built, with object types that map directly to the concepts of the product: tables, pages, reports, codeunits that hold business logic, and the extension variants that let you add to existing objects rather than replace them.

A tiny, illustrative flavour of what AL looks like when you add a field to a standard table through a table extension:

Notice the word that carries the whole philosophy: extends. The code does not open the Customer table and rewrite it. It declares a table extension that adds a field to the standard Customer table from the outside. Microsoft's table is untouched; your field rides alongside it. The same pattern applies to pages, where a page extension adds controls to a standard page, and to the rest of the object model. Because the development lives in Visual Studio Code, it also inherits the wider engineering toolchain: source control with Git, code review, branching, and automated build and release pipelines. ERP customization, for the first time, is managed like real software, and that is a large part of why the results are more durable.

4. Events and extensibility: how extensions hook into standard behavior

Adding fields and pages is the easy half. The harder and more interesting question is how your code participates in the standard product's behaviour without editing that behaviour. If you cannot modify the posting routine, how do you run your own logic when a document posts? The answer is events, and events are the mechanism that makes the whole extension model work for anything beyond cosmetic additions.

Microsoft's standard code is instrumented with a large number of published events. At meaningful moments in a process, before a sales document posts, after a customer record is inserted, when a specific validation runs, the standard code raises an event, effectively announcing "this is happening right now." Your extension can subscribe to that event with a piece of code called an event subscriber, and when the event fires, your logic runs. You get to participate in the standard process at defined, supported points, without ever having touched the code that runs the process. It is the difference between splicing your wires into someone else's circuit and plugging into the sockets they deliberately provided.

There are a few kinds of events worth distinguishing at a capability level. Business events and integration events are raised by the application to signal that something has occurred or is about to occur, and they are the workhorses of extension logic. There are also events that let you inject validation or extend behaviour at specific decision points. The common thread is that every one of them is a contract: Microsoft commits to raising that event at that point, and your subscriber commits to reacting to it, and neither side needs to know the internal details of the other. That contract is what survives upgrades. As long as the event still fires, your subscriber still works, no matter how much Microsoft rewrote the code around it.

The insight that matters: the extension model does not just prevent you from breaking the base, it changes what "customization" means. You are no longer changing the system, you are subscribing to it. Your logic is a guest that the platform invites in at published moments, runs, and then returns control to the standard flow. That is why an upgrade can replace enormous amounts of Microsoft's internal code and leave your customization working: your code was never entangled with theirs, it was only ever connected at named, stable points.

This event-driven approach does impose a discipline. You have to find the right event for the behaviour you want to influence, and occasionally the exact hook you need does not yet exist, in which case the correct move is to request that Microsoft publish one rather than to look for a way around the boundary. That constraint frustrates developers coming from the old modify-anything world, but it is a feature, not a limitation. Every place your code connects is a place Microsoft has promised to keep stable, and that promise is precisely what you are buying.

5. Per-tenant extensions versus AppSource apps

Not every extension is meant for the world, and Business Central recognises this with two distinct kinds of app. Understanding the difference matters because it shapes how you build, how you deploy, and what standards you are held to.

A per-tenant extension, often abbreviated PTE, is a customization built for one specific customer's environment. It is the modern equivalent of the bespoke tailoring a partner used to do in the base code, except now it lives as a proper app installed only in that one tenant. If a client needs a field, a report format, an approval rule or an integration specific to their operation, that is a per-tenant extension. It is developed, published and maintained privately for them, it does not go through any public listing, and it can be as narrowly specific as the business requires. The overwhelming majority of real-world Business Central customization is per-tenant work.

An AppSource app is a different proposition. AppSource is Microsoft's public marketplace, and an app published there is a commercial product intended for many customers. Because a marketplace app can be installed into any tenant alongside anyone else's apps, Microsoft holds it to a much higher bar: it must pass technical validation, follow object-numbering and naming rules that prevent collisions with other apps, meet quality and support standards, and behave predictably as a general-purpose product rather than a one-client customization. Building for AppSource is closer to shipping commercial software than to delivering a client project, and the governance around it reflects that.

The practical decision is straightforward. If you are solving one organisation's specific problem, you build a per-tenant extension and you are done. If you have built something genuinely reusable that many businesses would pay for, and you are prepared to support it as a product, you consider AppSource. Most operations only ever consume AppSource apps rather than publish them, installing third-party solutions the way you install apps on a phone, while their own tailoring stays in per-tenant extensions. Both are the same technology underneath, the same AL, the same extension model; the difference is audience and the standard of governance that audience demands.

6. How extensions keep cloud upgrades safe (the evergreen promise)

Here is where the architecture pays off, and where the decision maker should pay closest attention, because this is the single largest operational benefit of the whole model. The cloud version of Business Central is evergreen: Microsoft ships major updates on a regular cadence, twice a year, with minor and security updates in between, and these updates apply automatically. There is no upgrade project in the old sense, no multi-month re-implementation, no re-merge of customizations. The system moves itself to the next version on a schedule, and your business keeps running. That is only possible because of the extension model.

The mechanism is exactly what the earlier sections built toward. When Microsoft updates the base application, they may rewrite huge amounts of internal code, but they preserve the public surfaces: the tables and fields you extended, the events you subscribed to, the APIs you called. Your extension, which only ever connected through those surfaces, reattaches to the new base and keeps working. During the update, the platform validates that your installed extensions are still compatible with the incoming version, and because your code never lived inside Microsoft's objects, there is nothing to reconcile. Customization and upgrade have been decoupled at the architectural level, which is what "evergreen" actually means underneath the marketing word.

This is a genuine transformation for anyone who lived through the old model. The organisation that used to freeze on an ancient version because upgrades were unaffordable now sits on a system that is always current, always supported, always patched, with no periodic upgrade megaproject to dread. The total cost of ownership changes shape: you trade the occasional enormous upgrade bill for a steady, predictable cadence of small, automatic updates. For a decision maker, that shift from lumpy capital-project risk to smooth operational rhythm is often the most compelling single argument for cloud Business Central. For the wider case on what cloud ERP delivery actually changes, see the cloud ERP explained pillar.

The honest caveat: evergreen does not mean effortless. Automatic updates still demand a discipline the old frozen-version world let you avoid. You need a testing routine that exercises your extensions against each preview release before it goes live, so that a change in Microsoft's behaviour is caught in a sandbox rather than in production. Extensions built carelessly, depending on internal behaviour they were never meant to touch, or on events used in unsupported ways, can still break on an update. The model makes safe upgrades possible; it does not make sloppy customization safe. The organisations that get burned by an automatic update are almost always the ones that cut corners inside the extension.

7. Configuration versus extension versus integration: choosing the right tool

Before anyone writes a line of AL, there is a prior question that separates good Business Central practice from expensive Business Central practice: does this requirement need code at all? A great deal of what people instinctively reach for a developer to build can be achieved without an extension, and the discipline of exhausting the cheaper options first is one of the clearest markers of a mature implementation. There are three broad levers, in ascending order of cost and commitment.

• Configuration: Business Central ships with an enormous amount of built-in flexibility. Number series, dimensions, posting groups, approval workflows, user permissions, report layouts, and personalised pages can all be adjusted through setup rather than code. Page personalisation alone lets users and administrators rearrange, add and hide fields on pages without any development. The first question for any requirement should always be whether standard configuration already covers it, because configuration costs no development, carries no upgrade risk, and can be changed by a functional consultant rather than a programmer.
• Extension: when configuration genuinely cannot meet the requirement, an extension is the correct next step. New fields, new business logic, custom documents, bespoke calculations and behaviour that the standard product does not offer are all legitimate extension territory. The key is that you reach for it after configuration, not instead of it, and that you build the smallest extension that solves the actual problem rather than gold-plating.
• Integration: some requirements are not really about changing Business Central at all, they are about connecting it to another system. Pushing invoices to a payment platform, pulling data from a warehouse system, syncing with a CRM or a specialist industry application. That is integration work, done through APIs and connectors rather than through extending the ERP's own behaviour, and treating an integration requirement as a customization requirement is a common and costly category error.

The practitioner's rule I apply on every implementation: configure first, extend only when configuration fails, integrate when the need is really about another system. Reaching for AL as the default answer to every requirement is how projects accumulate unnecessary custom code, and every line of custom code is something you own, test and maintain forever. The cheapest customization is the one you did not have to write because standard configuration already did the job. For the connectivity side of that triad, how Business Central talks to the systems around it, see the Business Central APIs and integrations pillar.

8. The AppSource marketplace and buying versus building

Once you accept that a requirement genuinely needs more than configuration, the next decision is whether to build it yourself or buy something that already exists. AppSource, Microsoft's marketplace for Business Central apps, is the reason this is a real choice rather than a foregone conclusion. It hosts a large and growing catalogue of validated apps covering everything from country-specific tax and compliance to industry verticals, advanced warehousing, document management, e-commerce connectors, payment integrations and reporting tools. For a great many common requirements, someone has already built, validated and supported the solution, and installing it is a matter of a few clicks.

The buy-versus-build calculation is the same one that applies to software everywhere, but the extension model sharpens it. Building your own extension gives you exactly what you want and full control, but you own it forever: you pay to develop it, to test it against every Business Central update, to fix it when something changes, and to enhance it as needs evolve. Buying an AppSource app transfers most of that ongoing burden to the publisher, who maintains it, keeps it compatible with each release, and supports it as a product. In exchange you accept the app as it is built, with whatever configuration options it exposes, rather than tailored precisely to you.

My default advice to clients is to treat AppSource as the first place to look for any non-trivial requirement, and to build only what genuinely does not exist or where your need is truly unique to your operation. A common healthy pattern is to buy the general-purpose capability, a proven warehousing or document-management app, and to build small, focused per-tenant extensions only for the parts that are specific to your business and that no product could reasonably provide. That mix, buy the commodity and build the differentiator, keeps your own custom-code footprint small, which is exactly what you want, because a small footprint is a small maintenance burden and a small upgrade risk. Every requirement satisfied by a maintained AppSource app is a requirement you never have to test against next spring's update yourself.

9. Governance: managing extensions, dependencies and technical debt

The extension model solves the upgrade problem, but it does not remove the need for engineering discipline, and a Business Central estate that accumulates extensions carelessly can build up its own kind of technical debt. Governance is the set of habits that keep a growing collection of extensions healthy over time, and it is the part decision makers most often overlook until it starts to hurt.

Several concerns deserve deliberate management. Dependencies are the first: extensions can depend on other extensions, and a tangle of interdependent apps can become as brittle as the old monolith it replaced if nobody is tracking what relies on what. Keeping dependencies shallow and deliberate matters. Object numbering and naming come next: every extension claims ranges of object identifiers, and in a multi-extension environment, collisions and sloppy naming create confusion and conflict, which is exactly why AppSource enforces strict rules and why a serious internal shop should adopt similar conventions. Source control and release process are the third: because AL development lives in Visual Studio Code, it should live in Git, with branches, code review and a repeatable build-and-publish pipeline, so that you always know what version of which extension is running in which environment and can roll forward or back with confidence.

Then there is the discipline of testing against updates. The evergreen promise only holds if someone actually exercises the extensions against each preview release before it reaches production. That means maintaining a sandbox environment, running your critical processes through it when a new version previews, and catching incompatibilities early. It is unglamorous, ongoing work, and it is the difference between an update that passes unnoticed and one that surprises you on a Monday morning. The related concern is keeping the footprint lean: retiring extensions that are no longer used, resisting the temptation to build what configuration or an AppSource app could provide, and periodically reviewing whether the accumulated customization still earns its keep. Custom code is a liability as much as an asset, and an estate that only ever adds and never prunes will eventually feel as heavy as the systems the extension model was meant to free you from.

None of this is exotic. It is ordinary software engineering discipline applied to ERP, which is precisely what the move to AL and Visual Studio Code made possible. Organisations that treat their Business Central extensions like the real software they are, with version control, review, testing and lifecycle management, keep their estate healthy for years. Those that treat extensions as fire-and-forget one-off changes accumulate a quieter, more modern version of the old customization debt.

10. A practical approach to customizing Business Central well

Pulling the threads together, here is the sequence I would have any organisation follow when a new requirement lands, because the order of the questions matters more than the tools you eventually use.

• Start by challenging the requirement. Is this really a system change, or a process the business could adjust to fit the standard product? The cheapest customization is the one you decide you do not need, and standard Business Central embodies a great deal of well-designed practice that is often better than the bespoke workaround someone is asking to preserve.
• Try configuration next. Exhaust setup, workflows, dimensions, permissions, report layouts and page personalisation before anyone opens Visual Studio Code. A surprising share of requirements dissolve at this step, at zero development cost and zero upgrade risk.
• Check AppSource before building. If it needs more than configuration, look for a validated, maintained app that already solves it. Buying transfers the maintenance and upgrade-compatibility burden to a publisher whose job it is to carry it.
• Build a focused per-tenant extension when you must. When the need is genuinely specific to your business and nothing off the shelf fits, build the smallest extension that solves the real problem. Connect through supported surfaces, events and extension objects, never through anything that reaches into Microsoft's code.
• Treat integration as its own discipline. If the requirement is really about connecting to another system, solve it with APIs and connectors, not by bending the ERP's internal behaviour out of shape.
• Govern what you build. Put every extension under source control, review it, test it against each preview release, manage its dependencies, and retire it when it is no longer needed. The extension model keeps upgrades safe only if you keep the extensions healthy.

That sequence is not bureaucracy, it is the accumulated lesson of the era the extension model was built to escape. Every requirement handled at the cheapest sufficient level, configuration over code, buy over build, small over sprawling, is a requirement that will not cost you again at the next update. The organisations that customize Business Central well are not the ones that write the most AL, they are the ones that write the least AL necessary and manage it like real software. For a step back to whether the platform is the right fit in the first place, see the is Business Central right for your organization pillar, and for where AI now fits on top of this same extensible foundation, the Azure OpenAI and custom AI agents in Business Central pillar.

Final thoughts

The extension model is one of those architectural decisions whose importance is easy to miss until you have lived on both sides of it. For anyone who spent years watching good ERP customizations turn into upgrade prisons, the ability to tailor Business Central deeply and still ride an automatic, twice-yearly update cadence is not a technical footnote, it is the resolution of the oldest tension in enterprise software. Customization no longer fights upgradability, because your code never touches the vendor's code. It adds, it subscribes, it hooks in at published points, and it stays yours through every release.

For the developer, that means learning AL and Visual Studio Code, thinking in terms of extension objects and event subscribers, and accepting the boundary that never lets you edit the base as the very thing that keeps your work safe. For the decision maker, it means insisting on the discipline that makes the promise real: configure before you code, buy before you build, keep the custom footprint lean, govern what you own, and test every extension against every update. Do that, and Business Central stays fitted to your business and current with Microsoft at the same time, indefinitely. That combination, deep fit and permanent currency, was impossible in the old world, and it is the quiet achievement of the extension model that it is now simply how the product works.

Related reading: Business Central APIs and integrations, Business Central and the Microsoft ecosystem, Cloud ERP explained, Azure OpenAI and custom AI agents in Business Central, Is Business Central right for your organization.