If your finance team still logs into NAV every morning, you probably already know the system isn’t the problem. It does its job, is customised to how you work, and everyone knows where things live.
The problem is that Microsoft’s support is running out, and the longer you put off the move, the more tangled it becomes.
This guide is for anyone who must plan that move. It covers where each NAV version stands, whether to upgrade or start over, the route Microsoft supports, and the part that usually causes the most trouble: custom code.
Why Now Is the Time to Decide
Business Central is the cloud successor to NAV. It runs on Azure and is built in AL, whereas NAV was built in C/AL. The two are related but aren’t the same product, and that difference is what makes this a project rather than a version bump.
In our experience, waiting rarely makes it easier. More transactions carry over, more custom code to untangle, and fewer people left who remember why a particular modification was written in the first place. A migration done with time to spare is calmer than one forced by an expiry date.
Check Where Your NAV Version Stands
Start with the dates, as they set the pace. Based on Microsoft’s lifecycle policy, as summarised by several Dynamics partners, here’s the picture.
| NAV version | Extended support |
| NAV 2015 | Ended January 2025 |
| NAV 2016 | Ended April 2026 |
| NAV 2017 | Ends January 2027 |
| NAV 2018 | Ends January 2028 |
Anything older is already outside every support window. Once support ends, there are no security patches or compliance updates, which poses a real risk for any organisation handling financial data.
We’re relying on published summaries here, so confirm the current position on Microsoft’s own lifecycle pages before you plan around a date.
Upgrade or Start Again
There are two main routes, and a hybrid is also common.
A technical upgrade carries your existing NAV database into Business Central. Once converted, your data, history, and customisations all come across. It suits organisations whose data is in decent shape and whose customisations still make sense.
A reimplementation sets up a fresh Business Central environment and brings across only what you need, such as master data and open balances.
It suits organisations with heavily customised systems, years of workarounds, or processes that have changed since NAV was set up. Microsoft also provides a Business Central 14 reimplementation tool for this route.
Neither is automatically better. The honest way to choose is to look at three things: how clean your data is, how much custom code you carry, and how much you want your processes to change. If the answer to the last one is “quite a lot”, a reimplementation usually pays for itself.
The Staged Path Microsoft Supports
You can’t jump straight from an old NAV version to the latest Business Central. Microsoft supports a staged route, and its guide to migrating NAV to Business Central online sets it out.
- NAV 2015 to 2018 upgrade to Business Central version 14 on-premises, then to a supported on-premises version (version 25 or later), then to Business Central online
- NAV 2013 and 2013 R2 go to NAV 2018 first, then follow the same route
- NAV 2009 goes via NAV 2013 or 2015, then to NAV 2018, then the same route
- Both the upgrade route and the reimplementation route start by reaching Business Central version 14.
For the current release, one summary of the path has NAV 2015 to 2018 going through version 14, then version 25, then version 28, and MS Dynamics World’s overview explains why the hops exist. Your partner will map the exact route for your version.
What Happens to Your Customisations
This is where most of the effort goes, so it deserves a section of its own.
Current versions of Business Central are AL- and extension-based only, and NAV’s C/AL code can’t run in them. Before you can migrate to Business Central online, every C/AL customisation must be converted into an AL extension, unless you take the Business Central 14 reimplementation path.
Microsoft’s tooling helps, including code conversion and data upgrade tools, but conversion isn’t a button you press once.
The approach that works is to triage. Take an inventory of every customisation and sort each one into one of three groups.
- Keep and rebuild. It represents real value to the business, so rebuild it as an extension.
- Replace. Business Central now provides the same functionality in standard features, or an app covers it.
- Retire. It was a workaround for a NAV limitation that no longer exists.
You’ll often find the third group is bigger than expected. Many old modifications can simply be dropped because Business Central covers them out of the box, which shrinks the project considerably.
Data, Testing and Cutover
Clean the data before you move it, not afterwards. Duplicate customers, vendors and items, and old records nobody uses, all travel across happily unless you stop them.
Decide how much history to carry. Seven years of detailed transactions might be necessary for audit, or ten years of closed history might be dead weight.
Then map how each NAV table and field maps to Business Central, and test with real users in a sandbox using real scenarios. Posting, month-end, reporting and every integration should be tested before cutover day.
If NAV talks to a CRM or other systems, those connections need rebuilding too, which is where our guide to Business Central and Dynamics 365 CE integration and our piece on a single customer view are useful.
Plan the cutover itself carefully: a freeze on changes, a final data load, and a reconciliation that proves the numbers match before anyone relies on the new system.
Life After Go-Live
Moving to Business Central online isn’t only about avoiding an expiry date. It unlocks features NAV never had, including Copilot and the sales and purchase agents we describe in our guide to agentic ERP in Business Central.
Which AI features are available depends on your deployment option, so check this when you decide between cloud and on-premises.
If you’re new to the platform, our Business Central guide explains what it does and who it suits.
Final Thoughts
A NAV migration goes well when you make early, evidence-based decisions: which version you’re on, how clean your data is, and which customisations deserve to survive.
The technology path is well documented. The hard part is the customisation triage and the data, and that’s where an experienced partner earns its fee.
Our D365 migration and Business Central services team plans and runs these moves, from the first inventory of customisations through to cutover and support.
As an ISO 27001 certified Microsoft partner, we treat data protection as part of the plan, not an afterthought.
Book a free assessment, and we’ll review your NAV setup and tell you honestly which route makes sense, no hard sell.
Frequently Asked Questions
Can I upgrade directly from NAV to the latest Business Central?
No. Microsoft supports a staged route. Upgrade from NAV 2015 to 2018, then to Business Central version 14, then to a later on-premises version, and finally to the current release or to Business Central online.
Is Dynamics NAV still supported?
Support varies by version. NAV 2016 and earlier are out of extended support. NAV 2017 runs until January 2027, and NAV 2018 until January 2028. Check Microsoft’s lifecycle pages for the current status.
What happens to my C/AL customisations?
They can’t run in the current Business Central. On the full migration path, they must be converted to AL extensions, replaced by standard functionality or apps, or retired if they were workarounds.
Should we upgrade or reimplement?
Upgrade if your data is clean and your customisations still make sense. Reimplement if your system is heavily customised, full of workarounds, or your processes have changed. A hybrid approach is also common.
Can we move NAV straight into Business Central online?
Microsoft supports migration to Business Central online from supported NAV versions, but NAV must first be upgraded to a supported Business Central on-premises version.
