Chapter 4
Transition Phase, Migration Strategy and Execution
Chapter 4
Transition Phase, Migration Strategy and Execution
The transition phase is where the design becomes reality. It is the most visible phase of the migration and the most unforgiving.
Everything that was undefined in the design phase surfaces here. Every process that was not documented creates a decision that must be made under pressure. Every piece of master data that was not cleansed creates a validation failure that must be resolved on the migration timeline. Every integration that was not mapped creates a cutover problem that cannot wait.
The transition phase does not create problems. It reveals them at the worst possible time, with the least possible tolerance for delay.
The organisations that execute the transition phase well are almost always the ones that did the design phase well. The work that appears to happen in transition actually happened in design. The transition phase is the delivery of a foundation that was built months earlier.
Cutover is not the finish line. It is the moment where preparation is tested.
Key Takeaway:
The quality of the transition phase is a direct reflection of the quality of the design phase. Organisations that arrive at transition with a complete design execute it well. Organisations that arrive with gaps pay for them during execution at full cost and under full pressure.
"Cutover doesn't create problems. It reveals the ones you didn't solve."
MarvinPro_|_March_2026
marvinpro.com
The transition phase begins with a decision that was made in design the migration strategy. But in the transition phase that strategy becomes concrete. It determines how data moves, how teams are organised, how risk is managed and how the organisation maintains operational continuity during the migration.
Three execution models are available.
Big Bang moves the entire organisation to the new system at once. One cutover date. One go-live. All markets, all processes, all data simultaneously. Big Bang is the highest risk approach, a failure during cutover affects the entire organisation. But it is also the highest control approach, there is no period of dual-system operation, no reconciliation between legacy and new, no ambiguity about which system is the system of record.
Big Bang works when the design is complete, the data is clean, the testing is thorough and the organisation has the change management capacity to absorb a simultaneous transition. It fails when any of those conditions are not met.
Phased Rollout moves the organisation country by country, region by region or function by function. Each phase is a contained migration with its own cutover, its own testing and its own hypercare period. Phased rollout reduces the risk of any single failure affecting the entire organisation but it extends the overall migration timeline and requires a period of dual-system operation that creates reconciliation complexity.
Phased rollout works well for large, complex organisations where a Big Bang is genuinely not feasible. It requires discipline, the temptation to compress timelines between phases must be resisted.
Parallel Run operates both the legacy system and the new system simultaneously for a defined period, validating critical processes in both environments before full cutover. Parallel run is not a full duplication of operations, it is a controlled validation for the highest-risk processes. It adds cost and complexity but provides the highest confidence before the legacy system is decommissioned.
Key Takeaway:
The migration strategy must match the organisation's risk tolerance, process maturity and operational complexity. No strategy is universally correct. The strategy chosen must be executed with full commitment, a phased rollout treated as a Big Bang, or a Big Bang without complete preparation, will fail.
"The migration strategy chosen without full commitment to its requirements is a strategy that will fail at the moment it is most needed."
MarvinPro_|_March_2026
marvinpro.com
Data migration is the technical core of the transition phase. It is also the area where the most migration failures originate, not because the data migration tools are inadequate, but because the data itself was not prepared.
In S/4HANA the Migration Cockpit is the primary tool for data migration and validation. It maps legacy data objects to S/4HANA objects, validates the mapping against the system configuration and flags errors before data is loaded. The tool is mature and well-designed. It cannot compensate for data that is inconsistent, incomplete or incorrectly structured.
Data migration has four stages that must be completed in sequence.
Data extraction, pulling the data from the legacy system in the correct format. This requires a complete understanding of the legacy data model which is often undocumented and inconsistent across regions.
Data cleansing, identifying and resolving inconsistencies, duplicates and missing values. This is the stage most organisations underestimate. The volume of data quality issues discovered during cleansing is almost always larger than anticipated.
Data mapping, translating legacy data structures into S/4HANA objects. Every field in the legacy system must be mapped to a field in S/4HANA. Every object type, business partner, material, cost centre, must be validated against the design specification.
Data validation, loading the data into a test environment and validating that it produces the correct results in the system. Validation must be conducted by the process owners, not just the technical team. A business partner record that loads without error but represents the wrong customer is a data migration failure that only a process owner can identify.
Key Takeaway:
Data migration is a business activity, not a technical one. The data quality decisions made during cleansing and mapping determine whether the system works correctly after go-live. Process owners must be involved in data validation not just the technical team.
"Data migration is not complete when the data loads without error. It is complete when the data produces the correct business outcome."
MarvinPro_|_March_2026
marvinpro.com
Cutover is the most compressed and highest-risk period of the entire migration. It is the window between the legacy system going offline and the new system going live. Everything that happens in this window must be planned in detail because there is no time to improvise.
A cutover plan is not a project plan. It is a minute-by-minute sequence of activities, each with a named owner, a defined duration and a clear dependency on the activities that precede it. Every activity that runs long affects every activity that follows. Every activity that fails must have a defined escalation path and a rollback procedure.
The cutover plan must be rehearsed. Not reviewed, rehearsed. The team must run through the plan in a simulated environment before the real cutover begins. Every gap in the plan, every activity that takes longer than estimated, every dependency that was not identified, all of these are better discovered in rehearsal than in production.
The cutover plan must also include a go or no-go decision point. At a defined point in the cutover sequence the migration leadership must make a decision, proceed to go-live or roll back to the legacy system. This decision requires predefined criteria. What is the maximum acceptable number of open data migration errors? What is the maximum acceptable number of failed integration tests? What is the maximum acceptable delay to the go-live timeline?
These criteria must be agreed before cutover begins. A go or no-go decision made under pressure, without predefined criteria, in the middle of a cutover window is a decision that will be made badly.
Key Takeaway:
Cutover is the execution of a plan not the creation of one. The plan must be complete, rehearsed and supported by predefined go or no-go criteria before the cutover window opens. Improvisation during cutover is a risk that no organisation can afford.
"A cutover plan that has not been rehearsed is not a plan. It is a list of intentions."
MarvinPro_|_March_2026
marvinpro.com
In a large organisation executing a phased migration across multiple European markets, the cutover plan for the first market was rehearsed three times before the live cutover began.
The first rehearsal identified twelve gaps in the plan, activities that had been described at a high level but not specified in sufficient detail to be executable. Two of those gaps involved data validation steps that had been assigned to the technical team but required business process knowledge that only the domain owners had. Both gaps were reassigned before the second rehearsal.
The second rehearsal identified four timing errors, activities whose estimated duration was significantly shorter than the actual time required. The cutover window was extended by six hours to accommodate the revised estimates. Had this not been identified in rehearsal, the go-live would have been delayed.
The third rehearsal ran cleanly. The live cutover followed the plan exactly.
The first market went live on schedule. The data migration completed within the cutover window. The go or no-go decision was made with three hours to spare against the criteria that had been agreed in advance.
The second market migration benefited from everything learned in the first. The rehearsal process was faster because the plan was more complete. The cutover window was shorter because the team was more experienced. The go-live was smoother because the process had already been proven.
This is the compounding return on cutover preparation. The investment in rehearsal for the first market paid dividends across every subsequent market.
"The cutover that goes well was rehearsed. The one that fails was assumed."
MarvinPro_|_March_2026
marvinpro.com
Chapter Outcome:
The transition phase is where preparation meets reality. Everything that was invested in the design phase, process documentation, master data cleansing, standardisation decisions, domain ownership pays back here.
Choose the migration strategy deliberately. Execute the data migration as a business activity, not a technical one. Plan the cutover in detail and rehearse it before the window opens. Define the go or no-go criteria in advance.
The transition phase will still be demanding. No migration is without pressure. But the organisation that arrives at transition with a complete design, clean data and a rehearsed cutover plan will navigate that pressure successfully.
The organisation that arrives without those foundations will discover what they cost at exactly the moment when there is no time to fix them.
"The cutover window is not the time to make decisions. It is the time to execute them. Every decision made in the window is a decision that was not made in the design phase."
MarvinPro_|_March_2026
marvinpro.com