Pre-built dynamics ax data migration for GL, AP, AR, inventory, sales and purchase. SQL Server + AIF extractors, Financial Dimension to COA crosswalks, EDT translation, FBDI emitters, row-level reconciliation, audit-ready evidence at every load.
The hard part isn't SELECTing from CustTable. It's translating AX's Financial Dimension model, EDT inheritance, multi-layer X++ customizations and AOS-mediated business logic into Fusion's data model without losing posting semantics or audit context.
Microsoft Dynamics AX 2012 presents an SQL Server-backed data model anchored on LedgerJournalTrans (the journal-line fact table), CustTable + CustTrans (customers and their balances), VendTable + VendTrans (vendors and balances), InventTable + InventTrans (items and inventory movements), SalesTable + SalesLine (sales orders), PurchTable + PurchLine (purchase orders), with Financial Dimensions providing the analytical posting axis through DimensionAttributeValueCombination. Oracle Fusion uses a fundamentally different shape — Suppliers and Customers as Trading Community Architecture parties, Items in Product Hub, GL Journal Lines aligned to a fixed 6-segment COA, Distributions modelled per Subledger Accounting setup.
Every dynamics ax data migration to Fusion has to bridge those gaps without breaking the audit chain that links a Fusion GL journal back to its originating AX vendor invoice or sales order. Custom SQL clients and one-off transformation T-SQL can do it — but every domain becomes a multi-week negotiation between functional, technical and compliance teams. Syntra ETL replaces that with pre-built crosswalks refined across dozens of AX conversions covering AX 2012 R1/R2/R3, AX 2009 and AX 4.0.
The same engine handles three deployment scenarios: full AX replacement (Finance + SCM + manufacturing → Fusion), Finance-first phased pattern (AX Finance → Fusion GL/AP/AR with SCM following), and the M&A carve-out where a single AX legal entity migrates into a target Fusion tenant ahead of group consolidation.
The transformations Syntra ETL ships pre-built. No custom T-SQL scaffolding, no multi-month bespoke conversion development.
DimensionAttributeValueCombination walked, classified by reporting materiality, routed: required dimensions collapse to Fusion COA segments, secondary route to GL DFFs, analytical-only route to OTBI dimensions or AX archive.
AX Extended Data Types catalogued, inherited types resolved, mapped to Fusion native fields, DFFs or EFFs as appropriate. Custom EDTs extending base types (CustTable/VendTable) handled with explicit per-EDT routing.
Every active Number Sequence catalogued with scope, format mask and statutory significance. Continue / restart / freeze-and-replace decision made per sequence with statutory invoice continuity preserved.
Cross-legal-entity duplicate detection on CustTable and VendTable, tax-id and bank-account normalization, Fusion party-and-site model built from the AX flat customer/vendor record.
InventTable plus InventDim (the AX storage/tracking dimension table) disaggregated into Fusion Item attributes plus Inventory Item Location and Lot/Serial control as appropriate.
DocuRef/DocuValue documents extracted with original file content, hash-signed, bound to Fusion records via FBDI attachment metadata. Cross-reference preserved for SOX/HGB/HMRC audit.
A repeatable load order that respects Fusion's data dependencies. Skip a step and your AP invoice load fails on missing supplier sites or COA combinations.
Fusion enterprise structures, ledgers, BUs, COA segments, COA values, cross-validation rules, calendars, currencies, tax setup, document sequences configured. Loaded via FSM tasks — not user-facing data, but every load downstream depends on it.
Suppliers (FBDI Supplier Import from VendTable), Customers (FBDI Customer Import from CustTable), Items (FBDI Item Import from InventTable with InventDim disaggregated), Workers (HDL Worker.dat from AX HR if relevant). Loaded in dependency order — suppliers before invoices, items before transactions.
Open AP invoices from VendInvoiceJour/VendTrans via FBDI AP Invoice Import. Open AR invoices and receipts from CustInvoiceJour/CustTrans via FBDI AR Invoice/Receipt Import. Inventory on-hand from InventSum via FBDI Item Onhand Import. Reconciled to the cent against AX aging.
Historical LedgerJournalTrans by fiscal period via FBDI GL Journal Import, posted with original Financial Dimension context preserved as COA segments plus GL DFFs. Loaded period by period oldest-first with reconciliation gate per period.
Closed AP/AR history if Fusion is the target archive (otherwise routed to AX long-term archive). Closed sales/purchase history with Financial Dimension postings. Production orders, BOMs, work orders for live manufacturing context.
Final delta replay via change-data-capture on RECID + MODIFIEDDATETIME, parallel-period reconciliation, sign-off pack (TB vs TB, aging vs aging, on-hand vs on-hand). AIF integration ports rewired to Fusion endpoints. Production cut to Fusion.
Sign-off requires evidence, not a status email. Syntra ETL ships these artefacts per load cycle.
AX trial balance per period per legal entity vs Fusion trial balance, to the cent, with variance heatmap by natural account. Sign-off-ready for finance and internal audit.
AP open balance per supplier per ageing bucket vs Fusion Payables aging. AR open balance per customer per ageing bucket vs Fusion Receivables aging. Variance flagged at supplier/customer level.
InventSum on-hand per item per warehouse per storage dimension vs Fusion Inventory on-hand per item per organization per locator. Variance flagged at item-warehouse level.
Count and hash signature of DocuRef/DocuValue documents migrated vs count and hash in Fusion attachment store. Missing-attachment exception list with source RECID for re-extract.
Extract timestamp, source-row count, transformed-row count, loaded-row count, validation-error count, hash chain, reviewer sign-off. Sufficient for SOX 404 IT-general-controls evidence on the data conversion.
Per-legal-entity retention attestation showing that AX-origin records are preserved either in Fusion or in the long-term archive for the jurisdiction's statutory minimum (US SOX 7yr, UK HMRC 6yr, German HGB 10yr).
Dynamics AX data migration is the process of moving GL (LedgerJournalTrans, General Journal Account Entries), AP (VendInvoiceJour, VendTrans), AR (CustInvoiceJour, CustTrans), inventory (InventTrans, InventSum), sales (SalesTable, SalesLine), purchase (PurchTable, PurchLine), customers (CustTable), vendors (VendTable), items (InventTable) and supporting master data from your AX 2012 or AX 2009 environment into Oracle Fusion. The technical heart is twofold: SQL Server direct extraction against the AX schema and optional AIF SOAP extraction for document-class business logic. Syntra ETL handles both with pre-built extractors, governed crosswalks for AX Financial Dimensions to the Fusion COA, EDT-to-Fusion-field translation and Oracle-validated FBDI Supplier/Customer/AP Invoice/AR Invoice/GL Journal Import output.
The terms get used interchangeably, but the distinction is useful: dynamics ax data migration is the end-to-end project (extract + transform + load + reconcile + cutover), while conversion is the transformation layer specifically. Syntra ETL's AX data conversion engine ships pre-built rules for AX Chart of Accounts to Fusion 6-segment COA, Financial Dimensions to COA/DFF/OTBI dimension routing, EDT to Fusion field mapping, customer/vendor harmonization across AX legal entities, item master cleanup with InventTable/InventDim disaggregation, and translation of AX X++ posting rules into Fusion's subledger accounting. These are rules that on a consultant-led project would otherwise eat 3–4 months of bespoke SQL and X++ development.
AX Number Sequences are central to document control — invoice numbers, order numbers, voucher numbers all draw from configured sequences with scope (shared, legal entity, region) and format masks. The dynamics ax data migration plan has to decide for each sequence: continue numbering in Fusion (preserve continuity, common for statutory invoice numbers in EU/Germany), restart sequencing in Fusion under the Fusion Document Sequencing framework (clean break, common for internal operational numbers), or freeze the sequence on the AX side and assign a new range in Fusion (most common compromise). Syntra ETL catalogues every active Number Sequence, classifies by statutory significance, and the assessment delivers a recommended disposition per sequence with the migration package implementing whichever path you choose.
Yes — and this is one of the most analytically valuable parts of any dynamics ax data migration. AX Financial Dimensions (default and customer-defined: BusinessUnit, CostCenter, Department, ItemGroup, and freeform dimensions) combine via DimensionAttributeValueCombination to provide the analytical posting axis. Syntra ETL walks every combination that has activity in LedgerJournalTrans, identifies which dimensions drive material reporting splits, and proposes routing: financial-statement-driving dimensions collapse to Fusion COA segments, secondary dimensions route to Fusion GL DFFs, analytical-only dimensions route to OTBI subject areas or to the long-term AX archive. Account-structure validation rules in AX translate to Fusion cross-validation rules during the data conversion.
Syntra ETL emits Fusion-native load formats for every AX data domain: FBDI Supplier Import for VendTable, FBDI Customer Import for CustTable, FBDI Item Import for InventTable, FBDI AP Invoice Import for VendInvoiceJour open items, FBDI AR Invoice/Receipt Import for CustInvoiceJour and CustTrans, FBDI GL Journal Import for historical LedgerJournalTrans by period, HCM Data Loader (HDL) for any HR data being absorbed, and REST API payloads for incremental delta loads during parallel-run and post-cutover. Document attachments from DocuRef/DocuValue are bound via FBDI attachment metadata. Every payload is validated against the current Oracle Fusion 26x release schema before submission, so validation errors surface locally — not in a 4-hour Fusion ESS job that fails on row 84,000.
Every record extracted from AX (LedgerJournalTrans line, VendInvoiceJour, CustInvoiceJour, SalesLine, PurchLine, InventTrans) is hashed at the source with a stable schema-aware hash. Every record loaded into Fusion is re-hashed post-load. The reconciliation engine compares counts (transactions per period per legal entity), sum totals (debit/credit per natural account per period, AP open balance per supplier, AR open balance per customer per ageing bucket, inventory on-hand per item per warehouse) and hash signatures. Any record that fails Fusion validation is captured with the exact field-level reason ready for bulk fix. Output is a signed timestamped reconciliation pack: AX trial balance vs Fusion trial balance to the cent per period, AP aging vs aging, AR aging vs aging, inventory on-hand by item-warehouse. Internal audit signs off on the pack directly.
Yes. After the initial bulk load, Syntra ETL captures AX deltas via change-data-capture on key tables (RECID + MODIFIEDDATETIME watermarks on LedgerJournalTrans, SalesTable, PurchTable, VendInvoiceJour, CustInvoiceJour) and replays them into Fusion through FBDI incremental loads or REST APIs. This supports the standard parallel-run pattern: AX continues taking transactions for 1–2 fiscal periods while Fusion is validated to the cent, both ledgers post in parallel, deltas reconcile daily. Once finance, supply chain and IT sign off, new transactions cut to Fusion and AX moves to read-only archive mode. AIF integration ports are rewired to Fusion endpoints during this same window.
SOX requires 7-year retention of financial records with auditable trace from GL entry back to original supporting evidence. EU statutory frameworks (German HGB 10 years, French PCG, UK HMRC 6+ years) impose region-specific minimums. Syntra ETL preserves the full chain: GL line in Fusion → Subledger journal → AX-origin transaction → original AX document (invoice, voucher, sales order) → attached document from DocuRef/DocuValue, with every hop signed and timestamped. Whether the record lands in Fusion or in the long-term AX archive, the read-access log is captured for SOX and statutory audit evidence. The migration plan explicitly addresses retention per legal entity so the post-AX archive matches each jurisdiction's minimum.
Send us your AX version, legal-entity list, Financial Dimension design and report library. We will return a data-conversion scope, FBDI volume estimate, reconciliation plan and timeline — typically within 5 working days.