Someone in finance has already run the numbers on what it costs to keep the lights on, and someone in IT has flagged that the version you're on stopped getting mainstream support a while ago. Somewhere in the last twelve months, a partner or an auditor has asked, not unkindly, what the plan is for when NAV stops being patched at all.

There is a plan available, and most of what you'll read about it online was written by someone selling one specific outcome. This piece sets out the three real Dynamics NAV end of life replacement options, what each actually costs in time and disruption, and how a CFO or ops director without an ERP background can tell which one fits.

Dynamics NAV support ends in stages: extended support finishes in January 2027 (NAV 2017) and January 2028 (NAV 2018). There are three real options: re-implement onto Business Central, run a wider ERP selection if customisation is heavy, or stay put as a risk decision with a deadline.

When does NAV support actually end?

Microsoft stopped selling new NAV licences some time ago, and mainstream support has closed for every version of the product. That much is settled. What's less understood is that extended support, the bit that still delivers security patches and compliance updates, has not ended for everyone at once.

NAV 2017 runs out of extended support in January 2027. NAV 2018 follows in January 2028. If you're on an earlier version, you're already past the point where Microsoft will patch a newly discovered vulnerability, and you've likely been told that by whoever manages your infrastructure or your cyber insurance renewal. After the relevant date, there are no more security patches and no more compliance updates. That's not a vendor scare tactic. It's the published lifecycle position, and it's the fact that should be driving the timeline on your board pack, not a supplier's sales cycle.

Why "just upgrade to Business Central" is not the full sentence

Dynamics 365 Business Central is Microsoft's designed successor to NAV, built on the same underlying data model. That relationship is real, and it's the reason most of the advice you'll find treats the move as an upgrade.

It isn't one, in the sense that word usually implies. NAV customisations, and mid-market NAV installs are almost always customised somewhere, do not carry across automatically. The extensions and the modified processes, plus the odd report someone built for a customer who left the business four years ago, all have to be assessed, rebuilt, or deliberately dropped. A NAV to Business Central migration is closer in cost and disruption to a re-implementation than to a version upgrade, and budgeting it as the latter is the classic mistake in this decision.

That doesn't make Business Central the wrong answer. For a lot of NAV estates it's the right one. It makes it a decision that deserves the same scrutiny you'd give any other ERP selection, not a foregone conclusion because the data model happens to be familiar.

Option one: Business Central as a re-implementation

For organizations whose NAV customisation load is moderate and whose core processes haven't drifted far from how the system was originally designed to work, Business Central is usually the sensible default. The commercial and technical continuity with NAV genuinely lowers risk versus a move to an unfamiliar platform.

Cost it properly, though. A NAV to Business Central migration involves a data model assessment, a decision on every customisation (rebuild, replace with standard functionality, or retire), a testing cycle that treats the new system as new, and change management for users who will find some things familiar and other things not. Firms that budget this as a technical upgrade and staff it accordingly are the ones who end up in a recovery conversation later.

Option two: a wider selection

When the customisation load is heavy, or when the underlying business processes have drifted a long way from anything a standard ERP assumes, a Business Central-only evaluation can miss the better answer. Acumatica, Epicor and Sage X3 are commonly evaluated alongside Business Central in these situations, each with a different fit depending on sector, growth trajectory and how much of the estate is genuinely custom versus configured-standard-in-disguise.

This route costs more time upfront: a proper selection process, weighted against your actual requirements rather than a vendor's demo script, typically runs longer than a straight Business Central migration project. It's worth that time when the alternative is migrating heavy customisation onto a platform that was never the best functional fit, just the most familiar one.

Option three: staying put, honestly assessed

There is a third option, and it deserves to be named as a decision rather than left as a default by omission. Staying on NAV past the support deadline is a risk position. It can be the right one for a defined, short period, for instance while a wider selection is properly run, provided the risk is owned explicitly. That means naming what happens to your cyber insurance renewal, what your auditors will say about a system running without vendor security patches, and how much integration debt is quietly accumulating with every other system that still has to talk to it.

What it cannot be is a plan by default, arrived at because nobody put a date in the diary. If staying put is the call, put a number on the risk, a date on the reassessment, and a name against who owns that decision. That's a governance position a board can defend. "We hadn't got round to it" is not.

How to choose between the NAV end of life replacement options

The honest starting point is an assessment of how far your NAV instance has drifted from a standard implementation, not a vendor's roadmap for where they'd like you to land. Heavy customisation and process drift point towards a wider selection. A relatively clean core with a manageable list of extensions points towards Business Central. A short, deliberate delay with the risk owned and dated is sometimes right, but only ever as a stated position, never as the absence of one.

Why most advice online has a destination already in mind

Search for this question and the majority of what comes back is written by Business Central implementation partners. That's not a criticism of their competence; it's a structural fact about who publishes content on this topic. Their advice starts from the answer they sell and works backwards to the justification. A genuinely independent view has to be willing to say Business Central isn't always the right call, and to mean it.

How Assured Velocity runs this

We don't implement ERP systems, and we aren't aligned to any of the vendors above. That's deliberate: it means we have no destination to steer you toward, and the recommendation at the end of a selection is the one that fits your business, not one that fits ours.

The entry point is a fixed-scope Business Review from £5k, delivered in 14 days: an independent read on where your NAV estate actually sits, what a re-implementation onto Business Central would really cost you, and whether a wider selection is worth the extra time. We are a young firm and won't claim a track record we haven't earned, but the independence is real and it's the reason to bring an outside view into this decision before the extended support clock runs out.

If your NAV support deadline is on the calendar and the plan isn't, read more on how we approach ERP selection on the Technology Advisory page, or go straight to the diagnostic: book a Business Review and get a straight answer inside 14 days.

Is the NAV deadline on the calendar but the plan isn't?

A fixed-scope Business Review gives you an independent read on where your NAV estate sits and which of the three options fits. Delivered in 14 days, senior-led throughout.

Book a Scoping Call