Pre-built Dynamics 365 data conversion for every F&O, Business Central, and Customer Engagement entity. Main Account → COA crosswalks, Dataverse extractors, FBDI/HDL emitters, row-level reconciliation. Audit-ready evidence at every load.
The hard part isn't moving rows. It's translating D365's three different data models — F&O SQL Server, Business Central, and Dataverse — into a single target without losing meaning.
Dynamics 365 is not one product, it's a product family. D365 Finance & Operations runs on Azure SQL Server with the AOT, X++ extensions, and Lifecycle Services deployment artifacts. D365 Business Central is the NAV lineage with a different schema and Business Central API. D365 Customer Engagement runs on Dataverse — an entity-relationship metadata layer with its own security model and a completely different data shape. Each requires its own extraction and transformation approach.
Every Dynamics 365 data migration has to bridge these gaps to a single target — and the bridging is where projects slip from quarters into years. Custom SQL, X++ jobs, and Power Query flows written by hand can do it, but each entity is a multi-week negotiation between functional, technical, and audit teams. Syntra ETL replaces that with pre-built crosswalks that have been refined across dozens of D365 conversions.
The same engine handles four deployment scenarios: full D365 replacement (F&O + CE → Fusion), F&O-only migration (Finance + SCM → Fusion Financials/SCM), BC consolidation (mid-market subsidiaries → enterprise Fusion), and the hybrid pattern where CE stays on Dataverse for the sales process and only F&O moves to Fusion for back-office.
The transformations Syntra ETL ships pre-built. No custom code, no multi-month bespoke development.
F&O's flexible MainAccount + up-to-10 financial dimensions collapsed into Fusion's fixed 6-segment COA. Dimension-usage analyser identifies material splits; non-material dimensions route to DFFs or PPM dimensions.
CE entity-relationship graph extracted with foreign-key integrity, many-to-many relationship tables preserved, audit history captured, owning-team security translated to Fusion role-based access.
F&O DataAreaId / BC Company / Dataverse Business Unit mapped to Fusion's BU + Legal Entity two-level model with intercompany configuration preserved.
Fuzzy-match de-duplication across F&O VendTable + CustTable and Dataverse Account + Contact (which often duplicate the same parties). Single supplier master in Fusion regardless of D365 source.
F&O EcoResProduct + InventTable normalized to Fusion's item-class structure, category translations applied, costing methods migrated with full history per inventory site.
F&O HcmWorker + HcmEmployment effective-dated history converted to Fusion HDL worker/assignment event sequences with full 10+ year history preservation.
A repeatable load order that respects Fusion's data dependencies. Skip a step and your AP load fails on missing vendors.
Fusion enterprise structures, ledgers, BUs, COA segments, value sets, calendars configured. Loaded via FSM tasks or migration utility — not user-facing data, but everything downstream depends on it.
Chart of Accounts segment values, value sets, account hierarchies loaded via FBDI ChartOfAccounts and Value Set FBDI templates. Validated against D365 MainAccount and dimension hierarchies for parent-child integrity.
Suppliers (FBDI Supplier Import — sourced from F&O VendTable and de-duplicated against Dataverse Account), customers (FBDI Customer Import — same de-dup pattern), items (FBDI Item Import), employees + jobs (HDL Worker.dat + Assignment.dat). Loaded in dependency order — workers before assignments, vendors before invoices.
GL period balances (FBDI Journal Import), AP open invoices (FBDI AP Invoice Import), AR open invoices (FBDI AutoInvoice), open sales orders, open POs, asset CIP and in-service balances. Each load reconciled to D365 before next stage begins.
Closed-period historical data loaded if Fusion is the target archive, or routed to Syntra archive if cold-data lifecycle dictates. Either way, queryable for audit during the full retention window.
Final delta replay, parallel-close reconciliation, sign-off pack generation (trial balance, aging, asset register, worker headcount — D365 vs Fusion to the cent). Production cut to Fusion.
Every Dynamics 365 data migration load produces signed, drill-downable reconciliation reports.
Source D365 row count vs Fusion-loaded row count per entity, per period, per legal entity. Variance threshold zero for GL; configurable for archival domains.
Debit, credit, amount, quantity, and balance sums reconciled per period per ledger. Variance flags surfaced before any subsequent load is allowed to proceed.
Each record content-hashed at D365 source and re-hashed post-Fusion-load. Hash drift indicates transformation bug or corruption — surfaced with row-level diff.
D365 F&O trial balance per ledger per period vs Fusion trial balance, drillable to journal line, sub-ledger source, and originating vendor invoice.
Open AP invoice aging in D365 vs open AP invoice aging in Fusion, bucketed and reconciled by vendor; same for AR by customer. Internal audit signs the pack directly.
Dataverse Opportunity pipeline by stage, owner, and close date reconciled against the loaded equivalent. Crucial when CE-to-Fusion-CX is in scope.
Dynamics 365 data migration is the process of moving master data (Main Accounts, financial dimensions, vendors, customers, items, employees, Dataverse entities), open transactional records (vendor invoices, customer invoices, journals, sales orders, POs), and historical archives out of D365 Finance & Operations, D365 Business Central, or D365 Customer Engagement into a target system — usually Oracle Fusion Cloud, sometimes a data warehouse, sometimes a long-term archive. The technical heart of the work is schema transformation: F&O's MainAccount + dimensions model is collapsed into Fusion's fixed 6-segment Chart of Accounts; Dataverse's entity-relationship graph is normalized into Fusion's relational structures; X++ AOT extensions are inventoried and routed to retire or rebuild. Syntra ETL handles every transformation natively with governed crosswalks and Oracle-validated FBDI/HDL output.
The terms are used interchangeably in practice, but the technical distinction is useful: dynamics 365 data migration is the end-to-end project (extract + transform + load + reconcile + cutover), while conversion is the transformation layer specifically — the rules that turn D365 data structures into target-shaped data. Syntra ETL's D365 data conversion engine ships with pre-built rules for MainAccount collapse, financial-dimension flattening, vendor/customer de-duplication across F&O and CE, Dataverse entity-relationship normalization, employee history flattening for HCM, asset book remapping, and legal-entity-to-BU translation. These are the rules that, on a consultant-led project, would otherwise consume 4–6 months of bespoke X++ or Power Query development.
Dataverse is fundamentally different from F&O's SQL Server back end: it's an entity-relationship metadata layer, with custom entities, many-to-many relationship tables, owning-team security, business units, and an audit history table. Syntra ETL's Dataverse extractor uses the TDS endpoint (SQL-over-Dataverse) for high-volume bulk extraction and the Web API for metadata, plug-in registration, and audit history. The output preserves the entity-relationship graph as foreign keys plus a relationship manifest, includes soft-deleted records (configurable), captures every audit-history row, and resolves owning-team references to user-level lineage. The largest CE deployment we've moved had 280 million primary-entity rows across Account, Contact, Opportunity, and Activity.
D365 F&O does not include a full payroll engine in most regions (it relies on partners or external payroll for US/UK/CA, while EMEA-specific localizations vary). Where customers do run F&O Payroll (commonly in the US partner-localized variant), Syntra ETL extracts pay statement, earnings, deductions, and tax data from F&O's payroll schema, plus the underlying HR data (HcmEmployment, HcmWorker, HcmPositionWorkerAssignment). For most customers, the practical pattern is: load current-year YTD balances and prior-year W-2/T4 data into Fusion Payroll via HDL, and route the historical payroll detail to Syntra archive for the 7+ year IRS retention period. This satisfies both Fusion's operational needs and historical compliance requirements without paying Fusion storage for cold data.
Syntra ETL emits all three Fusion-native load formats: FBDI (File-Based Data Import) ZIPs for Financials and SCM (GL_INTERFACE, AP_INVOICES_INTERFACE, AR_INTERFACE_LINES, etc.); HDL (HCM Data Loader) bundles for HCM (Worker.dat, Assignment.dat, Salary.dat); and REST API payloads for incremental delta loads. For non-Fusion targets, Syntra ETL also emits Parquet for cloud-warehouse landings (Snowflake, BigQuery, Synapse), Delta Lake for Databricks/Fabric, and standard CSV for legacy targets. Each format is validated against the destination schema before submission, so validation errors are caught locally — not in a 4-hour Fusion ESS job that fails on row 47,000.
Every record extracted from D365 is hashed at the source. Every record loaded into Fusion (or another target) is re-hashed post-load. The reconciliation engine compares counts, sum totals (debits, credits, amounts, quantities), and hash signatures per table, per period, per legal entity. Any record that fails Fusion validation is captured in an error report with the exact field-level reason — ready for bulk fix or escalation. The output is a signed, timestamped reconciliation pack: D365 trial balance vs Fusion trial balance to the cent, AP aging vs AP aging, customer aging vs customer aging, asset register vs asset register. Internal audit signs off on the pack directly; no rebuild needed.
Yes. After the initial bulk load, Syntra ETL captures D365 deltas via the Modified date/time watermarks on F&O entities (or via Business Events for high-velocity scenarios) and Dataverse change-tracking for CE; deltas replay into Fusion through REST APIs. This supports the standard parallel-run pattern: D365 continues taking production traffic for 1–2 close cycles while Fusion is validated against D365 to the cent. Once finance, HR, and audit are comfortable, traffic cuts to Fusion and D365 moves to archive-only mode.
D365 F&O uses Legal Entities (DataAreaId, the old AX 'company') for posting-segregation; Business Central uses Companies; Customer Engagement uses Business Units (Dataverse). Oracle Fusion uses Business Units and Legal Entities as a deliberate two-level model. Syntra ETL's converter analyses your D365 legal-entity / company / business-unit topology, recommends a Fusion BU + LE design, and applies it during transformation so vendors visible to D365 LE 'USMF' end up in the equivalent Fusion BU with correct security and intercompany configuration. The mapping is reviewed and signed off by both functional and security leads before any load.
30-minute call. Walk through your D365 data volumes (F&O, BC, CE), Main Account / dimension design, Dataverse entity scope, and target load destination — leave with a concrete data-migration plan.