Migration Risk
The specific risks migrations carry, and the controls that reduce each — with reversibility as the master control.
Definition
Migration risk is the probability and consequence of things going wrong during a transition. It is higher than normal change risk because two systems are involved, both are moving, and the failure modes are unfamiliar.
The risks and their controls
| Risk | Control |
|---|---|
| Data loss or corruption | Verification at every stage; reconciliation; source kept intact and readable |
| Undocumented behaviour missed | Run-and-compare against the old system on production traffic |
| Extended outage | Rehearsed cutover with timed steps; phased rather than big-bang |
| No way back | Reversibility maintained to the last possible step; rollback tested |
| Performance regression | Load test the target with production-scale data before cutover |
| Integration breakage | Contract tests; consumer inventory from actual traffic |
| Programme cancellation | Sequence so every step delivers value independently |
| Running both indefinitely | Decommissioning budgeted as explicit work; track capabilities remaining on legacy |
The master control: reversibility
Every step should be reversible until the last possible moment, and the point where reversibility ends should be named explicitly in the plan.
Practically: route behind a flag so traffic can be shifted back instantly; keep the source updated via reverse replication for a period after write cutover; and take the irreversible step alone, after verification, rather than bundled with others.
The under-rated control: run-and-compare
Send production traffic to both systems, serve the old result, log every difference. This is the only reliable way to discover the undocumented behaviour that no specification contains, and it will find dozens of cases.
Budget time to triage them — some differences are legacy bugs you should not replicate, and deciding which is a business conversation rather than an engineering one.
Risk concentration
Migrations concentrate risk at the cutover. Every technique that spreads it — phasing by segment, gradual traffic shifting, capability-by-capability strangling — reduces total risk even though it increases total effort and duration.
That trade is almost always worth making, and the pressure to compress it into a single event usually comes from wanting the programme to be over rather than from a genuine constraint.
Interview question
"What is the single most important risk control in a migration, and why?"