Dynamics NAV vs Business Central: The Decision, Not the Product Sheet
Dynamics NAV and Business Central are the same product line, so comparing their feature lists will not settle anything. The decision is forced by three things that have nothing to do with features: the support calendar, the fact that your customizations have to be rewritten in a new language whichever way you go, and the parts of your code that a cloud service will refuse to run. Everything else, Copilot included, can wait.
We write this from a specific place. We deliver Business Central, and we have moved a Dynamics NAV code base of about 660 objects to Business Central SaaS, then lived with it through two years of updates. The numbers below come from that repository’s history, not from a brochure.
Is Business Central really a different product from Dynamics NAV?
No. Business Central is the name NAV took in 2018. Version 14 of Business Central, the Spring 2019 release, was the last one that still ran C/AL, NAV’s development language. From version 15, the only way to customize the product is AL, and the only way to ship AL is as an extension that sits beside the base application instead of modifying it.
That sentence is the whole comparison. The base application is the same family. What changed is how you customize it, where it runs, and how often it moves. Business Central online gets a major update every April and October, with a minor update in the months between, and each major comes with a preview about a month ahead and a five-month window in which you schedule it. NAV moved when you decided to upgrade. Business Central online moves whether you decided or not.
So the question is never “NAV or Business Central”. It is “which version of NAV do we run today, and what would it take to run the current Business Central instead”.
What actually forces the decision?
Three things, and only one of them is a date.
The support calendar. Dynamics NAV 2018 is the last NAV version there will ever be. Its mainstream support ended on January 10, 2023. Extended support ends on January 11, 2028. Extended support means security updates and paid non-security support, and Microsoft accepts no design changes or new features during that phase. NAV 2017 follows on January 11, 2027; every version before it is already past its date. If you run NAV 2018 or NAV 2017 today, you have a fixed end date. If you run anything older, you are already past yours.
The language. Every customization you have is written in C/AL. Business Central runs AL. The tool that converts C/AL to AL, Txt2Al, only ships with Business Central version 14 and has not been included since version 21. That means the conversion path always passes through a version 14 environment, whatever version you are aiming for. There is no route that lets you keep C/AL, including Business Central on-premises. This is the part of the decision that is not a choice: if you leave NAV, your code gets converted.
The cloud boundary. This one is a choice. Business Central on-premises still runs .NET interop, still reads files from a server disk. Business Central online does neither. Microsoft’s own migration guidance is blunt about it: .NET interop is not available online, and those parts must be redesigned. If your NAV code leans on .NET assemblies, on a file share, on a message queue or on a database link, the online edition will refuse the code as written. That is the boundary between an upgrade and a rewrite.
What did moving a real NAV code base to Business Central SaaS actually change?
Here is what the repository history says, in order.
The syntax conversion took one day. The first commit after the empty repository is the Txt2Al output: about 660 files and 190,000 lines landing at once. 257 pages, 180 tables, 69 codeunits, 4 reports, one XMLport. The manifest declared runtime 3.0 and application version 14. Two years later the same manifest declares runtime 15.1 against application 26. The distance between those two numbers is the project.
The cleanup touched almost every file. The next commits are mechanical: remove the with statements, deprecated for cloud development, replace object IDs with names, remove unused variables. The with removal alone rewrote 618 files. None of it is hard. All of it has to happen before compiling.
The .NET block was deleted wholesale. The converted code carried one file declaring 144 .NET types across 26 assemblies: file streams, directories, HTTP requests, JSON objects, a data table, an enterprise message-queue client, and fourteen client add-ins. Today there is not a single .NET reference left. What replaced them is what Business Central provides natively: HttpClient in 6 files, the JSON types in 37, temporary blobs in 55, isolated storage in 5. File uploads became stream uploads; the Excel import that used to write a file on the server now opens the workbook from a stream.
One thing the cloud refused, and the fix. NAV had been using a .NET data table’s expression evaluator as a free arithmetic engine. There is no such thing in the cloud. The manifest’s target flipped from on-premises to cloud on a Tuesday, flipped back the same day when that dependency surfaced, and went to cloud for good three days later, once a small expression parser had been written in AL: about 160 lines and one stack table. That is the shape of every cloud-boundary problem we have met since. Small, invisible in the object list, and a hard stop until it is solved.
Base-object changes became events. NAV let you edit Microsoft’s own objects. The conversion turned those edits into 95 page extensions and 51 table extensions and parked them in a quarantine folder. Today the application has 118 page extensions and 72 table extensions, and about 210 event subscribers. The subscribers outnumber the extensions. That is what “customize without modifying” looks like in practice: most of what used to be inline code in a Microsoft codeunit is now a method that listens for the moment that codeunit publishes.
The SaaS cut-over deleted more than it added. Seventeen months after the conversion, the commit that put the application on its SaaS footing changed 317 files, adding 4,000 lines and removing 20,000. An export app and a support app had already been carved out of the monolith before the cut-over; two weeks after it, an API app and an integration app followed. None of that split was part of the migration itself. The migration was about getting the code to run. The architecture came around it, before and after.
What it left behind. The application carries 128 obsolete-state declarations across its objects, because in a live SaaS tenant you never drop a column, you mark it obsolete and wait a wave. And its test app holds 17 tests, not wired into the build pipeline. That is the honest cost of a conversion where the budget goes to making things compile. We would not start one today without the discipline we apply to extension upgrades from the first commit.
What can wait?
Features. The feature gap between NAV 2018 and the current Business Central is real, and it is not the reason to move. Copilot, the modern client, the Power Platform connectors, the twice-yearly stream of improvements: all of it arrives on its own once you are on the platform, and none of it is available to you until you are. Deciding on features means deciding on things you will get anyway.
The other thing that can wait is the cloud versus on-premises question, but only for a while. Business Central on-premises gives you AL, extensions and the current base application while letting you keep .NET and file access. It is a legitimate landing point for a code base with heavy cloud-boundary dependencies. It is not a place to stay. You own the upgrades, and the boundary you postponed is still there.
What does waiting cost?
Every customization you write in C/AL between now and the move is written twice. That is the simplest way to see it. The 660 objects above were the count on the day of conversion. A team that keeps building on NAV for three more years converts a bigger code base with the same tooling, on the same version 14 bridge, with fewer people who still read C/AL.
Extended support is a second cost that looks free. Security fixes continue until January 2028. Design changes and new features stop, and the law in your country does not. If invoicing or reporting rules move where you operate, the functionality that follows them is something you build yourself, in C/AL, and then again in AL.
The third cost is the one nobody budgets: the audit of what your code depends on. Every month on NAV adds a report, an integration, a .NET call. Each one is a line in the inventory a migration team will have to produce before it can quote you. The inventory is cheaper to make now than later, and it is the same inventory either way.
How do we run this decision at Asio Services?
We do not start with a demo. We start with three counts, and a NAV database gives them up in a day.
How many Microsoft objects did you modify? Not how many custom objects you own. The base-object modifications are the ones that must become extensions and events, and they set the size of the project. Custom tables and pages convert almost as-is.
What does the code reach outside the database for? .NET assemblies, file shares, printers, COM automation, message queues, direct SQL. Each item on that list is a redesign, not a conversion. The length of the list decides whether Business Central online is a destination or a second step after on-premises.
Which customizations should not be rewritten at all? A large share of what a NAV code base carries covers gaps the current Business Central has since filled. We have written separately about which Business Central customizations should never have been written. The conversion is the one moment when deleting is free.
With those three counts, the decision stops being NAV versus Business Central and becomes a dated plan: which version 14 bridge, which landing edition, which quarter. The seven phases of a NAV to Business Central migration follow from there, and our Dynamics NAV to Business Central migration service runs them. If you want the three counts before you commit to anything, ask us for a clarity assessment.
FAQ
Can we stay on Dynamics NAV after January 2028? Technically, yes. The software keeps running. What stops is any form of support from Microsoft, including security updates. From that date every risk in the system is yours, and a partner who agrees to maintain it is taking on that risk with you.
Is Business Central on-premises a way to avoid rewriting our code? No. Business Central on-premises from version 15 runs AL and extensions only, exactly like the online edition. What it lets you keep is .NET interop and server file access. The C/AL conversion is identical. Only the cloud-boundary redesign is postponed.
How long did the conversion described above take? The C/AL to AL conversion landed in one day. The cleanup that made it compile took about two weeks of per-module work. Removing the .NET dependencies and making the application cloud-compliant took another five months. The SaaS cut-over came seventeen months after the conversion, with the split into satellite apps spread on either side of it.
Does the feature gap between NAV 2018 and Business Central matter? Not for the decision. The gap is large, and it closes on its own once you are on the platform. Deciding on features leads to a product comparison, and this is not a product comparison. It is a date, a language, and a list of dependencies.