How the programme runs, what to inventory, and where SAP-specific traps hide
How an SAP-to-D365 F&O programme is structured across seven stages — from assessment through hypercare — including what to inventory in the SAP estate, how data migration waves are sequenced, how testing and mock cutovers work, and where SAP-specific assumptions cause the most expensive failures.
What you will be able to do
Describe the seven programme stages and the key deliverable that gates each transition
List the SAP estate artefacts that must be inventoried before fit-gap begins
Explain the data migration wave sequence and why each dependency ordering constraint exists
Identify the SAP-specific assumptions that cause the most common migration failures
Describe the four-corner reconciliation and why it is the go/no-go criterion for cutover
Introduction
An SAP-to-D365 programme is not primarily a technology project. It is a re-expression of one organisation's way of running its business — encoded in SAP configuration, SAP customisations, and accumulated SAP data — into a new system that uses different abstractions. The technology work is real and substantial;
Why this migration matters and what scope really means
The executive framing is not that SAP ECC is bad and D365 is good. It is that many ECC estates are at the end of a long maintenance arc: Enhancement Packages such as EHP8, deep custom code, ageing integration patterns and regulatory controls that now expect cloud-era evidence.
The seven programme stages
The following stages apply to an SAP-to-D365 programme of any size. The names are descriptive rather than methodology-specific.
The SAP estate inventory
Before fit-gap workshops begin, the team needs a factual picture of what the source SAP system is actually doing. This inventory has five components.
Data migration waves and load sequencing
The data migration load is sequenced by dependency: an object cannot be loaded until all objects it references are already present. The canonical model defines eight dependency-ordered waves.
Testing strategy: SIT, UAT, and regression
SIT validates that D365 behaves correctly end-to-end for each business process. SIT test scripts should be derived from the fit-gap, not from the existing SAP test scripts — the processes may have changed. Key SAP-specific SIT scenarios:
SAP-specific traps
The following assumptions are specific to SAP organisations and cause failures that are not obvious to teams without prior SAP migration experience.
Knowledge check
Summary
A well-run SAP-to-D365 programme follows seven stages, gates each stage with a factual deliverable, and does not allow the Decide stage to begin without completing the SAP estate inventory.