How a disciplined extractor → canonical model → transformer → loader → reconciler pipeline replaces point-to-point IFS-to-D365 mapping, why the engine reads Oracle tables rather than the _API for bulk waves, and the fifteen operational-hardening dimensions that turn a migration script into a production system.
Chapter 1 of this track described the programme shape: stages, waves and the decisions an IFS-to-D365 migration must sequence correctly. This chapter goes one level down, into the engine that actually moves the data — the software that reads IFS, reshapes it, and proves to a CFO's satisfaction that what landed in D365 is what was really…
The engine follows a medallion shape — bronze, silver, gold — with IFS-specific extraction adapters bolted onto the left edge and D365 F&O's Data Management Framework (DMF) consuming the right edge.
An IFS PL/SQL developer's first instinct when asked to pull data out of IFS is usually correct about the tool, and wrong about the layer. Writing SQL directly against Oracle is legitimate — the engine does exactly that for bulk waves — but it reads base _TAB tables through a read replica, not through hand-written joins against whatever…
The canonical lookup model is the engine's neutral intermediate representation: 37 canonical concepts, grouped into five clusters (Legal & Organizational; Chart of Accounts & Dimensions; Master Data; Open Transactions; GL & Period).
Where the canonical lookup model defines what a concept means, the transformation matrix defines how each field of each business object is actually converted. It is scoped to the same eight LU families used throughout the programme:
Gold-tier data reaches D365 through DMF, and the engine treats DMF strictly as the loader, not as the whole solution. One DMF data project exists per wave — eight in total — using recurring data jobs in preference to interactive, manually triggered imports, because recurring jobs are what a scheduled, auditable pipeline needs.
The engine follows eight architectural principles, and each one answers a way a migration script normally fails:
The engine is treated as a production system, not a migration script, and is hardened across fifteen dimensions. Each is worth understanding as a specific, concrete control rather than a compliance checkbox:
IFS's PostingCtrl matrix is the single largest design exercise in a financials migration, and it creates a hazard specific to this engine that is worth stating as plainly as the brief that shaped this chapter demands: PostingCtrl's rules and PostingCtrl's history are two different migration problems, solved by two different mechanisms,…
The transformation matrix is not a supporting spreadsheet; it is the executable contract for the silver-to-gold transforms. The engineering wave produces one CSV artefact per family — matrix-financials.csv, matrix-scm.csv, matrix-manufacturing.csv, matrix-eam-service.csv, matrix-projects.csv, matrix-hcm.csv, matrix-crm.csv and…
The fifteen hardening dimensions are easiest to remember as controls that must exist before the first production dry run:
The medallion engine is a production application, so its principles must be testable:
The migration engine's job is to make an IFS-to-D365 data migration provable, not just plausible. A canonical, versioned intermediate model — governed the same way any shared configuration should be — replaces the private knowledge that lives in a point-to-point script.