Inside the migration engine: extractor, canonical model, loader, reconciler
The programme-level view in chapter 1 told you what the eight waves do. This chapter opens the engine that actually moves the data: why Fusion's SaaS boundary rules out a direct database query, why a canonical bronze/silver/gold layer beats point-to-point mapping, how a value mapping gets registered and governed, how the loader sequences seventy-six D365 entities, and the fifteen-dimension operational-hardening register that turns a migration script into a production system.
What you will be able to do
Explain why the engine reads Fusion through BICC, OTBI and REST rather than a direct database connection, and how that constraint shapes the whole architecture
Describe the bronze/silver/gold canonical layer and why it scales better than point-to-point field mapping across seventy-six business objects
State what a transformation-matrix rule must declare and who is authorised to approve it
Contrast the D365 loader's DMF entity model — categories, composite entities, parallel execution — with the FBDI model the reader already knows
Decide, with reasons, whether to migrate Fusion's Subledger Accounting output as data or re-derive it through D365 posting profiles
Introduction
Chapter 1 of this domain described the eight data-migration waves from the outside: what each wave loads, in what order, and why the order is dependency-driven rather than calendar-driven.
The reference architecture end to end
The engine follows a medallion shape — the same bronze/silver/gold pattern used across the Microsoft data estate generally — with extraction adapters built specifically for Fusion's surfaces.
The extractor against Fusion: BICC, OTBI, REST — and the wall around the database
The single fact that shapes this entire architecture is that the engine cannot query the Fusion database. Fusion is SaaS; there is no schema-level connection to open, no SELECT * FROM available to a migration engineer no matter how senior.
Registering a mapping: the canonical lookup registry and the transformation matrix
Every value that crosses from a Fusion code to a D365 code — a payment-terms code, a unit of measure, a tax classification, a customer class — is a mapping decision, and every mapping decision is registered, not improvised.
The loader: DMF entities, composite entities and the wave-dependency graph
You already know FBDI's shape from the Fusion side: one template per object, one interface table it lands in, one ESS job that validates and posts it. D365's Data Management Framework (DMF) is the loader on the other end of this engine, and its model is deliberately more explicit about structure than FBDI's.
Dry-run mode and the engine's design principles
Every wave supports a dry-run mode: the full extract, transform and validation pipeline executes exactly as a live run would, but the final DMF target write is skipped. Dry-run produces the same recon report a live run would produce — the same row counts, sums and key-coverage deltas — which makes it the tool of choice for rehearsing a…
Operational hardening: a fifteen-dimension register
The engine is hardened as a production system, not treated as a disposable script, across fifteen named dimensions.
Build versus buy, and the Subledger Accounting hazard
Not everything described in this chapter should be built from scratch, and knowing where the line sits saves real programme time.
Knowledge check
Summary
The engine cannot query the Fusion database directly; it reads through BICC (bulk), REST (narrow/latency-sensitive), OTBI (validation) and FBDI's interface-table shape, and this constraint shapes the entire architecture.