Business Central vs Dynamics NAV

Business Central is the direct successor to Dynamics NAV — same posting routines, same dimensions, same general ledger logic — but the operating model around it is fundamentally different. If you're still running NAV, understanding those differences is the key to scoping a sensible upgrade project.

Deployment

NAV was overwhelmingly on-premise, installed on customer-managed Windows servers and SQL Server. Business Central is SaaS-first: Business Central Online runs on Azure in Microsoft data centres, with Microsoft owning patching, infrastructure, and twice-yearly platform updates. On-premise Business Central exists but the vast majority of new implementations are cloud.

Customisation model

This is the biggest single change. NAV was customised through the C/AL language and the base object model: partners modified Microsoft's own objects directly. Upgrades were slow and expensive because every modification had to be re-merged. Business Central replaces C/AL with AL and an extension model — partners ship code as separate, side-by-side AL extensions, and the base application stays untouched. Upgrades happen automatically twice a year, with extensions tested against the new platform in advance.

User interface

NAV's Windows client is gone. Business Central is fully web-based, with first-class mobile, Outlook, and Teams experiences, plus an embedded Copilot for sales line suggestions, bank reconciliation, and other tasks.

Release cadence

NAV shipped roughly once a year with a long support tail. Business Central ships two major updates per year (Wave 1 in April, Wave 2 in October) plus monthly hotfixes, with mandatory updates on a customer-defined window.

Licensing

NAV was a perpetual license with annual maintenance. Business Central is a per-user subscription — Essentials, Premium, or Team Member.

What stays the same

It's worth saying clearly, because the marketing makes BC sound like a different product: the application core is NAV. Posting groups, dimensions, the general journal, item costing, the way a sales order flows to a posted invoice — a NAV finance user sits down in Business Central and recognises everything within an hour. NAV skills transfer almost completely; what changes is the technology wrapper and the commercial model. That matters when you plan training: budget for "where did my button go" web-client orientation, not for re-learning the ERP.

The support clock

Mainstream support for every NAV version has ended; the last version, NAV 2018, is in extended support, and that runs out too — into 2028, after which there are no security patches at all. Nothing stops a NAV system from running past that date, but each year the surrounding world moves: TLS requirements, bank formats, e-invoicing mandates, Windows Server versions, and the shrinking pool of C/AL developers willing to maintain it. Most organisations don't leave NAV because it stopped working; they leave because compliance or integration requirements finally demand something the old platform can't do, usually at the least convenient moment. Planning the move on your own schedule is strictly better than doing it under a deadline.

The three realistic paths

1. NAV → Business Central Online (SaaS). The default and what Microsoft's tooling targets. Data migrates via the cloud migration tooling; code gets rebuilt as AL extensions. You give up direct database access and server control, and gain automatic updates and the full cloud surface (Copilot, Power Platform connectors, telemetry).
2. NAV → Business Central on-premise. Same modern application, self-hosted. Legitimate when data residency or a hard dependency on direct SQL access forces it, but you keep the infrastructure burden and lose the cloud-only features — see BC on-premise vs SaaS before choosing this deliberately rather than by inertia.
3. Stay on NAV, contained. Defensible only as a short bridge — e.g. a company being sold or absorbed within two years. As a strategy it just moves the project later and makes it more expensive.

The upgrade path in practice

Microsoft provides tooling that lifts NAV data into Business Central, but custom C/AL modifications must be re-built as AL extensions. For heavily customised NAV deployments, the project often looks more like a re-implementation than a database upgrade, which is why many customers use the move as an opportunity to clean house.

That clean-house step is where projects are won. A typical fifteen-year NAV database carries hundreds of modifications nobody can explain, half of which duplicate features Business Central now ships standard (approval workflows, item attributes, bank feeds) or that an AppSource app covers. The right sequence is: inventory the customisations, kill everything that standard BC or an ISV add-on covers, and rebuild only the genuinely differentiating remainder in AL. Teams that skip the inventory and port everything one-to-one pay twice — once to rebuild code they didn't need, and again at every release wave when it has to be maintained.

How to decide

If you're on NAV today, the question is no longer whether Business Central — Microsoft ships no alternative successor — but when and how much to re-implement. Lightly customised NAV: migrate data, adopt standard, done in months. Heavily customised NAV: treat it as a re-implementation with data history migration as a scoped decision (many teams bring opening balances and open documents only, keeping the NAV database read-only for lookups). Either way, the cost driver is your customisation debt, not the software.