How NetSuite data actually becomes reconciled D365 data: the medallion-shaped extractor-to-reconciler pipeline, the four governed ways to get data out of a NetSuite account (and the one thing none of them can do — read the production database directly), the 38-concept canonical lookup model, the DMF loader's entity categories and dependency graph, dry-run mode, the fifteen-dimension operational-hardening register, and the per-item posting-account hazard that forces custom engineering no matter how much of the rest DMF and Dual-write give you for free.
Chapter 1 of this domain laid out the programme shape: the wave sequence, the legal-entity re-architecture, and the release-cadence ownership NetSuite never made you think about.
The engine follows a medallion shape: extractor → bronze → canonical (silver) → transformer → gold → loader (DMF) → reconciler. Each arrow is a real boundary, not a formality.
NetSuite exposes exactly four ways to get data out at the volumes a migration needs, and the engine picks between them by volume and latency, never by convenience:
The canonical lookup model is the silver tier's backbone: 38 canonical concepts, grouped into five clusters — legal and organisational, chart of accounts and dimensions, master data, transactional, and GL/period concepts — each with a stable key, the NetSuite source record(s) it draws from, and the D365 target entity it feeds.
Once gold-tier files land in Blob storage, the Data Management Framework is the canonical bulk-ingress mechanism into D365 — and it is a genuinely different animal from the CSV import or the SuiteScript loader script a NetSuite developer already knows.
Every wave supports a dry-run mode: the full extract-transform-validate path runs exactly as it would live, producing the same reconciliation report a live run would produce, but performing no DMF target write. In practice, running one looks like this:
The engine is treated as a production system, not a migration script, and is hardened across fifteen dimensions. Two of them — retry/backoff and the kill switches — are the last line of defence if a live cutover starts to go wrong; the rest are what make the other thirteen trustworthy enough to rely on in the first place.
Not everything in this chapter needs to be built from scratch, and pretending otherwise wastes a programme's budget. DMF is Microsoft's own, already-hardened bulk-load path — the engine's loader sits on top of it rather than reimplementing staging, validation and parallel execution.
The engine is easier to operate when its artefacts are named exactly and consistently. Three artefacts that often get summarised away — the NetSuite source-landscape inventory, the per-field transformation matrix, and the reconciliation report — are the objects a migration lead actually uses every day.
The migration engine is not a script that copies NetSuite records into D365 tables — it is a medallion-shaped, governed pipeline built because NetSuite exposes no direct database access, D365's data model does not match NetSuite's field-for-field, and a 24-hour cutover window has no tolerance for a load that cannot be resumed, audited or…