The migration engine: reference architecture and operational hardening

The medallion-shaped extractor-to-reconciler engine that moves LN data into D365 — how it reads LN specifically, the canonical lookup registry and transformation matrix that govern every mapping, the DMF loader and dependency graph, dry-run mode, and the fifteen-dimension operational-hardening register that makes the engine safe to run against a live cutover.

What you will be able to do

• Explain why a canonical bronze/silver/gold model beats point-to-point extracts for an LN migration
• Describe how the extractor reads LN specifically, including its three extraction mechanisms and company-number convention
• Register a canonical lookup value and add a transformation-matrix rule under proper governance
• Use dry-run mode to validate a wave before it ever writes to a target environment
• Name the fifteen operational-hardening dimensions and what each one protects against
• Judge honestly what to build versus what DMF, dual-write and Azure Data Factory already provide

Introduction

Part 1 set the programme's overall shape — waves, sequencing, the eight-wave plan. This part goes one level down, into the engine that actually moves data: how it is architected, how it reads LN specifically, how a value mapping earns the right to be trusted, how the loader sequences seventy D365 entities without violating a single…

The reference architecture end to end

The engine follows a medallion shape: bronze (immutable raw), silver (typed and canonical), gold (D365-shaped), then a DMF load into the target, with a reconciliation service watching every stage.

The extractor against LN specifically

The extractor has to deal with LN as it actually is, not as a generic ERP source, and it offers three extraction mechanisms chosen by volume and deployment model. ION BOD messages are the primary mechanism for LN CloudSuite: ION publishes standardised Business Object Documents on a message bus, and the engine subscribes to them for…

The canonical lookup registry and the transformation matrix

Every LN concept that has a D365 counterpart is registered once, in a canonical lookup model of 38 concepts across five clusters: Legal & Organisational, Chart of Accounts/IMS/Dimensions, Master Data, Open Transactions, and GL & Period. A representative slice looks like this:

The loader: DMF, composite entities and the entity-sequencing dependency graph

The engine does not reimplement D365's own data loading — it produces gold-tier files shaped exactly to what DMF already expects, and then orchestrates DMF's existing recurring data jobs, one DMF data project per wave, eight in total across the programme.

Dry-run mode, the quickstart, and the engine's design principles

Every wave supports dry-run mode: the full extract, the full transform, and the full validation run exactly as they would in a live load, producing the identical reconciliation report a live run would produce — with the one difference that nothing is ever written to the DMF target.

Operational hardening: a fifteen-dimension register

The engine is treated as a production system in its own right, hardened across fifteen dimensions rather than left to depend on individual developer discipline:

What to build versus what DMF, dual-write and Azure Data Factory already give you

The honest engineering judgement here cuts against over-building. DMF's staging, validation, and entity-loading machinery is not something this engine reimplements at all — gold-tier output is deliberately shaped to DMF's existing contract precisely so that DMF's own recurring jobs and composite-entity handling can be reused unchanged.

Knowledge check

Summary

The engine's medallion shape — bronze, silver, gold, DMF, reconciliation — exists to give LN and D365 a stable, versioned interpretation layer between them, extracted through mechanisms chosen for LN's actual deployment model rather than a generic connector.