Chapter 4
Transition Phase, Migration Execution
Chapter 4
Transition Phase, Migration Execution
The transition phase is where the design is tested.
Everything the organisation decided in the design phase how processes should work, what data should look like, which variations are approved and which are eliminated, how the system should be configured now becomes real. The documents become configurations. The decisions become data mappings. The approved process designs become system workflows that will either work or will not.
This is the most visible phase of the migration and the most unforgiving. It is the phase where the consequences of design decisions arrive the good ones and the bad ones simultaneously. The process that was designed clearly and documented completely configures cleanly and migrates smoothly. The process that was ambiguous in the design phase produces configuration questions that have no good answers under execution pressure. The data that was cleansed and validated in the design phase migrates without incident. The data that was assumed to be clean produces errors that must be resolved in the migration window.
The transition phase does not create problems. It inherits them from the design phase, from the data quality work that was or was not done, from the process standardisation that was or was not completed. The organisation that arrives at transition with a complete, documented, agreed design will find the transition challenging but manageable. The organisation that arrives with gaps will find the gaps during execution at full cost and under full pressure.
Cutover is not the finish line. It is the moment where everything that was prepared is either sufficient or it is not.
Key Takeaway:
The transition phase inherits the quality of the design phase. Strong design produces manageable execution. Weak design produces expensive surprises. The transition phase reveals which one the organisation built at the moment when there is least time and least capacity to respond.
"Cutover doesn't create problems. It reveals the ones you didn't solve."
MarvinPro_|_March_2026
marvinpro.com
The transition phase begins with the execution of a strategy that was chosen in the design phase. In the transition phase that strategy becomes concrete, it determines how data moves, how teams are organised, how the organisation maintains operational continuity during the migration window and how risk is managed when things do not go exactly as planned.
Three execution strategies are available for any migration whether ERP, CRM, cloud productivity platform or any other system transition.
Big Bang moves the entire organisation to the new system at once. One cutover date. One go-live. All processes, all data, all users simultaneously. Big Bang is the highest risk approach, a failure during the cutover window affects the entire organisation. But it is also the cleanest, there is no period of parallel operation, no reconciliation between old and new systems, no ambiguity about which system is the source of truth. Big Bang works when the design is complete, the data is clean and the organisation has the change management capacity to absorb a simultaneous transition. It fails when any of these conditions are not met.
Staged rollout moves the organisation in phases market by market, function by function or process by process. Each phase has its own cutover, its own testing and its own period of elevated support. Staged 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. Staged rollout works well for large, complex organisations where a Big Bang is genuinely not feasible.
Hybrid combines elements of both. Some processes or markets move in a Big Bang. Others follow in subsequent phases. The hybrid approach is the most common in large, multi-market organisations because it balances risk management with timeline discipline.
The choice between these strategies is not primarily a technical decision. It is a decision about the organisation's risk tolerance, its process maturity and its change management capacity. The strategy that matches these factors will succeed. The strategy chosen for the wrong reasons, to compress the timeline, to reduce the visible cost of the migration or to avoid the difficult conversations that a proper design phase requires will fail.
Key Takeaway:
The migration strategy must match the organisation's risk tolerance, process maturity and change management capacity. No strategy is universally correct. The strategy chosen must be executed with full commitment, a staged rollout compressed to Big Bang timelines, or a Big Bang without complete preparation, will fail.
"The migration strategy chosen for speed rather than maturity carries the cost of that choice forward indefinitely."
MarvinPro_|_March_2026
marvinpro.com
Data migration is the technical core of the transition phase and the area where the most migration failures originate. Not because the tools are inadequate, modern data migration tools are mature and capable. But because the data itself was not prepared.
Data that has been maintained in a legacy system over years accumulates inconsistencies that are invisible in normal operations. Duplicate records that the legacy system accommodated because both versions were used by different teams. Incomplete records that the legacy system allowed because the missing fields were not required for the processes the legacy system supported. Incorrectly formatted data that the legacy system accepted because its validation logic was less rigorous than the new system requires. Regional variations in data structure that the legacy system tolerated because it was never asked to produce a consolidated global view.
None of these problems are visible until the data is subjected to the validation logic of the new system. Then they surface all at once, in the migration window, with the go-live date fixed and insufficient time to resolve them properly.
The solution is data migration work that begins in the design phase and continues through the transition phase in a defined sequence. Data extraction pulls the data from the legacy system in the correct format. Data cleansing identifies and resolves inconsistencies, duplicates and gaps. Data mapping translates legacy data structures into the new system's data model. Data validation loads the cleansed, mapped data into a test environment and confirms that it produces the correct results, not just that it loads without error, but that it supports the processes the new system will execute.
Each of these stages takes longer than anticipated. The organisations that plan for this, that begin data migration work early, that allocate sufficient time for cleansing and that involve process owners in validation, arrive at the migration window with data that is ready. The organisations that underestimate the data migration work arrive with data problems that must be resolved under pressure.
Key Takeaway:
Data migration is a business activity, not a technical one. The data quality decisions made during cleansing and mapping determine whether the new system works correctly after go-live. Process owners must be involved in data validation, not just the technical team because the errors that matter most are the ones that load without error but produce incorrect business outcomes.
"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 and no tolerance for uncertainty.
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, a clear dependency on the activities that precede it and a defined escalation path if it fails. Every activity that runs long affects every activity that follows. Every activity that fails must have a rollback procedure that can be executed without debate.
The cutover plan must be rehearsed before it is executed. Not reviewed, rehearsed. The team must run through the plan in a simulated environment, under conditions as close to the real cutover as possible, before the real window opens. 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 rehearsal is not optional. It is the investment that makes the real cutover manageable. The organisation that rehearses its cutover arrives at the real window knowing exactly what will happen, in what order, at what pace and who is responsible for each activity. The organisation that does not rehearse arrives at the real window discovering these things for the first time at the moment when discovery is most expensive.
The cutover plan must also include a defined go or no-go decision point. Before the legacy system goes offline the migration leadership must assess whether the preparation is sufficient to proceed. This assessment requires predefined criteria specific, measurable standards that must be met before the cutover window opens. If the criteria are not met the decision must be to delay, not to proceed and hope that the problems resolve themselves in the window.
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. Improvisation during the cutover window is not a contingency, it is a failure mode.
"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 migrating its operations across multiple European markets using a staged rollout approach, the data migration for the first market surfaced a problem that had not been identified during the design phase.
A specific category of operational records had been maintained using a date format that was standard in the legacy system but incompatible with the new system's data model. The records were not invalid, they were accurate and complete. But the format could not be automatically mapped to the new system without a conversion that had not been defined in the data migration specification.
The problem was discovered during data validation three weeks before the go-live date for the first market. Three weeks was enough time to define the conversion logic, implement it and revalidate the affected records. The go-live proceeded on schedule.
The resolution was documented and applied to every subsequent market migration before the data extraction began. The same problem did not occur in any subsequent market because it had been identified and resolved in the first market and the fix had been incorporated into the standard data migration process before the next market began.
This is the compounding return on staged rollout. The problems discovered in the first market become the prevention investment for every subsequent market. The organisation that treats each market migration as an independent project loses this compounding return. The organisation that treats the staged rollout as a single, progressive migration capturing the learning from each phase and applying it to the next builds capability that makes each subsequent phase faster, cheaper and more reliable than the last.
"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. The design work, the data cleansing, the process standardisation, the cutover rehearsal, all of it is tested in the transition phase against the actual conditions of the migration.
Choose the migration strategy deliberately. Execute the data migration as a business activity with process owner involvement. Plan the cutover in detail and rehearse it before the window opens. Define the go or no-go criteria before the cutover begins.
The transition phase will always 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 because the difficulty is known, planned for and manageable.
The organisation that arrives without those foundations will navigate it differently, discovering what it costs to make transition decisions under execution pressure, at the moment when those decisions are most expensive and least reversible.
"Preparation does not guarantee a smooth transition. It guarantees that the difficulty is known, planned for and survivable."
MarvinPro_|_March_2026
marvinpro.com