Dynamics NAV Migration: How to Archive the Data and Decommission the System 

Somewhere on a rack in your data center, a SQL Server instance has been quietly posting invoices, running MRP, and closing month-ends since before most of your current finance team was hired. Nobody has touched its core code in years. Nobody fully remembers why the dispatch module works the way it does.

And yet, every regulator, every auditor, and every cyber-insurance underwriter who looks at it asks the same uncomfortable question: what happens to this system, and its data, the day Microsoft stops patching it?

That is the reason behind Dynamics NAV migration. It isn’t a single software upgrade. It’s a countdown. Microsoft’s Dynamics NAV product line has a hard expiration date attached to every version, and each one that lapses turns a stable, invisible piece of infrastructure into a governance liability.

This article walks through what Dynamics NAV migration actually means, why enterprises are racing to get off the platform, the hidden complexity that catches most of them off guard, a practical migration framework, a decommissioning checklist, and how to archive legacy NAV data.

What is Dynamics NAV migration?

Dynamics NAV migration is the structured process of moving a business off Microsoft Dynamics NAV (formerly Navision): its master data, transactional history, customizations, and integrations, into a new operating environment.

That destination can be Dynamics 365 Business Central (Microsoft’s cloud successor to NAV), another modern ERP such as SAP S/4HANA, Oracle Fusion, or NetSuite, or a hybrid setup where day-to-day operations move to a new platform while historical NAV data is preserved separately in a compliant archive.

It typically involves four intertwined workstreams:

1. Application migration – standing up the new ERP and configuring it to reflect current business processes.
2. Data migration – mapping and moving master data (customers, vendors, items, chart of accounts) and open transactions into the new system.
3. Data archiving – deciding what historical data doesn’t need to live in the new operational system but still has to be retained for audit, tax, or legal reasons, and moving it into a searchable, retention-governed archive.
4. Application Decommissioning – the formal, auditable retirement of the NAV application, database, servers, and licenses once migration and archiving are validated.

Why Enterprises Are Moving Out of Dynamics Nav

Dynamics NAV’s servicing lifecycle is the forcing function.

Microsoft’s mainstream support windows for legacy NAV versions have already closed, and extended support ends in stages: NAV 2016 support ends in 2026, NAV 2017 the year after, and NAV 2018, the final release of the product line, reaches the end of extended support in January 2028.

Older releases such as NAV 2009, 2013, and 2015 are already unsupported entirely.

Once a NAV version passes its extended-support date, several things stop happening at once:

• No further security patches, which leaves the environment exposed to newly discovered vulnerabilities indefinitely.
• No tax-table updates, which is a serious problem for businesses in jurisdictions with statutory digital-tax requirements such as UK Making Tax Digital VAT filings, German GoBD record-keeping rules, or country-specific SAF-T reporting across the EU.
• No Microsoft escalation path if something breaks in production.

Beyond the support cliff, four other pressures show up consistently in enterprise decision-making:

Gartner has estimated approximately 40% of infrastructure systems across asset classes face technical debt challenges.

Industry benchmarks confirm that legacy maintenance consumes 60–80% of enterprise IT budgets, leaving only 20–40% for new capabilities and innovation.

For a NAV estate specifically, that shows up as SQL Server licensing that never gets any lighter, a shrinking pool of consultants who still know C/AL, and audit-retrieval requests that take days instead of minutes because nobody remembers how the custom dispatch module actually queries data.

Dynamics NAV Migration Complexities

Ask any team that has been through a NAV migration, and the same handful of surprises come up again and again.

Data locked inside customizations doesn’t move by itself

NAV’s classic customization model let partners and internal teams modify base application code directly using C/AL. That was normal practice for a decade. But Business Central online locks the base application, and everything custom has to be delivered through extensions.

Data sitting in custom tables or modified fields has nowhere to land in the new system unless someone rebuilds the matching structure, and the “Modified” flag inside NAV that’s supposed to flag changed objects can be unreliable, so many companies underestimate how much customization they’re actually carrying.

A simple upgrade is really a multi-stage technical project

Microsoft’s supported path doesn’t go directly from an older NAV version to the cloud.

It requires an intermediate upgrade to Business Central version 14 on-premises; the last release that understood both the old C/AL development model and the newer AL extension model, followed by a further upgrade to a current on-premises version before a cloud migration tool can even run.

Each hop involves code conversion, database compatibility checks (SQL Server 2016 or later, with a specific compatibility level), and testing.

