Microsoft Dynamics NAV Decommissioning — Controlled Retirement Before the 2026/2028 Cliff

Microsoft dynamics nav decommissioning is the controlled retirement of a NAV environment — SQL Server backend, NAV Server, NAV Web Services, NAV Web Client and any partner-built add-ons — after data has been migrated to a target system (typically Oracle Fusion or Microsoft Business Central) and the long-tail historical record has been archived to a queryable, retention-governed archive. Decommissioning is not just shutdown: it's the structured process of confirming all data is preserved (either in target or archive), validating compliance retention is intact, releasing licenses, terminating infrastructure, archiving final database backups for the residual retention tail, and producing a sign-off pack that satisfies internal audit, external audit, tax authorities and cyber-insurance review.

Microsoft's NAV support timeline creates two near-term cliffs that make microsoft dynamics nav decommissioning a board-level priority. NAV 2016 mainstream support ended April 2021 and extended support ends April 2026 — past that date, no security patches, no tax-table updates for jurisdictions like UK MTD or German GoBD, no Microsoft escalation path. NAV 2018 extended support ends January 2028. Older NAV versions (5.0, 2009, 2013, 2015) are already out of support entirely. Carrying an unpatched NAV environment past extended-support end exposes the organisation to audit findings, cyber-insurance exclusions, tax non-compliance and incident response gaps. Decommissioning ahead of the cliff converts a forced exit into a controlled retirement.

Eight steps: (1) Confirm migration to target (Fusion/BC) is complete and reconciled to the cent. (2) Confirm historical archive is populated, validated and retention-locked. (3) Run final parallel-month cycle to catch any late-arriving transactions. (4) Cut over external integrations (EDI, banking, payroll, tax submission) from NAV to target. (5) Switch NAV to read-only mode. (6) Run final database backup, hash-signed and retention-locked, as residual evidence. (7) Release NAV Server, NAV Client and SQL Server licenses; terminate infrastructure. (8) Issue decommissioning sign-off pack covering data preservation, compliance retention, license release and infrastructure termination — countersigned by IT, finance, audit and legal.

Typically 3–9 months. The lower end (3 months) applies when the migration scope was full (all data moved to Fusion or archive), no surprises emerge during parallel-run, and the organisation is single-tenant single-jurisdiction. The upper end (9 months) applies to multi-company multi-jurisdiction estates where each subsidiary needs jurisdiction-appropriate sign-off and the decommissioning has to wait for the final regulator submission cycle. Plan microsoft dynamics nav decommissioning to land at least 3 months before the relevant extended-support cliff — that gives buffer for surprises without forcing an unsafe shortcut.

Custom objects, C/AL/AL source code and partner add-on configurations have already been handled during the migration: required logic was replaced with Fusion equivalents (DFFs/EFFs, OTBI reports, REST integrations, process automation), and data was preserved in either Fusion or the long-term archive. Decommissioning handles the residual artifacts: source code archived to version control with retention tag, custom object FOB exports preserved in the archive for retrospective forensic queries, partner add-on license terminations coordinated with vendors. The result: nothing in the NAV environment is needed for ongoing operations, but everything is preserved for the residual retention window if needed.

Three preservation layers ensure compliance audit trail survives decommissioning intact. (1) Migrated data in the target system (Fusion) carries NAV-id cross-reference for retrospective lookup. (2) The historical archive holds the deep tail with full drill-back chain (G/L Entry → Customer Ledger → source document → attachments) under object-lock immutability for the SOX 7yr / GoBD 10yr / HMRC 6yr / SAF-T retention window. (3) The final NAV database backup is hash-signed and retention-locked as residual evidence — recoverable to a sandbox if a regulator audit absolutely requires the live NAV environment to be reconstructed, which in practice happens essentially never once a proper archive is in place.

Yes, with the read-only mode pattern. After Fusion cutover, NAV is switched to read-only — no new postings, no master maintenance, no document creation, but existing users retain login access to query historical records during a transition period (typically 60–180 days). This bridge gives finance, tax and customer-service teams time to migrate their query patterns to the historical reporting layer without losing access to familiar NAV reports. Read-only mode also reduces NAV Server licensing exposure (some Microsoft license terms apply lower-tier pricing for read-only access). Once the transition period closes, the NAV environment shuts down per the full decommissioning plan.

The pack is the legal evidence that decommissioning was performed correctly. Contents: data-preservation evidence (final reconciliation between NAV, Fusion target and archive — counts, sums, hash totals per company per period); compliance-retention evidence (archive object-lock policy, retention-window confirmation per jurisdiction, audit-log accessibility confirmation); license-release evidence (NAV Server, NAV Client, SQL Server license termination confirmations from Microsoft and partner vendors); infrastructure-termination evidence (server decommissioning logs, backup retention confirmations, network access removal); and sign-off signatures from IT, finance, internal audit, external audit, tax and legal. The pack is itself retention-locked alongside the archive.