The M3-to-D365 migration engine: canonical model, transformation governance, and operational hardening
How a purpose-built migration engine turns M3's MI transactions, Db2-for-i tables and MEC/ION document flows into reconciled D365 records — the extractor-to-reconciler reference architecture, the canonical lookup registry, the transformation matrix's governance rules, the DMF loader, dry-run mode, and the fifteen-dimension operational hardening register that separates a script from a production-grade engine.
What you will be able to do
Explain why a canonical intermediate model outperforms point-to-point mapping as the number of source companies and target legal entities grows
Choose the right M3 extraction source — direct table read, MI transaction, or MEC/ION document flow — for a given entity's accounting sensitivity
Describe how a value mapping is registered, versioned and approved in the canonical lookup registry
Read an entity-sequencing dependency graph and explain why it, not intuition, decides load order
Apply the fifteen-dimension operational hardening register to judge whether a migration engine is production-ready
Explain why FAM-function posting rules and posted GL balances have to migrate through two different mechanisms
Introduction
Chapter 1 of this domain described the programme: seven stages, an estate inventory, and a wave plan. This chapter goes one level down, into the thing that actually moves the data — the migration engine — and treats it with the same seriousness a production system deserves, because for the duration of the programme, it is one.
The reference architecture end to end
The engine is five stages, always in this order: extractor → canonical model → transformer → loader → reconciler.
The extractor against M3
M3 offers three genuinely different extraction sources, and the right choice depends on what the entity is and how sensitive it is to Business-Engine-derived logic:
The canonical lookup registry and the transformation matrix
Every code value that differs between M3 and D365 — order types, warehouse codes, unit-of-measure codes, payment terms, tax codes, and dozens more — is registered once in the canonical lookup registry, not remapped ad hoc inside each transformation.
The loader: DMF, entities and sequencing
The loader writes gold-tier data into D365 through the Data management framework (DMF), organised by entity category:
Dry-run mode, design principles, and what not to build
Every wave runs in dry-run mode before it runs for real: the full extract, transform and validate pipeline executes end to end, against the same source data, producing the same reconciliation report shape a real load would — row counts, sum amounts, sum quantities, key-coverage deltas — with one difference: nothing is written to DMF or…
Operational hardening: the register
A script becomes a production-grade engine through fifteen specific, checkable properties. Treat this as a register to walk through before the first real wave, not an aspiration:
The FAM-function hazard: rules and results migrate differently
M3's accounting model resolves a posting from a FAM function, itself selected by a CO/CR pair on the master data and the operational event. This has a direct and easy-to-miss consequence for how migration has to be scoped: the posting rule and the posted result are two different things, and they migrate through two different mechanisms.
Knowledge check
Summary
The migration engine is a small number of well-defined stages and a much larger number of disciplines that make those stages trustworthy at production volume.