Third-party add-ons rarely have a clean cloud equivalent

Most long-running NAV environments lean on ISV add-ons for EDI, shipping, payroll, or industry-specific workflows. Those NAV-era add-ons typically don’t run in Business Central online, so each one needs an AppSource replacement, and the data those add-ons generated needs its own migration plan.

Some vendors have gone out of business entirely, stranding their data unless it’s proactively archived.

Depreciated technology has no home in the cloud

Patterns that were completely normal in NAV – .NET add-ins, certain Option field types, direct SQL access, either don’t exist in the cloud version or need to be redesigned using Azure Functions, external APIs, or newer field types.

Users and access controls start over

Business Central online authenticates through Microsoft Entra ID, not NAV’s Windows-based logins, so provisioning, permission sets, and role centers all need to be rebuilt and tested before go-live.

History has a price tag

A NAV database that has been accumulating posted documents, change logs, and attachments for fifteen years can be enormous.

Carrying all of that into a new cloud system inflates both migration time and ongoing storage costs, which is exactly why archiving, not blanket migration, is usually the smarter move for anything beyond two or three years of operational history.

Compliance retention windows don’t disappear just because the system does

Financial records typically need to survive for 6–10 years depending on jurisdiction; SOX in the US, GoBD in Germany, HMRC rules in the UK, SAF-T requirements across much of the EU. None of those clocks reset because you replaced the ERP.

A Practical Dynamics Nav Migration Framework

Rather than treating migration as one monolithic project, most successful programs break it into five phases, run largely in sequence with some overlap.

A decision that shapes everything downstream: should this be a full upgrade or a reimplementation?

A full upgrade is only realistic when the business is on a recent NAV version, customizations already live in extensions rather than modified base code, and processes haven’t drifted much from how the system was originally configured.

In practice, that combination is uncommon in NAV environments over eight to ten years old, which is why a clean reimplementation, carrying forward only the data and integrations still needed, has become the more common route.

Depending on customization depth and data volume, projects typically run anywhere from four months for a lightly customized environment to well beyond eight months for a heavily customized, multi-entity estate.

Dynamics Nav Data Archiving: Deciding What to Keep, and Where

Not every byte in a NAV database deserves a seat in the new operational system. A useful three-way split:

• Migrate: master data (customers, vendors, items, chart of accounts, dimensions), open transactions (unpaid invoices, open orders), and opening balances.
• Archive: posted historical transactions beyond your active reporting window, superseded change logs, inactive records, and data generated by add-ons being retired; all of it kept in a governed, searchable, immutable archive rather than deleted or left inside a dormant NAV instance.
• Purge (carefully): data with no retention obligation and no business value, removed only after legal and compliance sign-off.

A properly designed NAV data archive should provide:

• Immutability at ingestion (WORM-style storage) so archived data can’t be silently altered, something a simple backup or a cold-storage bucket does not provide.
• Metadata-driven search so finance, tax, or legal teams can retrieve a specific posted document, customer ledger entry, or attachment in seconds rather than reviving the old application.
• Referential context, the drill-back chain from a G/L entry to its source document and attachments needs to survive the move intact.
• Jurisdiction-aware retention rules, since a US subsidiary’s 7-year SOX retention clock and a German entity’s 10-year GoBD clock rarely line up.

This is also where the “archive-first” principle pays off financially: archiving historical NAV data before migration typically strips out the majority of the data volume that would otherwise have to move, shrinking both migration scope and the size (and cost) of the new production database.

Dynamics Nav Decommissioning Checklist

Migration and archiving are not the finish line, decommissioning is. A NAV environment isn’t safely retired until it’s been switched off in a way that can survive an audit five years from now. Use this checklist as a working document.

Pre-decommissioning discovery

• NAV version, database size, SQL Server version, and customization inventory documented
• Every ISV add-on and integration mapped, with a confirmed replacement or archive plan
• Data classified by retention obligation and jurisdiction
• Cost baseline captured (licenses, infrastructure, support hours, audit retrieval time)

Stakeholder and governance setup

• RACI defined across IT, finance, legal, and compliance
• Named retention owner and legal-hold owner appointed
• Executive sponsor and budget confirmed

Reconciliation and cutover

