Microsoft Dynamics NAV Migration Best Practices — Lessons From Dozens of NAV-to-Fusion Programmes

Seven microsoft dynamics nav migration best practices show up across every successful NAV-to-Fusion programme. First, inventory C/AL/AL before scoping — never accept a fixed-fee proposal before the Object Designer crawl is complete. Second, triage partner add-ons (Anveo, ChargeLogic, Continia, Insight Works) explicitly with retire/replace/keep decisions per add-on. Third, sequence multi-company database extraction (NAV's per-company segmentation makes intercompany reconciliation a project of its own). Fourth, design the compliance archive (GoBD, HMRC, SAF-T) before the first extract — retention rules drive extraction scope. Fifth, build the trial-balance reconciliation engine before the bulk load — not as a post-hoc Excel exercise. Sixth, parallel-run for 1–2 month-end cycles minimum. Seventh, plan the NAV decommission window — read-only mode, archive verification, licence-stack retirement coordination.

The C/AL → AL inventory is the single most under-scoped part of most NAV-to-Fusion projects. Microsoft dynamics nav migration best practices say: run the Object Designer crawl in week 1, not month 3. Enumerate every custom table (typically in the 50000-99999 partner range), every custom field on standard tables (Customer 18, Vendor 23, Item 27), every modified standard object, every custom codeunit, every custom page, every custom report (RDLC, Word layout), every XMLport. Classify by business purpose: retire (zero update in 36 months), replace (build Fusion equivalent), preserve (DFF/EFF/OTBI), or rebuild (Visual Builder / OIC). The inventory drives the crosswalk effort estimate; without it, the budget is fictional. Syntra ETL ships the Object Designer crawler so the inventory takes 1–2 weeks rather than 8–12 weeks of consultant-led enumeration.

Partner add-ons are the second-most-common project-derailment source. Microsoft dynamics nav migration best practices for add-on triage: per-add-on retire/replace/keep decision, documented with sign-off. Anveo eCommerce data typically routes to Fusion CX or Salesforce + Fusion. Continia OPplus document handling replaces with Fusion AP Automation. ChargeLogic Payments replaces with Fusion Payments + bank-direct integration. Insight Works WMS replaces with Fusion Inventory + WMS Cloud. Each decision drives extraction work (Continia tables, ChargeLogic vault metadata, Anveo eCommerce data, Insight Works mobile WMS data) and crosswalk work to the Fusion target. Add-ons not surfaced in week 2 surface in week 14 as change orders — the rule is full add-on inventory before scope is signed.

NAV's per-company database design (Company1, Company2, Company3 as separate database tables within one SQL Server instance) creates sequencing complexity not present in single-database ERPs. Microsoft dynamics nav migration best practices for multi-company: extract all companies in parallel against a SQL Server read replica (no production-server load). Reconcile intercompany G/L Entry pairs at the source before extraction (intercompany imbalance in NAV is intercompany imbalance in Fusion). Map each NAV company to its Fusion BU + ledger early — currency, COA, statutory framework, fiscal calendar. Sequence parallel-run by company so dress-rehearsal-cutover-sign-off happens per company rather than as a single big-bang. The pattern reduces cutover risk from organisation-wide to per-company-cell.

Reporting is the third common project-overrun source. NAV reporting spans classic NAV section-based reports (pre-2009), RDLC reports (2009+), Word layout reports for letter-style output, and the ubiquitous Jet Reports Excel add-on installed at the majority of NAV sites. Microsoft dynamics nav migration best practices for reporting: inventory every active report file in week 1 (RDLC files in the NAV installation, Jet Reports workbook share, Word layout reports). Classify by business value (sales-by-customer, item-turnover, AR aging, GoBD GDPdU export, statutory tax reports) and usage (monthly run count, last-modified date). 40–60% typically retire as duplicates or low-value. The remainder rebuild in Fusion OTBI (analytical dashboards), BI Publisher (pixel-perfect statutory output) and Smart View (Excel-tethered analysis replacing Jet). Output is a rebuild backlog with priority, owner, and dress-rehearsal sign-off criteria.

Compliance archive design is the most often-skipped pre-migration step. Microsoft dynamics nav migration best practices: design the archive before the first extract. GoBD 10-year retention with audit-grade immutability (Germany), HMRC 6-year MTD-compatible (UK VAT), EU SAF-T per-country (Norway, Poland, Portugal, France, Lithuania, Romania), Italian SDI invoice archive, Mexican CFDI, Brazilian SPED — each jurisdiction has specific retention windows, audit-evidence requirements, and read-access logging obligations. Decide what stays in Fusion (operational window — current FY + 1–2 prior FY typical) and what routes to the long-term NAV-side archive (deeper history). Hash-sign every record, timestamp every read access, preserve the full posting chain. Document the audit-pack format auditors will receive. Syntra ETL ships the compliance archive design playbooks for every jurisdiction; consultants build them from scratch.

Parallel run is the cushion that absorbs the unknowable. Microsoft dynamics nav migration best practices: 1–2 month-end cycles in parallel minimum, with NAV continuing to take production transactions and Fusion absorbing delta replays through the SQL Server change-tracking layer. Reconcile NAV vs Fusion at month-end at row, sum and hash level — trial balance to the cent, AR aging to aging, AP aging to aging, inventory valuation to valuation. Document every reconciliation variance, root-cause it, fix it before cutover sign-off. The cutover itself is a defined weekend close-out: NAV switched to read-only, new transactions filed in Fusion. Rollback plan documented and tested before cutover (rollback to NAV is rare but the plan exists). Don't skip parallel run to save a month — that's the month that costs you year 1.

Stabilisation pain is largely predictable. Microsoft dynamics nav migration best practices that reduce it: hyper-care command centre open for the first month post-cutover with named owners and 24-hour issue triage SLA. Daily reconciliation between NAV-side archive and Fusion live data for the first quarter (silent message loss surfaces within 24 hours, not at month-end audit). Critical reports validated against NAV equivalents through the first two month-ends. Statutory submission rehearsed end-to-end before the first live submission (HMRC MTD VAT return, German GoBD GDPdU export, EU SAF-T per country, Italian SdI). User support concentrated in the first 4 weeks (super-user network, drop-in clinics, video reference library for Fusion Redwood UX). Most stabilisation pain reflects shortcuts taken during planning; the discipline above absorbs the surface area before it bites.