Dynamics NAV End of Support: What to Decide Before January 2028

Your company has run on Dynamics NAV for ten or fifteen years. It works. The people who use it know it, the partner who built it still answers the phone, and every customisation has a reason, even if nobody remembers it. The upgrade to Business Central has been on the list for three years, and every year something more urgent came first. The Dynamics NAV end of support dates are now close enough that it cannot wait for another year.

Microsoft’s extended support for NAV 2017 ends in January 2027. For NAV 2018, the last version, it ends in January 2028. Older versions are already out of support. Below is what those dates actually change, the three realistic options, and a plan that gets you off NAV before the date rather than after it.

The Dynamics NAV end of support dates

According to Microsoft’s lifecycle pages, both versions follow the fixed lifecycle policy:

• Dynamics NAV 2017: mainstream support ended in January 2022; extended support ends on 11 January 2027.
• Dynamics NAV 2018: mainstream support ended in January 2023; extended support ends on 11 January 2028.
• NAV 2016 and older: already past the end of extended support.

If you are not sure which version you run, ask your partner or look at the version shown in the client. Many companies that say “we run NAV” turn out to be on NAV 2013 or 2015, which means the date has already passed.

What end of support actually changes

NAV does not stop working on 12 January. Nothing switches off. What stops is Microsoft’s side: no more security updates, no more fixes, and no Microsoft support if something breaks. The practical consequences arrive more slowly, and that is exactly why they are easy to underestimate.

• Security: the NAV server, and often the Windows and SQL Server versions underneath it, stop receiving patches. Your insurer, your auditor or a large customer’s supplier questionnaire may start asking about that.
• Regulation: e-invoicing and e-reporting changes keep coming. Belgium’s Peppol obligation arrived in 2026, Germany’s issuance obligation starts in 2027. On an unsupported version, every new requirement is a custom build.
• People: the developers who know C/AL, the language classic NAV customisations are written in, are getting fewer. Partners are moving their people to Business Central. Each year the same change costs more and takes longer.
• Infrastructure: NAV usually runs on a server in your own building or a hosting contract. The hardware and operating system age with it.

Three realistic options

Upgrade to Business Central

Business Central is Microsoft’s successor to NAV, and for most NAV users it is the natural next step. The data model will feel familiar, and Microsoft provides migration tools for the data. What does not move by itself is the customisation: code written in C/AL has to be rewritten as extensions or, better, replaced by standard functionality that did not exist when the original was built. The honest first step is an inventory of every customisation, with a decision for each: keep, rebuild, or drop.

Re-implement on a different ERP

If NAV was chosen fifteen years ago for a business that looks very different now, perhaps after an acquisition or a change of model, it is worth asking whether Business Central is still the right fit. A re-implementation is more work than an upgrade, but it is also a chance to design the processes for the company you are now. The same questions apply as in any ERP selection.

Stay on NAV for now, deliberately

For a small number of companies, staying on NAV for a limited period is a reasonable choice: a sale of the business is planned, a group-wide ERP decision is pending, or the system is being retired. If that is you, write the decision down, put an end date on it, and reduce the risk: isolate the server, restrict access, and have a plan for regulatory changes. Staying by default is not the same thing.

A plan that works back from January 2028

Partner guides give very different durations for a NAV migration, and your own will depend on the number of customisations, the quality of the data and how much time your people can give. We have delivered full ERP implementations in 12 weeks when the scope was tight, as at Waterlogic Czech Republic, but a tight scope is a decision, not an assumption. Work backwards:

1. This quarter: confirm your NAV version and its date, list every customisation and interface, and decide between upgrade, re-implementation or a deliberate stay.
2. Early 2027: choose the partner and the scope. Drop the customisations nobody uses. Clean the master data while you still have time to do it properly.
3. Mid 2027: build and test. Run at least two test migrations with real data.
4. Pick a go-live that is not in the last weeks of the year. A go-live on January 1 has its own risks, and doing it on the same weekend your support ends leaves no safety net.
5. After go-live: plan for hypercare and the first year-end close on the new system. Those are part of the project, not after it.

The bottom line

Dynamics NAV end of support does not stop your business on a given day. It makes every year on NAV a little riskier and a little more expensive, and it takes away the option to choose your own timing. Confirm your version, inventory the customisations, decide between upgrade, re-implementation or a deliberate stay, and set a go-live date that leaves a margin before January 2028. The companies that start now choose their project. The ones that wait get the project that is left.

How to Run a 12-Week ERP Implementation

Should You Go Live With Your New ERP on January 1?

Your First Year-End Close on a New ERP: A Practical Plan

Case study: Waterlogic Czech Republic, a production-ready ERP in 12 weeks

Sources

Microsoft Lifecycle: Dynamics NAV 2018

Microsoft Lifecycle: Dynamics NAV 2017