Everyone has heard the migration horror story — the weekend cutover that became a two-week outage. They’re common, and they’re almost entirely avoidable.
The failures rarely come from the target platform. They come from the approach: a big-bang cutover with no way back, undocumented dependencies discovered mid-flight, and a plan that assumed everything would go right.
Phased, reversible, boring
Good migrations are deliberately unexciting. You move in phases small enough to verify, keep a working rollback at every step, and prove each slice in production before moving the next. It takes longer to plan and far less time to recover from — because there’s nothing to recover from.
The goal of a migration is to be boring. Excitement means something went wrong.
Do the homework the disaster stories skipped
- Map the real dependencies before you move anything — especially the undocumented ones.
- Migrate in slices you can verify, not one weekend you can’t undo.
- Keep a tested rollback at every phase; a plan you can’t reverse isn’t a plan.
- Prove each slice in production before advancing — confidence is earned, not assumed.
Modernisation carries the same discipline. Whether you’re moving to cloud or bringing a legacy system into the modern world, the method is the same: understand what you have, move in controlled steps, and never remove the safety net until the new path is proven.