The medallion engine, from extraction to reconciliation

The medallion architecture for a Plex-to-D365 migration — Bronze (immutable raw extract with no version to pin, only a date), Silver (conformed via the canonical lookup model), Gold (D365-entity-shaped for the Data Management Framework) — plus extraction routes, cross-reference tables, idempotent reruns, data-quality gates and the special problem of container-identified inventory.

What you will be able to do

Introduction

The previous chapter set the programme shape: gating decisions, wave sequencing and the discovery artefacts that gate design. This chapter goes one layer down, into the engine that actually moves the data — because a Plex migration carries one extraction constraint that no on-premises adapter in this hub faces: there is no version to…

Extraction: no database, no version, only APIs and reports

Plex is a true multi-tenant SaaS platform. There is no customer-accessible database, no ODBC/JDBC connection, no file-system export path. The practical extraction routes are:

Bronze: the immutable record of source state

Bronze is one Delta table per Plex source object per extract run, landing in OneLake (or Azure Data Lake Storage). No transformation. No type coercion. No deduplication. Bronze is the legal record of what Plex returned at the moment of extraction.

Silver: the canonical lookup model applied

Silver is where the canonical model (covered in the programme-shape chapter) does its work. Each Silver table represents one canonical concept — typed, de-duplicated and conformed — with every Plex value translated through the governed lookup registry.

Gold: D365-entity-shaped for DMF

Gold reshapes Silver into the exact contract the Data Management Framework expects: column names matching the D365 data-entity field names, enumerations matching the entity's enum values, financial-dimension combinations expressed as the hyphen-delimited string format D365 requires, and composite-entity parent/child grouping for entities…

Cross-reference tables: Plex key to D365 key

Every record loaded into D365 receives a cross-reference entry mapping its Plex natural key to its D365 natural key (or RecId where no natural key exists). This registry is the backbone of reconciliation, rerun and traceability.

Data-quality gates and the reconciliation harness

Every wave has a reconciliation gate. The engine refuses to advance to the next wave until the gate passes. Gates are not a post-load check — they are built into the engine's progression logic.

Container-identified inventory: the special transformation

Plex MES identifies inventory by container — a physical unit (pallet, tote, bin) that carries parts through the shop floor. D365 Warehouse management identifies inventory by licence plate (a logical or physical label on a handling unit) plus batch and serial tracking dimensions.

Idempotent reruns and operational hardening

Same input yields same result. A Bronze partition processed twice produces identical Silver/Gold output; a Gold package submitted twice with the same idempotency key does not create duplicates in D365. Resumable at wave boundary.

Dress rehearsals: how many is enough

A dress rehearsal is a complete end-to-end execution of the engine — extraction, Bronze, Silver, Gold, DMF load, reconciliation — against production-volume data in a non-production D365 environment. It proves the engine works at scale within the agreed cutover window.

Knowledge check

Summary

The medallion engine for a Plex programme follows the same Bronze → Silver → Gold → DMF → Reconcile shape as any adapter in this hub, but with three Plex-specific features: schema-drift defence substitutes for the version freeze Plex cannot provide, the module-aware Silver layer prevents the engine from assuming unlicensed products are…