General project risks apply here too: why ERP implementations fail.
It is a migration, not an upgrade
Microsoft's naming makes this confusing on purpose. Business Central is Dynamics NAV — same lineage, same underlying logic, renamed in 2018. So people reasonably expect an upgrade: run a tool, arrive on the new version.
The technical reality is different, and the difference is one thing: C/AL is gone. NAV customisations were written by modifying base objects in C/AL. Business Central does not permit that. Every modification has to be rebuilt as an AL extension that sits alongside the standard application rather than inside it.
The data comes across with Microsoft's tooling and is rarely the hard part. The customisations are the project, and they determine the budget almost entirely.
The one number that predicts everything. Before asking anyone for a quote, find out how many modified base objects your NAV database contains. A partner can extract this in an afternoon, and it forecasts the cost of the project better than user count, data volume or company size.
Your customisations are the whole project
Most NAV databases that have been running for a decade contain a large number of modifications, and a meaningful share of them are no longer used. Before rebuilding anything, sort them into four buckets.
| Bucket | What to do |
|---|---|
| Now standard | Business Central absorbed a great deal of what people customised NAV for. Check before rebuilding — this is where the biggest savings are |
| Available on AppSource | A supported app is almost always cheaper over three years than maintaining your own version |
| Genuinely yours | Rebuild as an AL extension. This is the real cost line |
| Dead | Nobody has used it in years. Drop it — and expect this bucket to be larger than anyone predicts |
This triage is worth doing properly, with the people who actually use the system rather than from the object list alone. Companies routinely find that a third or more of their modifications fall into the first and last buckets, and that changes the budget materially. The general criteria are in when AL customisation pays off.
Where you are starting from matters
| Starting point | What to expect |
|---|---|
| NAV 2016–2018 | The easiest path. Data structures are close and Microsoft's migration tooling supports these versions directly |
| NAV 2013–2015 | Workable, usually via an intermediate step. Some modules changed significantly in between |
| NAV 2009 and older | Treat it as a fresh implementation with data migration. Trying to preserve the old structure costs more than starting clean |
| Navision 3.x–5.x | Definitely a fresh implementation. The gap is too wide to bridge economically |
The instinct with an old version is to preserve as much as possible because it represents years of work. In practice, the older the source, the more of that work has already been superseded by standard functionality — and a clean implementation with migrated master data and balances usually costs less than an attempted conversion.
Cloud or on-premises
Both are supported, and the choice is more consequential than it first appears.
Business Central Online gets automatic updates twice a year, infrastructure included, and access from anywhere. The constraint is that you accept the update schedule: extensions must be compatible, and if one is not, it becomes urgent rather than optional.
On-premises keeps control of timing and infrastructure, and permits per-tenant extensions with wider latitude. You keep servers, backups and update projects.
Most companies leaving NAV go to the cloud, and the honest reason is usually not features — it is that they have just spent a decade discovering what it costs to own an ERP that only updates when someone runs a project.
One thing worth deciding early either way: if you go cloud, the extension compatibility question becomes a permanent obligation, not a one-off. Ask any partner how they handle it and who pays.
What comes across
| Data | Transfers | Notes |
|---|---|---|
| Chart of accounts, master data | Yes | Good moment to clean up years of accumulated duplicates |
| Open entries and balances | Yes | Reconciled to a cut-off date and signed off |
| Posted document history | Usually | Volume drives cost; consider summarising older years |
| Custom tables | Only with a rebuilt extension | The table has to exist in the new solution first |
| Reports and layouts | Rebuilt | Routinely underestimated. Budget for it explicitly |
| Permissions | Rebuilt | Also a good moment to review who actually needs what |
Custom reports are the line that surprises people. They feel like they already exist, so nobody budgets for them — and then a hundred RDLC layouts need rebuilding or replacing. Count yours before signing anything.
A realistic plan and budget
- Object analysis, 1–2 weeks. How many base objects were modified, and what does each do. Output is the four-bucket triage above.
- Scope decision, 1 week. What gets rebuilt, what is dropped, what moves to AppSource. Requires the business, not just IT.
- Environment and extensions, 4–10 weeks. Depends almost entirely on the third bucket.
- Data migration and two test runs, 3–4 weeks. Two, not one.
- Report rebuilding, 2–4 weeks. Runs in parallel and is usually the forgotten line.
- Testing and training, 2–3 weeks. On your own configuration with your own data.
- Cutover. Ideally at a period end.
Three to six months for a mid-sized company with a moderate number of customisations. The variance is enormous and it comes from one place: how much was modified and how much of it still earns its keep. Cost structure is broken down in what an implementation costs, and partner selection in how to choose a partner.
Frequently asked questions
Is Business Central just a renamed Dynamics NAV?
Same product lineage, renamed in 2018, but the development model changed fundamentally. NAV customisations were written by modifying base objects in C/AL; Business Central requires AL extensions that sit alongside the standard application. That single change is why this is a migration rather than an upgrade.
Can we migrate directly from NAV 2009?
Not as a direct upgrade. From NAV 2009 and older it is more economical to treat the project as a fresh implementation with data migration for master records and balances. Attempting to preserve the old structure typically costs more than starting clean.
What happens to our C/AL customisations?
They have to be rebuilt as AL extensions. Before doing that, triage them: a substantial share are now standard functionality, available as supported AppSource apps, or simply no longer used. Companies routinely find a third or more falls into those categories.
Do we have to move to the cloud?
No, on-premises remains supported. Most companies leaving NAV do go to the cloud, usually because they have just spent a decade learning what it costs to own an ERP that only updates when someone runs a project. Either choice works; the cloud one makes extension compatibility a permanent obligation.
How long does a NAV to Business Central migration take?
Three to six months for a mid-sized company with a moderate number of customisations. The range is wide because the driver is not user count or data volume but how many base objects were modified and how many of those still earn their keep.
Will our custom reports transfer?
No, they are rebuilt. This is the most commonly underestimated line in the budget because existing reports feel like they already exist. Count how many you have before asking for a quote — it is often more than anyone expects.