What actually slows down a cloud migration

Every migration plan starts with a clean wave schedule: move these ten applications this quarter, those twenty next quarter. The schedule almost always looks reasonable on a slide. What breaks it, consistently, is discovering mid-migration that an application scheduled for wave two has an undocumented dependency on something in wave four — a shared database, a legacy authentication service, a batch job nobody remembered was still running.

Dependency mapping feels like overhead when a program is under pressure to show early progress, so it's the first thing teams try to skip or shortcut. That's exactly backwards. The programs that move fastest overall are the ones that spend real time up front tracing what talks to what, because every dependency discovered mid-migration costs far more time to resolve reactively than it would have taken to map in advance.

The second most common slowdown is ownership ambiguity. Migrations touch systems that were built by teams who have since moved on, been reorganized, or simply stopped being the de facto owner without anyone updating the documentation. When something breaks during cutover, the first hour is often spent just figuring out who can actually make a decision about it — time that a clear ownership map, built during planning, would have eliminated entirely.

The third, and most avoidable, is treating rollback as an afterthought. A rollback plan written after something has already gone wrong is not a plan, it's improvisation under pressure. Every wave in a well-run migration has a rollback path defined and, ideally, tested before cutover — not because failure is expected, but because the cost of having a plan and not needing it is trivial compared to the cost of needing one and not having it.

None of this requires exotic tooling. It requires discipline: map dependencies before scheduling waves, assign explicit ownership before touching a system, and write the rollback plan before you need it, not during the incident.