Extraction, transformation and the DMF load

Extraction from the Maconomy database and service layer, the medallion transformation architecture (Bronze–Silver–Gold), canonical modelling with fifteen project-centric domains, composite entity load design, batch sizing, throttling, and a worked lineage for a job with its task hierarchy, budget and WIP position through to the D365 project entity — plus the reconciliation gates that block wave progression.

What you will be able to do

Introduction

The transition-engine chapter covers the mechanics of moving data from Maconomy into Dynamics 365 Finance and Supply Chain Management: how data is extracted, how it flows through a medallion transformation architecture, how the canonical model handles Maconomy's project-centric complexity, and how the Data Management Framework loads it…

Extraction from Maconomy

Maconomy provides multiple data-access surfaces whose availability depends on the discovered version and deployment:

The medallion architecture

The migration engine uses a three-layer medallion model: Bronze (raw), Silver (canonical), Gold (DMF-ready).

Composite entities and DMF load design

D365 provides composite data entities that write to multiple tables in a single operation. For project migration, the key composites are:

Worked lineage: job with task hierarchy, budget and WIP

This section traces a single Maconomy job through the full pipeline to illustrate how each layer adds value.

Reconciliation gates

Each wave has a reconciliation gate that must pass before the next wave begins. The gate compares four corners:

WIP and unbilled revenue: the hardest control

WIP reconciliation is the single hardest control in a professional-services migration because:

Knowledge check

Summary

The migration engine for a Maconomy programme is distinguished by its project-centric complexity: multi-role tasks that must be decomposed, budget hierarchies with revision history, and WIP positions that cannot be copied but must be reconstructed and reconciled.