• Final reconciliation between NAV, the new target system, and the archive; counts, sums, and balances tie out to zero variance
• Integrations (EDI, banking, payroll, tax submission) cut over and parallel-tested
• NAV switched to read-only for a defined transition window (commonly 60–180 days) so users can adjust before full shutdown

Shutdown

• Final hash-signed database backup taken and retention-locked as residual evidence
• NAV Server, NAV Client, and SQL Server licenses formally released
• Partner add-on contracts terminated
• Network access removed and infrastructure decommissioned

Sign-off

• Sign-off pack assembled: data-preservation evidence, retention-policy confirmation, license-release confirmation, infrastructure-termination logs
• Countersigned by IT, finance, internal audit, external audit, tax, and legal

Essential Dynamics NAV Decommissioning Considerations

These are critical Dynamics NAV decommissioning considerations most teams overlook:

• The “read-only bridge” period. Rather than an abrupt cutoff, most well-run decommissioning projects keep NAV alive in read-only mode for a few months so finance and customer-service teams can adjust their query habits gradually, rather than losing access to familiar reports overnight.
• Sustainability accounting. Running duplicate infrastructure, the old NAV servers and the new platform, for longer than necessary has a real energy and carbon footprint. As more companies report against net-zero commitments, timely decommissioning is quietly becoming part of ESG reporting, not just an IT housekeeping task.
• Zombie license and contract exposure. Long after a company believes it has moved-off NAV, it’s common to find dormant NAV Server, SQL Server, and third-party add-on contracts still auto-renewing because nobody formally terminated them. A decommissioning sign-off pack should explicitly capture license-release confirmations, not just technical shutdown steps.
• AI-readiness of archived data. Historical NAV data isn’t just a compliance artifact, cleaned, well-tagged archives can feed retrieval-augmented reporting and analytics tools long after the source system is gone, provided the archive was built with structured metadata rather than dumped as flat exports.
• Multi-entity, multi-jurisdiction complexity. Enterprises running NAV across several legal entities or countries face a harder decommissioning problem than the single-company case: each entity may need its own retention sign-off, its own tax-authority confirmation, and its own timeline, which is why multi-company estates often take twice as long to fully retire as single-tenant ones.

Final Track Powered by Archon

This is the part of the NAV journey where most internal teams and even experienced implementation partners run out of depth, not because migrating master data is hard, but because archiving and decommissioning require a fundamentally different skill set: retention law, immutable storage architecture, and audit-grade evidentiary design.

This is exactly what Archon is purpose-built for. Rather than treating your legacy NAV database as something to migrate in full or simply back up and forget, Archon separates the problem into two clean tracks: get the operational data your business still needs into the new platform quickly, and move everything else into a governed, independent archive that stays searchable, tamper-evident, and compliant for as long as regulators require, without keeping the NAV application itself alive.

Concretely, Archon helps with:

• Structured extraction from NAV, including custom tables and ISV add-on data that standard migration tools skip, preserving the relationships between ledger entries, source documents, and attachments.
• AI-driven data classification, profiles structured/unstructured NAV data, auto-detects PII, retention category, duplicates, and relationship gaps before anything is archived.
• Immutable, metadata-driven archiving, anomaly detection, RBAC, and lineage/provenance tracking that keep the archive audit-ready for the entire retention window. So, finance and audit teams can retrieve a decade-old, posted invoice in seconds through a simple search interface, rather than reviving a decommissioned server.
• Jurisdiction-aware retention orchestration, applying the right retention clock; SOX, GoBD, HMRC, SAF-T, or others – automatically per legal entity, with legal-hold support built in.
• Legacy system decommissioning trail, generating the reconciliation, retention, and license-release evidence that auditors and cyber-insurance reviewers actually ask for.

The Real ROI of Retiring NAV with Archon

For a mid-sized enterprise carrying a decade of NAV history, that translates into real numbers: no more SQL Server and NAV licensing renewals, no more specialist consultants billed to keep an aging system alive, faster monthly close because the production database isn’t bloated with dormant history, and an audit response measured in minutes rather than the days it currently takes to track down someone who remembers how the old system was built.

Returns of Application decommissioning with Archon:

• The infrastructure return – immediate cost drop once NAV is switched off
• The migration return – a smaller, faster project because 60–80% of data never needs to move
• The compliance return – risk priced down through automated retention and audit-ready lineage
• The compounding return – the archive itself becoming a queryable asset, not just a liability

NAV won’t retire itself. Let’s plan the exit with a structured assessment of your current Dynamics NAV environment.