The Upgrade That Isn't Just an Upgrade
Microsoft Dynamics NAV has served thousands of businesses well for decades. If your company is running NAV 2013, NAV 2016, NAV 2018, or any version in between, chances are it still works. Your people know it. Your processes are built around it. The question you're probably asking is: should we stay, or is it time to move to Business Central?
This article is for the companies that have already decided to move — and want to understand what that journey actually looks like.
NAV and Business Central: The Relationship
Business Central is not a replacement product built from scratch. It is the evolution of NAV. The same core data model, the same ledger logic, the same underlying concepts. Microsoft rebranded and rebuilt the delivery model: instead of on-premise software installed on your own servers, Business Central is primarily delivered as a cloud SaaS product (Business Central Online) through Microsoft's infrastructure.
This means BC inherits NAV's strengths. But it also means some things work differently now — and a few things that were easy in NAV are no longer supported in the same way.
What Changes When You Move
The Platform
NAV ran on your servers. Business Central Online runs on Microsoft Azure. This is the most fundamental change — and for most businesses, it is the right one. You no longer manage updates, patches, or infrastructure. Microsoft handles two major release waves per year automatically. Your IT team stops being in the business of maintaining an ERP server.
If you have regulatory or policy reasons that require on-premise, Business Central also has an on-premise version. But cloud is where all investment is happening.
The Development Language
NAV customisations were built in C/AL — a proprietary language. Business Central uses AL. These are similar enough that experienced NAV developers learn AL quickly, but your existing C/AL customisations cannot simply be carried over. They need to be rewritten as AL extensions.
This is often where migration projects stall. Companies discover they have dozens of customisations that were added over years, some with little or no documentation. Each one must be evaluated: is this still needed? Can it be replaced by standard BC functionality? If not, it must be rebuilt.
The Customisation Model
In NAV, customisations were often made directly to base objects — modifying tables, forms, and codeunits that shipped with the product. This created upgrade hell. Every time you updated NAV, your customisations had to be merged back in manually.
Business Central uses an extension model. Customisations live in separate AL extension packages that layer on top of the standard application. Upgrading BC does not touch your extensions. This is a major quality-of-life improvement — but it also means existing NAV modifications cannot be moved directly. They must be rebuilt following the extension architecture.
The User Interface
NAV had a thick client — a Windows application installed on each user's machine. Business Central uses a browser-based interface (the Web Client) that works on any device. The role centre concept is similar, but the visual experience is substantially different.
User training is non-negotiable. Even if the underlying data and processes are the same, users will need time to orient themselves in the new interface.
What Stays the Same
The good news: the core accounting logic, posting routines, and data structures are fundamentally similar. A chart of accounts from NAV maps cleanly to Business Central. G/L entries, vendor ledger entries, customer ledger entries — these concepts carry over. Your finance team will recognise what they are looking at.
Data migration — moving your master data (customers, vendors, items) and historical transactions — is well-understood and has established tooling. It is not trivial, but it is manageable with the right approach.
The Three Things That Determine Migration Success
1. A complete customisation inventory. Before anything else, you need to know exactly what has been modified in your NAV system. Custom tables, modified pages, added fields, custom reports, integrations with other systems. This inventory drives the project scope and the budget.
2. A deliberate data migration plan. Decide upfront how much history you need in BC from day one, what can be archived, and what can be left in NAV for reference. Trying to migrate everything is often unnecessary and always expensive.
3. A change management plan. The technical migration is achievable. The harder part is preparing your team. Budget for training time. Identify power users in each department who will learn BC first and support their colleagues through the transition.
When Is the Right Time?
The best time to migrate is before NAV reaches end of mainstream support. Microsoft's mainstream support for older NAV versions has already ended — extended support provides security patches but no functional enhancements. Each year you stay on NAV, the gap between what NAV can do and what Business Central can do widens.
It is also worth noting that new BC functionality — AI-assisted features, Power Platform integration, improved API connectivity — is only available to cloud customers. On-premise NAV customers are increasingly left behind.
Where DYNASYS Can Help
NAV-to-BC migration projects are in our wheelhouse. We have worked on migrations from NAV 2013 through NAV 2018, across manufacturing, services, and print industry clients. Our approach starts with a detailed discovery phase — mapping your current customisations, data, and integrations — before a single line of AL is written.
If you are evaluating a migration and want an honest assessment of scope and cost, get in touch. We will tell you what we find, not what you want to hear.