The dates
If you are running Dynamics NAV — many people still call it Navision — your version has a published end date, and for several versions that date has already passed.
| Version | Support ends | Status today |
|---|---|---|
| NAV 2009, 2013, 2013 R2, 2015 | Already passed | Entirely unsupported |
| NAV 2016 | 14 April 2026 | Passed |
| NAV 2017 | 11 January 2027 | Ends within months |
| NAV 2018 | 11 January 2028 | The final release of the product |
Microsoft stopped releasing NAV versions after NAV 2018 and directs customers to Dynamics 365 Business Central, which is built on the same codebase. There is no NAV 2019 waiting, and there will not be one.
What actually stops, and what does not
This is where most of the confusion sits, so it is worth being precise. On the day support ends:
- ✓NAV keeps running. Nothing switches off. Your users log in the next morning exactly as before. This is why the deadline is easy to ignore.
- ✓Security updates stop. The system holding every financial record you have stops receiving fixes. That is the part that matters, and it gets worse every month rather than all at once.
- ✓Regulatory and tax updates stop. Payroll tables, tax rates and reporting formats no longer get maintained for you.
- ✓Support ends. When something breaks, there is no escalation path to Microsoft.
- ✓The platform underneath ages too. NAV 2018 and earlier expect particular Windows Server, SQL Server and .NET versions. Those have their own end dates, and the stack gets harder to stand up every year.
So the real deadline is not the day it stops working. It is the day you decide you are no longer comfortable running your accounting on an unpatched system — which for most auditors and insurers arrives earlier.
The decision you actually have to make
Almost everyone lands on moving to Business Central. The harder question, and the one that gets deferred, is what happens to the history.
A NAV database is often ten to twenty years deep. A migration does not take all of it. Migration guides consistently recommend bringing two to three years of posted history into Business Central and archiving the rest, because loading a decade of transactions inflates storage cost, slows the project and clutters reporting in the new system.
That advice is sound. But "correctly left behind" still means left behind, and the questions do not stop:
- ✓Auditors. "Show me every invoice to this customer in FY2019, with the supporting documents."
- ✓Tax reviews. Detail from years before the migration, on request, at short notice.
- ✓Disputes and warranty claims. "We bought this in 2017 — what were the terms and the serial number?"
- ✓Staff turnover. The person who knew NAV leaves. Their replacement has never seen it and never will.
Planning backwards from your date
The useful move is to work backwards from your support date rather than forwards from today:
- ✓Decide the split before the migration is scoped. How many years go into Business Central, and where the rest lives. Writing this down early stops it becoming a cutover-week argument.
- ✓Preserve the history before you switch anything off. Extracting from a live, working NAV is straightforward. Extracting from a system nobody can start any more is a project.
- ✓Verify before you decommission. Whatever you keep the history in, check its totals against NAV account by account while NAV is still there to check against.
- ✓Only then retire the server. The Windows Server licence, the SQL Server licence, the VM and the backup job all exist to hold data. When the data is safely elsewhere and proven, those costs stop.
The options for where that history lives — a dormant NAV VM, a SQL backup, a database copy in Azure, a subscription viewer, or a purpose-built archive — are compared in ways to keep NAV history. What typically moves and what stays behind is covered in NAV history after a Business Central migration.