A Workday-to-D365 programme follows seven stages — orient, discover, decide, build, prove, cutover, stabilise — but its specific risks and traps are distinctive. This module covers what to inventory in a Workday estate, how data migration waves are sequenced, the Workday-specific design traps (Worktags as product dimensions, BPF agility expectations, HCM boundary, effective-dating), and how to run a mock cutover for a Workday estate.
Every ERP programme has a lifecycle — assessment, build, test, cutover, stabilise. A Workday-to-D365 programme follows the same broad arc, but its specific risks, its estate inventory content, its design traps, and its cutover mechanics are distinctive.
The Orient stage confirms that the programme is technically feasible and establishes the guiding principles. Key Workday-specific decisions at this stage:
The Decide stage produces the architecture and design blueprints for D365. Several Workday-specific decisions must be locked here; changing them after the Build phase begins is very expensive.
Data migration follows an eight-wave dependency sequence. Later waves have foreign-key dependencies on earlier waves; the sequence is mandatory.
The Workday cutover has three phases that are specific to Workday's process-driven architecture:
Hypercare is the four-to-twelve week period following go-live during which the programme team provides heightened support. Workday-specific hypercare priorities:
A Workday-to-D365 programme is not simply a data migration with a configuration layer on top. The unique characteristics of the Workday estate — its BPF-driven process model, its Worktag analytical layer, its managed integration cloud, its HCM-Finance coupling, and its effective-dated object graph — each produce a distinct design and…