Pre-built microsoft dynamics nav data migration for Financials, Sales, Purchasing, Inventory and Manufacturing. SQL Server extractors, NAV Web Services SOAP, OData, dimension-to-COA crosswalks, FBDI emitters, row-level reconciliation. Audit-ready evidence at every load.
The hard part isn't running SELECT against table 17. It's translating NAV's classic data model — Dimensions, Posting Groups, Item Ledger Entries, multi-company per-database design — into Fusion's COA, subledger and item models without losing the audit chain.
NAV's data model is the product of 30 years of evolution — from Navision Attain through Microsoft Navision and into Dynamics NAV 2005–2018. The classic table set is unmistakable: Customer 18, Vendor 23, Item 27, G/L Entry 17, Item Ledger Entry 32, Sales Header 36 / Line 37, Purchase Header 38 / Line 39, Contact 5050, Bank Account 270. Around it sits the Dimension framework (Global Dimensions 1 and 2, Shortcut Dimensions 3–8, plus customer-defined dimensions), the Posting Group hierarchy that drives subledger account derivation, and the per-company database segmentation that makes a multi-tenant NAV estate look like dozens of parallel databases.
Every microsoft dynamics nav data migration to Oracle Fusion has to bridge those structures into Fusion's 6-segment COA, TCA party model, Inventory item taxonomy and Subledger Accounting rule engine — without breaking the audit chain that links a Fusion GL line back to the original NAV Sales Invoice. Custom SQL plus bespoke transformation code can do it, but every domain becomes a multi-week negotiation between Finance, IT and external implementer. Syntra ETL replaces that with pre-built crosswalks refined across dozens of NAV conversions.
The same engine handles three deployment scenarios: full NAV replacement (Financials + SCM + Manufacturing → Fusion), Financials-only migration with SCM staying on NAV during a phased rollout, and the consolidation pattern where multiple NAV companies (Company1, Company2, Company3) merge into a single Fusion ledger with intercompany reconciliation built in.
The transformations Syntra ETL ships pre-built. No custom SQL scaffolding, no multi-month bespoke conversion development.
NAV Global and Shortcut Dimensions walked, classified by reporting materiality, and routed: high-cardinality statutory dimensions collapse to Fusion COA segments, analytical dimensions route to DFFs, obsolete dimensions retire.
Customer/Vendor/Item Posting Groups translated to Fusion Subledger Accounting rules, with full preservation of how each group drives G/L account derivation in NAV — replayed in Fusion with audit trail.
NAV per-company databases (Company1, Company2, Company3) consolidated into Fusion BUs and ledgers, with intercompany G/L Entry pairs reconciled and replayed for clean opening balance.
Item Ledger Entry 32 history reconstructed in Fusion Cost Accounting with quantity, cost layer (FIFO/Average/Standard), location/bin context preserved for valuation continuity.
Sales/Purchase Header-to-Line-to-G/L Entry chain preserved end-to-end, so a Fusion AR balance drills back to the originating NAV Sales Invoice with all supporting evidence intact.
Country-specific NAV localisations (DE GoBD, UK MTD, NO/PL/PT/FR SAF-T, IT SdI, MX CFDI, BR SPED) preserved with format-fidelity for ongoing statutory submissions from Fusion.
A repeatable load order that respects Fusion's data dependencies. Skip a step and your G/L load fails on missing COA combinations or undefined Subledger Accounting rules.
Fusion enterprise structures, ledgers, BUs, COA segments, Subledger Accounting rules, item categories, inventory organisations configured. Loaded via FSM tasks — not user-facing data, but everything downstream depends on it.
Customers (TCA party + customer account), vendors (TCA party + supplier site), items (Fusion Item Master), G/L accounts (COA values), bank accounts, contacts — loaded in dependency order. NAV-id cross-reference preserved.
Trial balance, AR open items, AP open items, inventory opening balances, bank reconciliations migrated as opening journals. Reconciled to NAV trial balance to the cent before downstream loads start.
Open Sales Orders (Sales Header 36/Line 37), open Purchase Orders (Purchase Header 38/Line 39), in-flight production orders, unposted journals migrated. Approval state and dimensions preserved.
G/L Entry 17, Item Ledger Entry 32, Customer/Vendor Ledger Entries for operational window (current FY + 1–2 prior FY) loaded if Fusion is target archive; older history to long-term NAV archive.
Final delta replay, parallel-month reconciliation, sign-off pack (TB, AR/AP aging, inventory valuation — NAV vs Fusion to the cent). Production cut to Fusion.
Every microsoft dynamics nav data migration load produces signed drill-downable reconciliation reports.
Source NAV row count per table per company vs Fusion-loaded count per BU per ledger. Document header and line counts reconciled separately. Variance threshold zero.
Amount in LCY, amount in additional reporting currency, quantity, tax amount reconciled per period per company per dimension. Variance flags surface before any subsequent load is allowed.
Each NAV record content-hashed at source and re-hashed post-Fusion-load. Hash drift indicates transformation bug or corruption — surfaced with row-level diff.
NAV trial balance per period per company vs Fusion Trial Balance, drillable to journal line, posting group and originating subledger document.
NAV inventory valuation report (per cost method, per location, per item) vs Fusion Cost Accounting valuation, reconciled to the cent.
AR aging and AP aging per customer/vendor per period — NAV vs Fusion. Document chain drillable both directions for audit walkthrough.
Microsoft dynamics nav data migration is the process of moving NAV's structured data — customers (table 18), vendors (table 23), items (table 27), G/L Entry (table 17), Item Ledger Entry (table 32), Sales/Purchase Header and Line records, contacts (5050), bank accounts (270), dimensions, posting groups, plus every custom table in the 50000-99999 range — out of the NAV SQL Server backend and into Oracle Fusion Financials, SCM and supporting modules. The technical heart is three-channel extraction (SQL Server direct, NAV Web Services SOAP, OData) plus governed transformation rules and Fusion-native FBDI output. Syntra ETL ships the channels and the rules pre-built, so a microsoft dynamics nav data migration that traditionally takes 6+ months of custom development happens in weeks.
The terms get used interchangeably, but the distinction is useful: migration is the end-to-end project (extract + transform + load + reconcile + cutover), while conversion is the transformation layer specifically. Syntra ETL's microsoft dynamics nav data conversion engine ships pre-built rules for NAV's classic table set: G/L Account to Fusion natural-account segment, NAV Dimension to Fusion COA segment, Customer/Vendor to Fusion TCA party, Item to Fusion Inventory item, Posting Group to Fusion subledger-accounting rule. These are rules that on a consultant-led project would otherwise eat 4–5 months of bespoke SQL and C/AL development against a moving target.
NAV dimensions are NAV's flexible analytics axis — Department, Project, Customer Group, Salesperson, plus customer-specific dimensions defined in setup. They drive analytical reporting and statutory submissions across the NAV application. Fusion's equivalent is the 6-segment Chart of Accounts plus DFFs. Syntra ETL's NAV dimension converter walks every active Global Dimension and Shortcut Dimension in the source database, samples usage across G/L Entry and subledger entries, and proposes a target: high-cardinality dimensions used in statutory reporting collapse to Fusion COA segments (the 6 segments typically include Company, Cost Center, Account, Product, Project, Intercompany), low-cardinality analytical dimensions route to Fusion DFFs, and obsolete dimensions (zero posting in 36 months) get retired.
Yes. NAV custom tables in the 50000-99999 range carry years of business-specific extension — territory-routing logic, custom commission calculators, integration scratch tables, partner add-on data (Anveo eCommerce data, Continia OPplus document handling, ChargeLogic credit-card vault metadata, Insight Works mobile WMS data). Syntra ETL walks each custom table, samples row volume and update frequency, classifies by business purpose, and routes: required custom tables migrate as Fusion DFF/EFF extensions on the parent object, analytical custom tables route to a Fusion-adjacent data warehouse with OTBI lookback, partner add-on tables follow per-vendor playbooks, and obsolete custom tables (no updates in 36 months) get retired with sign-off.
Syntra ETL emits Fusion-native load formats for every NAV data domain: FBDI Journal Import for G/L Entry historical migration, FBDI Customer Import and Supplier Import for TCA party loading, FBDI Item Import for Fusion Inventory, FBDI Sales Order Import and Purchase Order Import for open transactions, HCM Data Loader (HDL) for any worker-side context. Every payload validates against current Oracle Fusion 26x release schemas before submission. Validation errors surface locally with row-level diagnostics rather than failing in a 4-hour Fusion ESS job that dies on row 47,000 — the typical experience with hand-built FBDI generators.
Every record extracted from NAV is hashed at the source (header hash + line hashes + dimension hashes). Every record loaded into Fusion is re-hashed post-load. The reconciliation engine compares counts (G/L Entries, Customer Ledger Entries, Item Ledger Entries, document headers and lines), sum totals (amount in LCY, amount in additional reporting currency, quantity, tax amount per dimension), and hash signatures per company per period. Any record failing Fusion validation is captured with the exact field-level reason for bulk fix. Output is a signed timestamped reconciliation pack: NAV trial balance vs Fusion trial balance to the cent, AR aging vs aging, AP aging vs aging, inventory valuation vs valuation. Internal audit signs off directly on the pack.
Yes. After the initial bulk load, Syntra ETL captures NAV deltas through the SQL Server change-tracking layer (or via the Modified DateTime field on the entry tables) and replays them into Fusion via FBDI or REST. This supports the standard parallel-run pattern: NAV continues taking transactions for 1–2 month-end cycles while Fusion is validated to the cent. Once finance and operations sign off, new transactions cut to Fusion and NAV moves to read-only archive mode. The parallel-run window also covers external integration cutover: EDI feeds, banking files, payroll feeds and tax submissions all switch from NAV to Fusion with controlled rollback.
German GoBD requires 10-year retention of digital records with audit-grade immutability. UK HMRC mandates 6-year retention with MTD-compatible digital records for VAT. EU SAF-T (Norway, Poland, Portugal, France, Lithuania, Romania) requires per-country standard audit files retained for jurisdiction-specific windows (typically 5–10 years). Syntra ETL's microsoft dynamics nav data migration preserves the full chain: Fusion GL line → original NAV G/L Entry → originating document (Sales Invoice, Purchase Invoice, Journal) → supporting attachments, with every hop signed and timestamped. Whether the legacy NAV data lives in Fusion's online tables or in the long-term NAV archive, the read-access log is captured for GoBD/HMRC/SAF-T audit evidence. No reconstruction needed when auditors arrive.
30-minute call. Walk through your NAV version, multi-company estate, custom-table inventory and compliance obligations — leave with a concrete microsoft dynamics nav data migration plan.