Cloud Migration Template

Why migrations stall halfway

A cloud migration is not a single task, and treating it like one ("move everything to the cloud" as a card title) is the most common reason these projects stall around the halfway mark. The easy services move first, momentum looks good for a month, and then the project runs into the handful of services nobody fully understood the dependencies of, and stalls there for much longer than the first half took.

The inventory is incomplete, so migration finds surprises mid-way. A service nobody remembered depends on the old file server, and it's discovered only when that server is scheduled for shutdown, usually by whoever's application just broke.

Too many services migrate at once. Without a limit on active migrations, half a dozen services are mid-move simultaneously, none of them fully verified, and a failure in one is hard to isolate from the others when three teams are all mid-change at the same time.

Old infrastructure never gets decommissioned. Everything moves to the cloud, but nobody turns off the old servers because nobody's sure it's safe yet, so the organization ends up paying for both, indefinitely, with the old bill quietly becoming permanent.

Cutover and migration get treated as the same step. A service is "migrated" once it exists in the cloud, but traffic hasn't actually moved to it yet, and that gap between "exists" and "live" is where a lot of migrations quietly stall without anyone noticing the difference.

How to use it

1. 01Build the full inventory before migrating anything, including things that seem obviously unimportant. The dependency nobody remembered is usually one of those, and interviewing each team about what their service actually talks to catches more than a network scan alone.
2. 02Cap the migrating column at two or three services, even if the team is larger. Isolating failures matters more than migrating fast.
3. 03Migrate low-dependency services first. Order the inventory by how many other things depend on each item, and start at the bottom.
4. 04Treat cutover as its own event with its own checklist, not as the last step of migration. DNS, credentials, and monitoring all need separate verification.
5. 05Hold decommission for a fixed period after cutover, written on the card, rather than deciding case by case whether it feels safe yet.
6. 06Record the dependency map on the wiki as you build the inventory, not as a one-time diagram that goes stale. It's more useful as a living page than a snapshot from week one.

The pace is set by the migrating column's limit, not by how many services are in the inventory. A hundred-service inventory with a three-service limit will take a while. That's the honest schedule, not a sign the limit is too conservative.

Delivery forecasts become useful once a batch of low-dependency services has moved end to end, because the time each one actually took is a better predictor of the remaining timeline than the original estimate ever was. Teams tend to trust the forecast more once they've seen it self-correct after the first surprise dependency. High-dependency services near the end will still take longer than the average. That's expected, not a sign the plan is failing.