Why migrations need a plan of their own
A migration moves data, processes and users from an existing setup to a new one. It looks like a technical task, but most of the difficulty is usually organizational: people rely on the old system in ways nobody wrote down, data is messier than expected, and the business cannot stop operating while the change happens.
This article gives a map of the whole journey. Other articles in this cluster go deeper on individual steps. The aim here is to show how the phases fit together, where the main risks sit and which checkpoints are worth having.
A note on scope: this is general information. Every organization’s systems, contracts and obligations differ, so treat the phases below as a starting structure rather than a prescription.
Phase 1: Assess the current state
Before choosing how to move, find out what you have. That means listing systems, data stores, interfaces between systems, reports, scheduled jobs and the unofficial workarounds people use, such as a spreadsheet that quietly fills a gap. A proper current state assessment is the foundation for every later estimate. Skipped or rushed, it is a common reason plans turn out to be optimistic.
At the end of this phase you should be able to say what is in scope, what is not, who owns each piece and what depends on what.
Phase 2: Define goals, scope and governance
Write down why the migration is happening and what “done” means. Reasons vary: an unsupported product, a wish to bring several local tools into one, a merger, or a need for better reporting. Be honest about trade-offs. Moving to a central platform can bring consistency, but it can also create single points of failure and slow local decisions, so the goals should say what you are willing to give up.
Decide who makes decisions. Clear decision rights and a named system owner prevent arguments in the middle of cutover weekend. Many projects use a steering committee to resolve trade-offs between scope, time and risk.
Phase 3: Design the target and the approach
This phase covers the target design, the data approach and the cutover strategy. Key questions include:
- Which data moves, which is archived and which is left behind?
- How will fields in the old system map to fields in the new one?
- Will the switch happen at once or in stages?
- Which integrations must be rebuilt, and how will you check system interoperability?
If a new product is still being chosen, requirements gathering and a fair software pilot belong before this phase rather than inside it.
Phase 4: Prepare the data and build
Data work is often the longest part. It includes mapping, cleansing and validation, and the practical details are covered in the data migration article in this cluster. Expect to find data quality issues that nobody knew about, such as duplicate customers or inconsistent codes. Decide in advance who has authority to resolve them, which is where data stewardship roles become useful.
Alongside data work, configure the new system, build integrations and prepare documentation, including updated standard operating procedures.
Phase 5: Test
Testing should cover whether the new system works technically, whether data arrived intact and whether real users can do their jobs. Go-live testing usually combines several layers, run by different people. The aim is not to prove the system is perfect, but to find out what is wrong while it is still cheap to fix.
Phase 6: Prepare people and the business
Technical readiness is not the same as organizational readiness. Training, communication and local support matter. Organizational change management practices, a change communication plan and a network of change champions can all help, and they work best when started early rather than the week before launch. Expect some change resistance; it is often a signal about a real gap in the design rather than simple reluctance.
Phase 7: Cutover and stabilization
Cutover is the moment of switching. The approach may be a single switch or a series of smaller moves, and each carries a different risk profile. Whichever you choose, agree a rollback plan beforehand, including the point after which going back is no longer realistic. Some projects run both systems side by side for a period, which reduces some risks but adds cost and confusion.
After go-live, plan for a stabilization period with extra support, fast fixes and close monitoring of issues. Adoption measurement helps show whether people are actually using the new system as intended.
Phase 8: Decommission the old system
Retiring the old system is easy to postpone and easy to do badly. Safe decommissioning means confirming that data has been archived or migrated, that retention obligations are met, that access is removed and that nothing still depends on the old system. Leaving it running indefinitely is not free: it costs money, carries security exposure and keeps two sources of truth alive.
Checkpoints worth having
A migration benefits from a small number of formal decision points, each with criteria agreed in advance:
- Scope and plan approved. The assessment is complete and the approach is agreed.
- Data readiness. Mapping is signed off and trial loads reconcile within agreed tolerances.
- Test exit. Agreed testing is complete and open defects are understood and accepted.
- Go/no-go. Business, technical and support leads confirm readiness, including the rollback plan.
- Stabilization exit. Issues have settled and the old system can move to retirement.
The value of a checkpoint comes from the criteria being written down before anyone is under pressure to pass it.
Common risks
- Hidden dependencies, including informal workarounds and undocumented interfaces.
- Data quality, which is usually worse than assumed.
- Underestimated effort, especially for testing and for people-related work.
- Key-person dependence, where one individual knows how an old system really works.
- Business calendar clashes, such as cutover during a busy period or a financial close process.
- Weak ownership, where nobody is accountable for decisions after go-live.
None of these can be removed entirely. Planning reduces how often they surprise you, and outcomes remain uncertain even in well-run projects.