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.
We can keep 100% of 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.
In practice this means 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.
One migration we ran shows the whole arc, start to finish: 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.
