Your Cloud Migration Stalled. It's Probably Not a Tech Problem.
I sat in a room last year with a cloud programme that had been "80 percent complete" for eleven months.
Eleven months. Same percentage. Same slide.
The infrastructure team knew it. The vendor knew it. I knew it. The only people who didn't seem to know it were the exec team, who were still getting quarterly updates saying the migration was on track.
It wasn't on track. It was stationary. And the reason had nothing to do with Azure, AWS, or any piece of technology in the stack.
The Pattern
I've seen this enough times that I can describe the shape of it before anyone tells me the specifics.
The migration starts with genuine momentum. A business case gets approved. A vendor gets engaged. A roadmap gets built. The first few workloads move cleanly. Everyone breathes a sigh of relief — the tech actually works.
Then something shifts.
The second wave of workloads is messier. Legacy applications that weren't documented properly. Integrations nobody knew existed until they tried to move the system they connected to. A compliance requirement that surfaced four months too late. A key person who left.
Decisions start getting deferred. Dependencies pile up. Progress slows to a trickle. The programme keeps reporting "in flight" because nobody wants to be the one who calls it stuck.
And the technology? It's sitting there, working exactly as advertised, waiting for someone to actually use it.
What's Actually Happening
The technology is rarely the problem. In twenty years of watching these programmes, I can count on one hand the times a cloud migration genuinely stalled because the platform couldn't do what was asked of it.
What I can't count is how many times it stalled because of the following:
Nobody actually owned it. A cloud migration that lives in IT but needs buy-in from finance, operations, legal, and HR is not a cloud migration. It's a very expensive negotiation. When the project hits a real decision — "do we re-platform this application or lift-and-shift it?" — and there's no one with the authority to make that call and make it stick, the programme just waits. Sometimes for months.
The business never actually bought in. IT convinced itself that once the infrastructure was ready, the business would follow. The business had other priorities. Nobody on the programme had a mandate to compel business units to commit resources, make decisions, or accept disruption. The migration became optional for everyone except the team running it.
The scope was wrong from day one. The vendor scoped a lift-and-shift. The organisation needed a transformation. Lift-and-shift is faster and cheaper to sell. It is not faster or cheaper once you're six months in and discovering that the applications you moved to the cloud are now running at three times the cost because they were never designed for cloud billing models. Scope resets are painful. Most organisations avoid having them until they absolutely must.
The skills on the roadmap weren't in the room. Someone wrote "cloud-native modernisation" into the plan. Nobody checked if the internal team actually had those skills, or if they were fully committed to the programme rather than splitting time between the migration and keeping the lights on in the existing environment. When capacity crunches hit, the migration loses. Every time.
The vendor delivered what they sold, not what you needed. This one is harder to say out loud in front of a supplier. But a vendor who wins on a lift-and-shift scope is financially incentivised to keep it a lift-and-shift. The person who should be escalating the scope conversation is often the same person whose renewal depends on the existing contract staying comfortable.
The Conversation Nobody Has
Here's what I find interesting about stalled cloud migrations: the information is almost always available.
The engineers know. They've known for months what's blocked, what decisions are outstanding, what capabilities are missing. They're just not the ones presenting to the steering committee, and the steering committee isn't asking the right questions.
The questions the steering committee is usually asking: Are we on schedule? Are we on budget? Is the vendor performing?
The questions that would actually surface the real situation: What decisions are currently blocked, and who is supposed to make them? What workloads have been descoped since the project started, and why? If the programme ended today, what percentage of your target environment is actually running in production?
That last question is the one that matters. Not "are we 80 percent complete." But "if we stopped tomorrow, what's actually in production and working?"
The gap between those two answers is your stall.
What Good Looks Like
The cloud migrations I've seen work — and I have seen them work — share a few things that have nothing to do with which hyperscaler you chose.
A named executive who owns outcomes, not just progress. Not the CTO. Someone whose performance is tied to the business outcomes the migration was supposed to deliver, who has the authority to make cross-functional decisions and who will not let the programme drift into comfortable quarterly slide decks.
A clear migration philosophy agreed before the first workload moves. Lift-and-shift for commodity infrastructure. Re-platform for core business systems. Re-architect for anything that's a genuine competitive advantage. That framework needs to exist before the vendor starts scoping, not six months after you've already lifted and shifted something that's now billing your CFO into a mood.
Dedicated capacity on both sides. Cloud migrations that compete with BAU for internal resource do not complete on time. They complete on whatever timeline the competing demand allows, which is usually late. If you can't dedicate the team, move the start date until you can. Starting underresourced and hoping it resolves itself is how you get eleven months at 80 percent.
Honest scope reviews every quarter. Not status updates. Reviews. What changed? What needs to change? What decisions have been deferred and what's the cost of deferring them further? The review that says "we need to reset the scope" is painful. It is less painful than the alternative.
The right mix of internal knowledge and external capability. Your internal team knows the organisation, the politics, the history of why systems work the way they do. External specialists know the platform, the failure modes, the gotchas that cost other organisations six months. You need both. One without the other either moves too slowly or makes expensive mistakes that an insider would have avoided.
What You Can Do This Week
If you're reading this and your cloud programme is stalled, the first thing to do is stop running status meetings and run a decision register instead.
List every decision that is currently outstanding, blocking progress on the programme. Name the decision. Name who is supposed to make it. Record how long it's been outstanding.
If the list is longer than five items and the average age is more than three weeks, your governance is broken. Not your technology. Your governance.
Fix that first. The technology will still be there when you're ready.
And if you've been at 80 percent complete for more than two months, ask someone external — someone with no stake in the existing contract — to give you their honest read on what that actually means. Sometimes you just need someone who isn't living inside the slide deck to tell you what everyone else already knows.
A Note on Sunken Cost
One more thing.
There is always a conversation, somewhere in a stalled migration, about how much has already been spent. This conversation is used as an argument for continuing — "we've invested too much to stop now."
Sunk cost isn't a strategy. The question isn't what you've spent. It's whether continuing the current approach will deliver value you couldn't get another way.
Sometimes the honest answer is: descope, deliver what's working, and treat the rest as a second programme with a clean scope and proper ownership. That's not failure. That's course correction.
The organisations that do it early come out ahead. The ones that don't spend another eighteen months at 80 percent before someone finally calls it.
If your migration is stalled and you want a straight read on why, I'm happy to talk. Not to sell you something. Just to say what I see.
That's usually the most useful conversation.