I’ve been leading cloud migrations for most of my career. Multi-cloud, multi-team, multi-country programs. Platforms that couldn’t go down for even ten minutes. Timelines that weren’t negotiable.
The technical challenges were rarely what threatened delivery.
What Actually Threatens a Migration
Let me be specific about what I’ve seen derail programs:
- A team that hasn’t bought in to the migration and is passively not prioritizing their service
- An InfoSec stakeholder who wasn’t involved early and is now blocking the cutover at week 10
- Two teams who share a database but haven’t agreed on the cutover sequence
- An executive sponsor who stops attending steering meetings because “it’s a technical program”
- An application team that discovers mid-migration that their service has an undocumented external dependency
None of these are technical problems. They’re organizational ones.
The Org Chart Is Your Architecture Diagram
Conway’s Law says that organizations design systems that mirror their communication structures. For migrations, the inverse is also true: your migration plan will fail if it doesn’t account for your org chart.
The first thing I do on any migration engagement isn’t a technical assessment. It’s mapping the human dependencies:
- Who owns each service?
- Who has to approve a cutover?
- Whose work depends on whose?
- Who are the skeptics, and what are their actual concerns?
- Who are the informal leaders — the engineers other engineers listen to?
This map is as important as the dependency diagram between services.
Stakeholder Management Is Technical Work
There’s a tendency in platform engineering to treat stakeholder management as a soft skill — something that happens alongside the real work. That’s wrong.
On the InMobi migration, I was running weekly executive updates alongside daily technical standups. Not because I was asked to, but because an engaged executive sponsor is a prerequisite for a migration of that scale to succeed. A sponsor who doesn’t know what’s happening can’t unblock the things that only they can unblock.
On the Koo migration, the hardest conversation wasn’t about database replication strategy. It was convincing an application team that their four-year-old service needed to be partially refactored before it could be safely migrated — and that two weeks of their engineering time now would prevent an outage during cutover.
These conversations require trust, which requires consistent communication, which requires treating stakeholder management as a deliberate, ongoing activity.
The Alignment Tax
Programs that skip stakeholder alignment early pay an alignment tax later — usually at the worst possible time.
I’ve seen it look like this: everything is going well technically, you’re three weeks from cutover, and then an InfoSec team you didn’t loop in early raises compliance concerns that require architectural changes. You now have a choice between delaying the delivery date or accepting risk that wasn’t properly evaluated.
Neither option is good. Both were preventable.
The alignment tax is real, and it compounds. The later you pay it, the more expensive it gets.
What This Means Practically
If you’re leading a cloud migration:
Start with a stakeholder map, not a technical assessment. You need to know who needs to be bought in before you know how much work you’re doing.
Define ownership explicitly. Every service, every database, every external dependency needs a named owner. “The platform team” is not an owner. A named individual is.
Make InfoSec a partner from week one. Not a reviewer at the end. Every major migration has security implications. The earlier they’re involved, the less disruptive their requirements become.
Treat communication cadence as delivery infrastructure. Weekly executive updates, daily team standups, documented risk registers, explicit escalation paths. This isn’t overhead — it’s what keeps the program moving when things get hard.
The technical work on a cloud migration is genuinely difficult. But in my experience, the migrations that fail technically, fail because something organizational went wrong first.