The two migration paths Microsoft offers, and what each one keeps
Microsoft documents two ways from Dynamics NAV to Business Central online. Both start with the same step: upgrading NAV to Business Central version 14 on-premises. There is no direct jump from NAV to the cloud.
Full migration. All your data and your customisations come across. The price: every C/AL customisation has to be converted into AL extensions, and the system has to be upgraded past version 14 to a current on-premises version before the cloud migration runs.
Reimplementation. You stop at version 14 and use Microsoft’s Business Central 14 reimplementation tool. No extension conversion. It moves master data, open orders, opening balances and setup, plus a defined subset of posted history such as posted G/L entries and posted sales invoices. Your legacy customisations and their data stay behind.
Two things to know before you plan on the second path. As of September 2026, Microsoft labels the reimplementation tool a preview feature, not meant for production use. And its own pages describe it both as carrying no historical transactions and as carrying that subset of posted entries. Check on your own data what it actually moves before you promise anyone a clean start.
Which path fits is not a technical question. It depends on whether the rules your custom code encodes are still the rules your business runs on. If they are, a reimplementation throws them away. If they are not, a full migration pays to carry them.
The upgrade route from your NAV version
Your starting version fixes the route. Each hop is a real upgrade, run and checked on its own. This is Microsoft’s documented route as of September 2026:
| Starting version | Route to Business Central online |
|---|
| NAV 2015 to 2018 | BC 14 on-premises → BC on-premises version 25 or later → BC online |
| NAV 2013 and 2013 R2 | NAV 2018 → BC 14 on-premises → BC on-premises version 25 or later → BC online |
| NAV 2009 SP1 and R2 | NAV 2013 or 2015 → NAV 2018 → BC 14 on-premises → BC on-premises version 25 or later → BC online |
On the reimplementation path, the route stops at version 14 and the reimplementation tool takes over from there. Microsoft documents no route for anything older than NAV 2009 SP1.
Three checks before the first hop. The SQL Server database has to run at compatibility level 130 or higher. Your country’s localisation has to exist as an app in Business Central online, with any local tax or reporting code rewritten to work with it. And Microsoft asks for at least one full dry run in a sandbox before the production cutover. Skip it, and your cutover weekend becomes the dry run.
What the cloud migration tool moves, and what it cannot
Once you are on a supported on-premises version, the move to online is Microsoft’s cloud migration. You connect the on-premises database to the online tenant and install the Integration Runtime. Azure Data Factory then replicates the data, in full first, then in deltas. The data upgrade runs last. Then you complete the migration and the online environment becomes the live system.
The tool moves data. It does not decide anything. Data from tables with code customisations only comes across if those customisations exist as AL extensions installed on both the on-premises and the online side. A custom field that never became an extension is a field whose data stays behind.
And the cloud refuses things that on-premises allowed. The big one is .NET interop, which NAV systems of that generation use widely. The converter will hand you AL that compiles and still can never be published to SaaS. You find out at deployment, unless someone checks during the audit.
Most NAV migrations fail on a decision nobody made
The failure is rarely technical. Fifteen years into a Dynamics NAV system, nobody remembers why half the setup exists. A field was added for a customer who left in 2014. A posting routine was bent around a rule that changed two reorganisations ago. A report exists because one controller asked for it once.
Nobody decided to keep any of that. It survived because deleting it felt riskier than moving it. So the migration project inherits every unmade decision at once, and the software encodes the missing decision faithfully, at scale.
That is why we start with an audit and not with a data mapping, the same root cause approach we bring to any group-level ERP question. Until you know which rules the business still runs on, every technical choice after that is a guess wearing a project plan.
Your data and your logic are two different projects
They get treated as one, and that is where budgets die. Historical data is a preservation problem: it has to stay accurate, auditable and reachable. Logic is a design problem: it has to be worth rebuilding.
On a full migration, we can keep your historical data. We will rarely recommend migrating 100% of your logic. The two are unrelated decisions, and collapsing them into one is what turns a migration into a fifteen-year debt transfer.
On that path, posted entries, open items, dimensions and balances come across intact, with reconciliation you can show an auditor. Customisations get judged one by one, on whether the business rule behind them is still true.
What happens to fifteen years of customisations
Each one gets sorted into three outcomes. It is now standard Business Central, so it goes away. It encodes a rule the business still runs on, so it gets rebuilt properly as an extension. Or nobody can name the rule it serves, in which case it dies, and we write down what died and why.
We are not anti-customisation. We are against careless customisation, the cosmetic kind that hides a missing process, or the kind that breaks on every upgrade. We know when to build a thousand objects and when to build zero. Most migrations get both decisions wrong, in the same project.
The measure of a good rebuild is not how little code you wrote. It is whether the code you wrote survives the next monthly update without anyone touching it.
What one NAV migration taught us, from conversion to SaaS
One migration we ran went from the converted C/AL to live on Business Central SaaS in eight months. The conversion itself fit in a single day. Owning what it produced took far longer: object numbers instead of names, with blocks hiding which record a field belongs to, dead variables nobody had ever been forced to look at.
The order we would repeat. A dedicated test app three weeks after the conversion, before any cleanup, so every change after it could be proven. Five months on-premises on the current version first, on purpose, so “does the code behave like NAV” and “is the code allowed in the cloud” got separate answers. The second question alone cost four days and three changes of the app’s target before the .NET code was replaced with AL written for the purpose.
And the decision people find surprising: the converted code stayed a single app for eighteen months before anyone split it. The seams you can see in a converted monolith are the old system’s limits, not the business’s. The real ones showed up in operation. That code is now thirteen apps, and major version upgrades arrive without a project.
The full story, commit by commit: eight months from NAV to Business Central SaaS, and three years to make it safe to touch.
Business Central updates twice a year, and it does not ask
This is the part NAV never prepared anyone for. On-premises NAV, you upgraded when you chose to, which for many groups meant almost never. Business Central online ships two major waves a year plus monthly service updates, on Microsoft’s calendar.
A migration that lands a pile of tightly coupled code into that cadence has not finished, it has scheduled its own crisis. The extension model exists to prevent exactly this, but only if the code respects it: no dependency on internals that Microsoft is free to change, event subscribers rather than modifications, and a test suite that tells you an update broke something before your users do.
A large business application can run past a thousand AL objects and still absorb every monthly update with zero impact. That outcome is a design decision made during the migration, not a maintenance effort bolted on afterwards.
Multi-entity groups have a harder problem, and it is not technical
Across subsidiaries, the same word means different things. Two entities call something a delivery and mean two different moments. Three chart of accounts have grown apart because each was maintained locally and nobody arbitrated.
A migration forces that arbitration into the open, usually late, usually as a technical ticket, usually decided by whoever is in the room. That is the most expensive way to make a group-level decision.
We surface those conflicts during the audit, name them as decisions that belong to the executive committee rather than to a consultant, and get them settled before anyone configures anything. Consolidation, intercompany flows and group reporting stop being a phase-two problem and become a constraint the design already respects.
How long it takes, and what actually drives the cost
The variable is almost never the volume of data. It is the number of unmade decisions and the number of custom objects that still have a defensible reason to exist.
A clean single-entity NAV with light customisation is a short project. A multi-entity group with fifteen years of accumulated logic, several charts of accounts and no current process documentation is a transformation programme, and pricing it as a data migration is how it ends up needing a Business Central rescue.
The audit exists to tell you which one you are, before you commit a budget to it. It produces a written verdict on what moves, what dies and why, and a roadmap with phases you can actually stop between.
