If your company still runs Microsoft Dynamics NAV, the question is no longer whether to move to Business Central but how, and how soon. This guide covers the parts that decide the effort: which version you start from, what happens to your customizations, what moves with your data, and how a realistic project is structured.
Is your NAV version still supported?
Every NAV version follows Microsoft's Fixed Lifecycle Policy: five years of mainstream support, then five years of extended support, which covers security updates only. As of September 2026 most NAV versions are already past the end.
| Version | Mainstream support ended | Extended support ends |
|---|---|---|
| NAV 2013 and 2013 R2 | 9 January 2018 | Ended 10 January 2023 |
| NAV 2015 | 14 January 2020 | Ended 14 January 2025 |
| NAV 2016 | 13 April 2021 | Ended 14 April 2026 |
| NAV 2017 | 11 January 2022 | 11 January 2027 |
| NAV 2018 | 10 January 2023 | 11 January 2028 |
| Business Central 14 (on-premises) | 10 October 2023 | Ended 14 October 2025 |
Only NAV 2017 and NAV 2018 still receive security updates, and NAV 2017 stops in January 2027. Running an unsupported ERP is a security risk. It also leaves you building every legal or tax change, such as Serbia's e-invoicing rules, on a platform nobody maintains any more.
The upgrade path depends on where you start
There is no single "NAV to Business Central" button. Microsoft publishes a path for each starting version, and the older the version, the more intermediate steps it takes.
| Starting version | Path to the current Business Central on-premises |
|---|---|
| NAV 2009 SP1 / R2 | Via NAV 2013 and NAV 2018, or via NAV 2015, then as below |
| NAV 2013 / 2013 R2 | Upgrade to NAV 2018 first, then as below |
| NAV 2015, 2016, 2017, 2018 | Business Central 14, then version 25, then the current release |
| Business Central 14 to 24 | Version 25, then the current release |
| Business Central 25 or later | Directly to the current release |
Two versions matter in that table. Business Central 14 is the last version that still runs C/AL, and it is the bridge every NAV upgrade crosses. Version 25 is now the minimum starting point for later upgrades, and for moving to the cloud.
Moving to Business Central online
Microsoft does not support migrating directly from NAV to Business Central online. The cloud migration tool moves data from Business Central on-premises version 25 or later, so a NAV database first goes through the on-premises path above. The source database must run on SQL Server 2016 SP1 or later.
For companies on version 14 there is also a BC14 reimplementation tool, still in preview. It moves master data, open documents, opening balances, setup and a subset of posted history into a fresh online environment, but no customizations. It suits companies that want a clean start more than a faithful copy.
What happens to your customizations
This is usually the largest part of the project.
NAV customizations were written in C/AL, directly in the standard objects. Since Business Central 15, C/AL has been completely replaced by AL, and Microsoft's base application itself ships as an extension. Business Central online runs extensions only, so every customization you want to keep has to become an AL extension that builds on the standard application instead of changing it.
Microsoft documents two routes:
- Standard application plus extensions (recommended). You adopt Microsoft's base application as it is and rebuild your customizations as extensions: custom tables become extension tables, new fields become table extensions, page changes become page extensions, and changes to standard code are refactored to use events. This is the route that works online and keeps future upgrades cheap.
- Technical upgrade. You convert your entire customized application to AL and keep running it as your own base application. It is faster at first, but it only works on-premises and it carries today's modifications into every future upgrade. Microsoft strongly recommends the full upgrade instead.
The conversion tool, Txt2AL, only exists in version 14, which is one more reason that version is a required step. Code that used .NET components needs attention too: from version 22 the server runs on .NET 6, which breaks many older .NET references, and .NET interop is not available online at all.
Start with an inventory. Many NAV customizations were written years ago to fill gaps that standard Business Central now covers, and every one you retire is one you no longer convert, test and maintain.
What moves with your data, and what does not
When you migrate to the cloud, most business data moves, but some things are rebuilt rather than migrated:
- Users, permissions and record links are not migrated.
- Data in custom tables only moves if the extension that owns those tables is installed online and allows its data to be replicated.
- Companies migrate in batches, of up to ten at a time.
- Large databases migrate in stages: Microsoft suggests keeping each run under 30 GB. Online storage is measured after compression, so the online database is usually smaller than your SQL database.
Before migrating, clean up. Archiving obsolete history and trimming log and change tables shortens every dry run and lowers the storage you pay for later.
Online or on-premises?
Most companies now move to Business Central online. Microsoft releases two major updates a year, in April and October, and you choose when to apply each one within a five-month window. Infrastructure, backups and the platform are Microsoft's job.
On-premises is still available and gives you full control, but upgrades remain yours to run, and some newer capabilities appear online first or only online. If licensing is part of the decision, see Business Central licensing explained.
A realistic project plan
- Assessment. Version and cumulative update, database size, number of companies, integrations and a full customization inventory. The output is a scoped plan, not a guess.
- Decide per customization: retire it, replace it with a standard feature or an app, or rebuild it as an extension.
- Build and test the extensions against the target version, with automated tests where the logic is critical.
- Clean the data and rehearse. Microsoft recommends at least two dry runs in a sandbox. Never run the first attempt against production.
- Cut over with a runbook: a code freeze, owners for each step, a rollback plan, and training for users before go-live rather than after.
- Stay current. Plan for the twice-yearly updates from day one, so the next upgrade is routine rather than another project.
How long it takes depends mostly on the number of customizations and integrations, the data volume and how many companies you run. The assessment is what turns that into a real timeline.
We run NAV to Business Central projects end to end: the upgrade itself, data migration and rebuilding customizations as extensions.
Sources
- Microsoft Learn: Upgrade paths to Business Central
- Microsoft Learn: Migrate from Dynamics NAV
- Microsoft Learn: Customization playbook for NAV migrations
- Microsoft Learn: Plan and prepare for cloud migration
- Microsoft Learn: Update rollout timeline
- Microsoft Lifecycle: Dynamics NAV 2018 and the pages for earlier versions
Written by
Stefan Šošić
Co-founder & CEO, BCILITY · Microsoft MVP
Stefan co-founded BCILITY and is a Microsoft MVP. He writes about Business Central development, AL performance, telemetry and AppSource on his own blog.
