Extensions The Quiet Revolution in Business Central

Most revolutions announce themselves with a loud bang. This one happened quietly, in lines of code.

When Microsoft introduced the extension model in Business Central, it didn’t reach me with much fanfare. I shrugged; it sounded like another overpromised solution—maybe even one that would make life harder. (I’m looking at you, RDLC report layouts.)

Despite the ho-hum introduction, what was happening was nothing short of revolutionary. Microsoft had quietly changed the very DNA of the system I’ve been working with for most of my life.

What does it all mean? For as long as I can remember, there’s been a tug-of-war between flexibility and stability. You could shape the system to your business with customizations, or you could keep it upgradeable, but rarely both. With the advent of extensions, you no longer needed to choose between Tony Stark’s innovation and Steve Rogers’ discipline.

At the time, even I underestimated how deep the shift was. When it hit me, it was like a bucket of ice water was poured over my head. I’d been customizing with C/AL code for the better part of two decades. I thought I understood what “customization” meant. Extensions deliver the same magic, but they allow you to build outside the base code instead of inside it. Microsoft had reinvented what it meant to customize BC.

The Old World: Customization Chaos

Before extensions, every serious NAV implementation was a balancing act; and the stakes were always high.

I was an end user of NAV in that era. We had a system that, by every practical measure, was perfect for our business. The processes were tailored like a handcrafted Italian suit; every field and form (now pages, and yes, dinosaurs were roaming the earth) fit precisely how we worked. It was perfect—right up until it was time to upgrade.

With each upgrade, our level of customization increased the cost exponentially. Every customization had to be compared against the base Microsoft code. Depending on how it was done, it might need to be redesigned or replaced entirely. Eventually, the complexity became too much; and that’s when I learned firsthand what it meant to be landlocked on a version.

Installing one or more ISV solutions led to a similar story. Should we insert the ISV solution’s code before or after the Microsoft code? Did it need to be aware of our customizations?

I didn’t know it yet, but I needed a new paradigm in my life.

Enter Extensions: My Hero

When I first heard about extensions, it didn’t sound like a revolution. It sounded like housekeeping.

Having spent years living in C/AL, that sounded annoying, silly, and maybe even ridiculous. I was wrong.

It took time and a few cycles to really grasp what Microsoft had done. By separating business logic from the base system, they’d re-architected the entire philosophy of Business Central. Instead of treating customizations like invasive surgery, extensions let us add new functionality like modular attachments; safe, reversible, and independent. The base code could evolve, and our logic could evolve with it.

Everything that’s developed within Business Central is now an extension:

• AppSource extensions for solutions delivered by ISVs
• Per Tenant Extensions (PTEs) for client-specific requirements, built by you or your partner

No matter how you augment Business Central’s base functionality, one principle remains; we don’t modify, we extend.

What it means:

• No more expensive code merges
• No more being locked out of upgrades
• No more rewriting the same logic version after version
• For the first time, you can tailor a system to your business and keep pace with system improvements

What it doesn’t mean:

• Never needing to refactor
• Always being completely seamless

How It’s Delivered

When there are significant changes to BC that might conflict with an extension, Microsoft telegraphs these in advance. They inform the development community, in code, that something is being removed and provide guidance on its replacement. They also provide previews of features that will replace existing parts of base BC.

In addition, when an environment is preparing for an upgrade, it proactively examines the extensions in that environment and identifies conflicts ahead of time. So upgrades do still require some work when customizations are involved; but unlike the old world, they’re not like solving a jigsaw puzzle where the picture constantly changes.

Real-World Impact

A few years ago, I worked with a client who had lived the old-world customization experience. They’d been running on Dynamics NAV for more than a decade, using the same database, with the same modifications, and experiencing the same pain.

Over the years, they’d added layers of custom code. Modernizing felt like tiptoeing through a minefield. When we first talked about moving to Business Central, they were skeptical.

The extension model changed the conversation. Instead of rewriting the entire system, we reimagined it. We built extensions that replicated their critical functionality, but left the base clean and intact.

By the time we went live, the difference was night and day.
Within a year, their internal team—none of them developers by training—was confidently maintaining their own extensions.

Within two years, they were upgrading Business Central themselves. They’ve now gone through multiple versions of BC (on-premises); no drama, minimal downtime, and no lost weekends chasing conflicts.

That single architectural change gave them what years of consulting hours never could; independence. With that independence came innovation. They can now utilize any tools the business requires to connect and deliver functionality and insights.

They’ve transformed from surviving on an aging ERP to thriving in an ecosystem that constantly evolves with them. Extensions didn’t just save them money on upgrades; they gave control back to the people who rely on the system every day. They turned the ERP from a closed box into a living platform.

Looking Back

Looking back, I realize I didn’t always appreciate the elegance of Microsoft’s change to the platform. In the old days, deep modifications felt like craftsmanship; like carving code into the heart of the system. It was intricate, personal, and satisfying. The idea of writing outside the base felt detached; almost wrong.

Now that I’ve seen how teams using extensions outperform those still using legacy systems in the old way, I’m not just a believer; I’m an evangelist.

True craftsmanship isn’t only about depth; it’s about sustainability. Extensions taught me that good design doesn’t fight the platform; it flows with it. The best developers I know now build with the same mindset: “How can I make this powerful, flexible, and invisible during upgrades?”

On the client side, I’ve also seen a similar evolution. Companies that once saw customizations as a risk now see them as opportunities. A culture of purposeful experimentation has replaced the fear of breaking things.

We’ve moved from a world of fragile control to one of resilient innovation.

Looking Forward

Extensions don’t make Business Central flashy; they make it future-proof.
By moving customizations out of the base and into modular containers, businesses have gained something far more valuable than momentary code stability: freedom.

Freedom to innovate without fear.
Freedom to evolve without reimplementation.
Freedom to keep pace with technology instead of being buried by it.

I used to joke that the best thing about NAV is that you could customize it; and the worst thing about NAV is that you could customize it. Well, I don’t say that anymore. With BC, you can have your cake and eat it too.

The move to extensions has been a revolution; it changed the rules of ERP without most people noticing. Those of us who have lived through both worlds know just how monumental that change truly was. It is a gift that will keep on giving.