Microsoft dynamics nav erp migration to Oracle Fusion Cloud — the SMB-to-enterprise step-up scenario. Design-centre translation, C/AL/AL inventory, partner add-on disposition, multi-company sequencing, full-module scope (Financials + SCM + Manufacturing + Service), 14–40 week timelines. The complete domain deep-dive.
A NAV-to-Fusion erp migration is not a vendor swap. It's a translation between two fundamentally different ERP design centres — SMB partner-led customisation freedom on one side, enterprise configuration-first discipline on the other.
Microsoft Dynamics NAV — Navision before the 2002 Microsoft acquisition, Microsoft Navision in the early Microsoft years, Dynamics NAV from 2005, and Business Central in the cloud — has been the dominant SMB and mid-market ERP across DACH, the Nordics, UK and US SMB for two decades. Its design centre is unambiguously mid-market: 10–500 users, single-country or modest multi-country, partner-led implementation, C/AL/AL deep customisation, SQL Server backend, per-company database segmentation. Within that envelope it is hard to beat on TCO, partner ecosystem depth, vertical-specific add-on availability, and implementation speed.
Oracle Fusion Cloud's design centre is fundamentally different: global enterprise, 250–50,000+ users, deep multi-country and multi-pillar integration, configuration-over-customisation, hyperscale Oracle Database, quarterly innovation cadence, native multi-ledger multi-currency multi-jurisdiction architecture. A microsoft dynamics nav erp migration only makes strategic sense when a NAV-grown business is crossing the SMB-to-enterprise threshold — typically when international expansion, multi-pillar integration, regulatory complexity, or scale stretch NAV beyond its design centre.
The translation work — the heart of microsoft dynamics nav erp migration intellectual content — happens at five layers. Data model translation: NAV Customer 18, Vendor 23, Item 27, G/L Entry 17, Item Ledger Entry 32 into Fusion TCA, Inventory, GL, Cost Accounting models. Customisation translation: C/AL/AL custom tables and fields into Fusion DFFs/EFFs/extensions. Business-process translation: NAV Sales Header → Fusion Order Management workflow with Fusion approval routing. Reporting translation: RDLC + Jet + Word layout into OTBI + BI Publisher + Smart View. Compliance translation: country-specific NAV localisations (DE GoBD, UK MTD, NO/PL/PT/FR/IT SAF-T, IT SdI, MX CFDI, BR SPED) into Fusion-native + Syntra ETL compliance archive. Each translation has its own crosswalk discipline.
Module scope is the largest driver of microsoft dynamics nav erp migration timeline. Financials-only is 10–14 weeks; full-scope including Manufacturing and Service is 28–40 weeks.
NAV General Ledger → Fusion GL (with COA + SLA translation). NAV Receivables → Fusion AR (TCA customer model). NAV Payables → Fusion AP (TCA supplier model). NAV Fixed Assets → Fusion Assets. NAV Cash Management → Fusion Cash Management. The Financials-first phase typically lands in 10–14 weeks.
NAV Sales (Sales Header 36, Line 37, Customer 18) → Fusion Order Management with full document chain preserved. Open orders migrated with approval state and dimension context. Sales analytics rebuilt as Fusion OTBI.
NAV Purchasing (Purchase Header 38, Line 39, Vendor 23) → Fusion Procurement. NAV Inventory (Item 27, Item Ledger Entry 32, location/bin) → Fusion Inventory with Item Ledger reconstructed in Fusion Cost Accounting (FIFO/Average/Standard layers preserved).
NAV Manufacturing (production order, BOM, routing, work centre, capacity) → Fusion Manufacturing. Production-order state, material consumption history, capacity utilisation preserved. Typically adds 6–10 weeks to Financials-only timeline.
NAV Service Management (service item, service order, service contract) → Fusion Service Logistics or Field Service Cloud. Service-item history, contract state, service-order document chain preserved. Typically adds 4–8 weeks.
NAV Jobs (project, task, resource, time-sheet, project ledger) → Fusion Project Management or Fusion PPM. Project costing, billing milestones, resource allocation preserved. Typically adds 4–8 weeks.
A 28–40 week full-scope microsoft dynamics nav erp migration including all six modules. Financials-only scope compresses to 10–14 weeks; multi-region multi-company scope expands toward 40 weeks.
Object Designer crawl, partner add-on signature scan, multi-company inventory, compliance archive scope, module-by-module data-volume estimate. Output: full programme inventory, sized assessment, risk register.
Per-module crosswalk: GL/AR/AP/Assets, OM, Procurement, Inventory, Manufacturing, Service, Project. Dimension-to-COA, posting-group-to-SLA, partner add-on disposition, compliance archive design. All signed off by finance, operations, audit.
Extractors configured, transforms configured, FBDI emission validated, dress-rehearsal load module-by-module. Reconciliation engine configured per module. Sign-off pack templates per module. Per-module dress rehearsal sign-off.
Production loads sequenced by dependency: Foundation (FSM) → Master Data → Opening Balances → Open Transactions → Historical Entries → Module-specific (Manufacturing, Service, Project). Per-module reconciliation.
Parallel-run 1–2 month-end cycles per cutover wave. Multi-region multi-company waves typically grouped (DACH wave, Nordics wave, UK/Ireland wave). Daily reconciliation, variance log, root-cause and fix.
Per-wave cutover weekend, NAV switched to read-only per wave, hyper-care command centre open. Archive verification, licence-stack retirement, partner add-on subscription cancellation, hardware decommission. NAV fully retired.
The patterns that show up most frequently in NAV-to-Fusion programmes. Each has its own playbook in the Syntra ETL platform.
Single-company NAV with light SCM. Full Financials cutover in 10–14 weeks. Phased SCM rollout follows over 6–12 months. Sub-six-month payback against NAV Enhancement Plan retirement.
10+ NAV companies across DACH, UK, Nordics. 3–5 cutover waves grouped by country, each with own parallel-run window. Intercompany handled via Fusion-to-NAV bridge during transition. 22–32 weeks end-to-end.
Manufacturing-heavy NAV (production-order driven business). Full-scope microsoft dynamics nav erp migration including Manufacturing, Service, Project. 28–40 weeks. Highest complexity and highest payback by retiring NAV partner add-ons across modules.
Financials to Fusion immediately, SCM/Manufacturing stays on NAV during 6–12 month phased rollout. Syntra ETL integration layer keeps NAV and Fusion synchronised during the phased window. Lowest disruption pattern.
Multiple NAV companies (Company1, Company2, Company3) consolidate into single Fusion ledger. Intercompany G/L Entry pairs reconciled at source and replayed as clean opening balance. Useful for post-M&A NAV estate cleanup.
GoBD 10-year retention is the leading constraint. Compliance archive design happens before module scope. Audit-pack format signed off by German Wirtschaftsprüfer before extraction begins. Common pattern in German manufacturing NAV.
Microsoft dynamics nav erp migration is the complete platform-level move from NAV to a successor ERP — most commonly Microsoft Dynamics 365 Business Central (the Microsoft cloud refresh path) or Oracle Fusion Cloud ERP (the enterprise step-up path). It differs fundamentally from a NAV version upgrade (e.g., NAV 2016 → NAV 2018), where the underlying application stays the same and only the version moves. A microsoft dynamics nav erp migration involves vendor change (Microsoft to Oracle) or product change (NAV to BC), data model translation, customisation re-platform, business-process redesign, and full retraining. The NAV-to-Fusion variant of microsoft dynamics nav erp migration is the step-up scenario covered on this site: SMB-design-centre NAV moving to enterprise-design-centre Fusion.
Three scenarios make microsoft dynamics nav erp migration to Oracle Fusion strategically rational rather than a vendor mismatch. First, enterprise scale-up: a NAV-grown business crossing 500–1,000 users, 10+ country footprint, or 50+ legal entities outgrows NAV's SMB design centre and Fusion's enterprise capability becomes worth the investment. Second, Oracle ecosystem consolidation: an organisation running Oracle EBS in HQ, Oracle Database in operational systems, or Fusion in adjacent subsidiaries gets material ongoing TCO from consolidating the NAV business unit onto Fusion rather than maintaining parallel Microsoft + Oracle stacks. Third, multi-pillar integration depth: when Finance + SCM + HCM + EPM + CX need to operate as one platform with single source of truth, Fusion's native multi-pillar integration is materially deeper than NAV + Business Central + standalone HR + separate planning tools. Outside those three, BC is usually the better answer.
NAV is engineered for SMB: small-team partner-led implementation, C/AL/AL deep customisation, SQL Server backend, per-company database segmentation, partner-add-on dependency. Fusion is engineered for enterprise: configuration-over-customisation, hyperscale Oracle Database, native multi-ledger multi-currency multi-pillar architecture. Microsoft dynamics nav erp migration translates between the design centres by: collapsing NAV custom fields onto Fusion DFFs/EFFs (configuration-friendly), routing NAV custom tables to Fusion extension objects or to long-term archive, replacing NAV custom codeunits with Fusion REST integrations or process automation, rebuilding NAV custom reports (RDLC, Word layout, Jet) in Fusion OTBI/BI Publisher/Smart View. The design-centre translation is the heart of the migration intellectual work; the data extract is comparatively mechanical.
Full-scope microsoft dynamics nav erp migration to Fusion covers: NAV General Ledger → Fusion GL with full COA and SLA translation. NAV Receivables → Fusion AR with TCA customer model. NAV Payables → Fusion AP with TCA supplier model. NAV Fixed Assets → Fusion Assets. NAV Cash Management → Fusion Cash Management. NAV Sales → Fusion Order Management (with NAV's Sales Header 36/Line 37 translating to Fusion OM headers/lines). NAV Purchasing → Fusion Procurement (with NAV's Purchase Header 38/Line 39 translating to Fusion Procurement). NAV Inventory → Fusion Inventory with Item Ledger Entry 32 history. NAV Manufacturing → Fusion Manufacturing (production order, BOM, routing, work centre translation). NAV Service Management → Fusion Service Logistics or Field Service. NAV Jobs (Project) → Fusion Project Management. Each module has its own crosswalk and reconciliation discipline.
NAV's per-company database design (Company1, Company2, Company3 as separate database tables within one SQL Server instance) creates microsoft dynamics nav erp migration sequencing complexity not present in single-database ERPs. The typical sequence: extract all NAV companies in parallel against a SQL Server read replica. Reconcile intercompany G/L Entry pairs at the source before extraction. 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. A 12-company NAV estate typically cuts over in 3–5 waves, with country-grouped companies cutting together (DACH wave, Nordics wave, UK/Ireland wave) and intercompany reconciliation handled across waves through a Fusion-to-NAV bridge during the transition window.
The standard microsoft dynamics nav erp migration history pattern: current FY + 1–2 prior FY into Fusion's online tables (operational window — analysts and finance teams use it daily), the remainder into a long-term NAV-side archive accessible through the compliance archive (GoBD 10-year, HMRC 6-year, SAF-T 5–10-year, SDI 10-year, CFDI 5-year, SPED 5-year). The pattern keeps Fusion fast and lean while preserving full audit trail back to NAV documents and beyond. Some organisations choose to load 5+ years into Fusion online tables for trending analytics — at the cost of larger Fusion subscription footprint and longer initial load runtime. The decision is documented in the migration assessment with finance, audit and analytics input.
C/AL is NAV's classic programming language; AL is its modern successor introduced for NAV 2018 and Business Central. Microsoft dynamics nav erp migration to Fusion handles both: the Object Designer crawler enumerates C/AL and AL objects equivalently — custom tables, custom fields, modified standard objects, custom codeunits, custom pages, custom reports, custom XMLports. Each is classified by business purpose and routed to Fusion: custom fields collapse to Fusion DFFs/EFFs, custom tables route to Fusion extension objects or long-term archive, custom codeunits map to Fusion REST integrations or process automation, custom reports rebuild as OTBI/BI Publisher/Smart View. The C/AL → AL → Fusion arc is a 3-step translation, but the Object Designer crawler treats it as a single inventory operation regardless of which language the source object was written in.
Realistic microsoft dynamics nav erp migration timeline depends on scope. Single NAV 2016 or NAV 2018 estate, Financials + light SCM, 3–8 companies, moderate customisation: 14–22 weeks using Syntra ETL versus 12–18 months consultant-led. Multi-region NAV with 10+ companies across DACH, UK, Nordics, with GoBD + HMRC + SAF-T compliance archive: 22–32 weeks with Syntra ETL versus 18–30 months consultant-led. Full-scope NAV including Manufacturing, Service Management and Project: 28–40 weeks with Syntra ETL versus 24–36 months consultant-led. The Syntra ETL acceleration comes from pre-built NAV extractors (SQL Server, SOAP, OData), pre-built crosswalks refined across dozens of NAV conversions, pre-built FBDI emitters, pre-built compliance archive playbooks, and row-level reconciliation that auto-generates the sign-off pack. Without that platform, every project re-invents the same wheel against a moving Fusion 26x release target.
Book a 30-minute discovery call. We'll walk through your NAV version, module scope, multi-company estate, customisation depth, partner add-ons, compliance scope and target Fusion shape — and give you a domain-led microsoft dynamics nav erp migration plan with concrete timeline and budget before the call ends.