Dynamics NAV end of support: what to do with your ERP history

What does end of support mean for a NAV system?#

End of support for Dynamics NAV means Microsoft stops servicing that version: non-security fixes stop when mainstream support ends, and security updates stop when extended support ends. Nothing is switched off, and the data stays in the NAV database, which in most installations runs on SQL Server, for as long as you keep the server.

The practical risk grows over time. An unsupported NAV version usually runs on older SQL Server and Windows Server releases with their own end dates, and cyber insurers, auditors and customer security questionnaires often ask about unsupported systems. Partners also tend to move their people to newer products, so finding someone to fix a broken report or a failed job queue gets harder.

Microsoft's direction for the product line is Business Central, NAV's successor. For most companies that makes end of support a migration decision, and every migration forces a choice about history.

Verify your own support timeline first#

NAV support dates differ by release, so the first step is to confirm exactly what you run and what applies to it. Many older NAV versions are already past their end dates, and later releases such as NAV 2018 have published dates of their own; check Microsoft's lifecycle documentation rather than a partner slide or a forum post.

• 1The NAV version and cumulative update installed, from the client's About screen or the database.
• 2The mainstream and extended support end dates for that version, from Microsoft's lifecycle pages.
• 3The SQL Server and Windows Server versions underneath, and their own lifecycle dates.
• 4Your partner's support terms for that version, including any cut-off of their own.
• 5Whether your NAV licenses allow a read-only instance to keep running after you migrate.
• 6Every add-on and customization, and whether its vendor still supports it.

Four paths for NAV history#

Every NAV exit follows one of four paths for history, and many companies combine two of them. The path decides what auditors, the tax team and operations can still see after go-live.

Which NAV history should finance protect?#

Finance should protect the NAV history that answers questions after the old system is gone: audit samples, tax inquiries, warranty and product claims, customer disputes and cost studies. In NAV, most of that history sits in a handful of ledger and posted-document tables.

Keep the links between them. Item ledger entries without document numbers, or production orders without their routing lines, lose most of their meaning once NAV can no longer show how they connect. Ask your auditors and tax advisers how long they expect detail to stay accessible, because record-keeping obligations can outlast the old server by years.

What does it cost to keep an old NAV server alive?#

Keeping NAV running after migration costs more than the server. The company still pays for hosting or hardware, Windows and SQL Server licensing, backups, security monitoring and someone who knows how to restart the service tier when it stops.

A read-only NAV instance is often the right answer for a transition period, while staff still look up old orders every day. As lookups fall away, an extracted archive with documented fields usually becomes cheaper and safer than an unsupported application on an unsupported operating system.

Ask the partner to design the archive before go-live, not after. Extracts are easiest while the people who customized NAV are still on the project and still remember what the custom tables mean.

Illustrative: a gearbox manufacturer leaves NAV behind#

Illustrative: a fictional maker of industrial gearboxes has run an older NAV version for many years, with custom tables for test-stand results and a heavily modified production order module. The CFO chooses a fresh start in Business Central because the customizations would make a technical upgrade slow and costly.

Before cutover, the team extracts G/L entries, item ledger and value entries, posted documents, production orders with routing lines and capacity entries, item tracking and the custom test-stand tables into an archive database. Each table gets a short field dictionary, and a backup of the final NAV database is kept as a fallback. The NAV server runs read-only until order lookups stop, then shuts down.

During the archive review, the operations director notices that production orders, test results and warranty returns connect through serial numbers. The CFO adds a line to the board pack: the archive is kept for compliance and is also a candidate for a metadata-only data licensing fit check, with customer-specified designs excluded.

Your NAV archive can be more than insurance#

A NAV archive can have value beyond compliance when it records how the business actually ran: quotes that became orders, production orders with actual against expected time, purchase exceptions and lot-traced returns. Operational history like this, from established manufacturers and distributors, is the kind of record AI developers license to train and evaluate models that work inside ERP systems.

SourceX reviews that kind of archive through the SourceX five-step transaction: Supply, Rights, Preparation, Approval and Delivery. Supply uses metadata only, such as tables, years covered and record families, so no data moves during the initial assessment. Customer and supplier pricing, personal data and customer-owned designs are handled in Rights and Preparation, and the company approves every release. The data is licensed, not sold outright, and the company keeps ownership.