The Missing Owner: Why Cloud Migrations Fail

McKinsey surveyed roughly 450 CIOs and IT decision makers and put a number on what migration veterans already suspected: $100 billion in wasted spend and up to $500 billion in eroded shareholder value tied to cloud programs that ran past their budgets. The headline gets quoted a lot. The more useful finding sits underneath it: the projects that overran rarely lacked engineers, tooling, or a target date. What they lacked was a single person who had signed for the whole move.

Cloud migrations don't die because the cutover script is wrong. They die in the space between the workload owners, the platform team, the security group, the finance partner, and the executive who approved the budget but never carried the pager. When nobody owns the move end to end, every hard decision gets punted to whoever inherits the mess after cutover.

The Problem Shows Up Everywhere Except the Org Chart

Walk into a stalled migration and the symptoms look technical. A lift-and-shift that ballooned the bill. An identity model that half the applications inherited and half rebuilt.

A dependency nobody mapped until the app went dark. A FinOps dashboard that lights up two weeks after the workload has already been running hot.

Teams pressure-testing their own plan against a checklist of cloud migration pitfalls will recognize most of these symptoms. None of them are the underlying problem. They're what happens when a program runs on five part-time leaders instead of one full-time one.

Architecture picks the target pattern. Security signs off on the guardrails. Finance builds the business case. Application teams keep the lights on.

The executive sponsor approves the funding and shows up at the steering committee. Every function does its piece, and nobody signs for the outcome. That's why cost overruns and identity issues end up grouped together in post-mortems even though they look unrelated: both are decisions that had no clear owner at the moment they needed to be made.

Why the Obvious Fix Doesn't Work

The instinct is to name an executive sponsor and move on. Most programs already have one. The title is on the charter. The name is on the slide.

Sponsorship on paper and sponsorship in the room are different jobs. Guidance from CBTW on migration change management draws the line bluntly: executive approval means signing the budget and reading the monthly deck, while executive sponsorship means showing up at kickoff, showing up at key milestones, and being willing to enforce the hard calls, including decommissioning the old environment on the date it was supposed to go dark.

The other reflex is to stand up a steering committee. Committees are useful for surfacing conflict and terrible at resolving it. When the platform team wants to refactor before moving, the workload owner wants to lift-and-shift to hit a date, and security wants both to wait for a new identity baseline, a committee will document the disagreement and schedule another meeting.

What a Real Owner Actually Signs For

The pattern that works looks closer to what AWS calls single-threaded leadership: one technical leader, dedicated to the program, accountable for the outcome, paired with a visible executive sponsor who backs their calls. That means one person on the org chart whose calendar reflects the program and whose promotion depends on it, rather than a matrixed lead juggling three other jobs or a PMO coordinator tracking status without any authority to move things.

The scope of what that person signs for is broader than most charters describe. Here's a useful list to hand a candidate before they accept the role:

• The target architecture. Which workloads are rehosted, which are refactored, and which are retired before they ever move.
• The identity model. How humans, service accounts, and workloads authenticate on day one, not after cutover.
• The cost envelope. A monthly run-rate target for each wave, with a named approver for anything that exceeds it.
• The decommissioning calendar. The date each source system goes dark. Without an owner willing to enforce it, the old environment runs in parallel for a year and the business case evaporates.
• The rollback criteria. What has to be true to call a cutover successful, and what triggers a reversal. Decided before the weekend, not during it.

What to Do Before the Next Wave

If a migration is already underway and the symptoms above sound familiar, the fix isn't another tool or another consultant, but a short and uncomfortable conversation about who owns what.

1. Name the leader. One person, dedicated, with the authority to make architecture, identity, and cost calls without escalating each one.
2. Redefine the sponsor's role in writing. Weekly presence, decommissioning authority, and a standing seat in the operating review. If the current sponsor can't commit to that, find one who can.
3. Kill the committee as a decision body. Keep it for visibility and conflict surfacing. Move decisions to the named leader.
4. Freeze new waves until the identity model is signed. Every workload that moves without a decided identity pattern becomes a rework ticket later.
5. Publish the decommissioning calendar. Dates, owners, and the consequence of a miss. The business case lives or dies here.

None of this is glamorous work. It's also the difference between a migration that lands on budget and one that shows up in next year's repatriation numbers. The cloud isn't the hard part. The signature is.