What Actually Kills Cloud Migrations (And What People Blame Instead)

The post-mortem everyone writes, and the one nobody does

When a cloud migration goes badly, there’s a familiar set of villains. The bill came in too high. Lift-and-shift was the wrong call. The vendor over-promised. The consultancy left and nothing worked. The team didn’t have enough Kubernetes experience.

I’ve been called in on the back end of a lot of these, and the post-mortems are almost always written about the symptoms rather than what actually caused the failure. Every one of those things may be true on the day the project is declared a disaster. None of them are why it went wrong.

The thing that kills migrations is almost always the same, and it’s almost never technical: nobody ever owned the new operating model, and nobody ever decided what “migrated” actually meant. Everything else is downstream of that.

This is the same failure mode I’ve written about for platform builds, scope and ownership decided long before code, and quietly ignored. Migrations make it worse because there’s a working system on one side and a half-built one on the other, and the cost of indecision compounds for every month they both exist.

What “migrated” should mean (and almost never does)

Ask three people on a migration project what “done” looks like and you’ll get three answers. The CIO thinks done is when the data centre contract is signed off. The platform team thinks done is when workloads run in the new environment. Finance thinks done is when the old bills stop arriving. The application owners think done is whatever lets them stop firefighting.

These are not the same definition. They imply completely different scopes of work, and if you don’t reconcile them at the start, you’ll discover the gap two-thirds of the way through, when somebody finally asks why the old VMware cluster is still racking up support fees nine months after “go live.”

A useful definition of done for a migration has four parts, and all of them have to be agreed up front:

1. What workloads are in scope, and what is explicitly out. Not “the application.” Which databases, which jobs, which integrations, which scheduled tasks, which forgotten EC2 instance running a script nobody can identify.
2. Who operates them after migration, with what runbook, on what oncall rota. If this is the same team that was firefighting before, you have not migrated, you have moved the fire.
3. What gets decommissioned, by whom, and by when. If the old environment isn’t being torn down on a calendar, the migration isn’t finished, it’s just paying for two homes.
4. What the new cost envelope is, and who owns it. Not the cloud bill in aggregate; the bill per team, per workload, per environment, with someone whose job it is to keep it from drifting.

If those four things aren’t written down and signed by the people whose budget they touch, the migration is going to fail. It might still ship, but it’ll ship into the same operational fog the old environment was in, and the team will spend the next year explaining why the bill keeps growing.

The three patterns I see most often

Pattern one: the migration that never finished. Workloads got moved. Some of them. The hard ones, the legacy database, the integration with the on-prem ERP, the one application written in 2009 by a contractor who left in 2014, never got tackled, because they were going to be “Phase 2.” Phase 2 never starts. Two years later, you’re paying for both environments, the team that knew the old systems has left, and the business case for the migration has quietly evaporated.

The fix is unglamorous: decommissioning has to be on the same project plan as migration. A workload isn’t migrated until the old one is off. If a workload can’t be migrated, that has to be an explicit, dated decision, not a default.

Pattern two: lift-and-shift with no managed-service follow-through. Teams are told to lift-and-shift to keep risk low, which is sensible for week one. Then nobody comes back. The application is now running on rented EC2 with the same architecture it had on-prem, and the only thing that’s changed is the bill. The promise of cloud, managed services, elasticity, paying for what you use, never gets cashed in.

I’ve argued before that lift-and-shift is fine as a step, but it’s never the destination. The migration plan has to include the next migration: when this workload moves from VMs to managed Postgres, from cron to a managed scheduler, from self-rolled queues to SQS or PubSub. If that next step isn’t dated, the lift-and-shift is the whole project, and you’ve paid cloud prices for data-centre architecture.

Pattern three: the operating model never arrived. The platform got migrated. The team didn’t change. The on-prem playbook, quarterly change windows, ticket-based provisioning, a single shared environment because “envs are expensive”, got carried wholesale into a cloud account where every assumption that justified it is now wrong. Engineers spend the next year fighting the same ticketing system with prettier hostnames.

This is the failure that hurts most, because it produces the impression that “the cloud doesn’t actually deliver.” It does. It just doesn’t deliver to teams running the same operating model that made the on-prem environment painful.

What people blame instead

Almost every public post-mortem I’ve read points at one of four scapegoats, and almost every one of them is the symptom, not the cause:

• “The cloud bill was too high.” Usually true. Usually because nobody owned the bill, there was no FinOps function, no per-team chargeback, no quotas, no killswitches on idle resources. The cost wasn’t a cloud problem; it was a missing operating-model problem rendered in dollars.
• “Lift-and-shift was the wrong strategy.” Usually it was the right strategy for week one and the wrong strategy for month twelve, because nobody scheduled the re-architecture work.
• “The vendor over-promised.” Usually the vendor sold the platform; the customer expected the platform and the operating model and the cultural change. Those aren’t in the contract.
• “The consultancy left and nothing worked.” Usually because the consultancy built the new environment and the internal team was never trained to run it. This is fixable if the engagement is structured for handover; almost no engagements are.

Each of those is a real, fixable thing. None of them are the deep cause. The deep cause is always the same: the project shipped a platform without shipping a way of working.

What “good” looks like

The healthy migrations I’ve been part of all share the same boring traits, and very few of them are technical:

• A named owner for the new operating model, separate from the project manager running the migration plan
• A definition of done with decommissioning baked in, with dates, on the same Gantt chart as the migration tasks
• A FinOps function that exists from day one, not added at month nine when the bill becomes embarrassing
• Customer-facing teams in the room every week looking at real, partially-migrated workloads, the same continuous-feedback loop I’ve described for platform builds
• An honest timeline. Migrations take longer than the slide deck says. I’ve written about why estimates feel slow, migrations are a worse version of that, because you’re paying double-rent the whole way through

None of that requires expensive tooling. All of it requires that someone with authority decides what the migration is for, and stays in the room until it’s done.

So what should you actually do?

If you’re about to start a migration, the most valuable hour you can spend isn’t with the architecture team. It’s with finance, with the application owners, and with whoever runs the team on the other side of the cutover, agreeing in writing what “done” means, and putting decommissioning, ownership, and the new operating model on the same plan as the workload moves.

If you’re in the middle of a migration that feels stuck, the most useful question to ask isn’t “which workload do we move next?” It’s: “what does the old environment look like the day after we finish, and who turns it off?” If nobody can answer cleanly, that’s where the project is broken, regardless of how many workloads have been moved.

If you’ve finished a migration and the bill keeps growing or the team keeps firefighting, the work isn’t over. The platform shipped. The operating model didn’t. That’s where the next phase of investment has to go, even though it’ll feel like cleanup work rather than progress.

Cloud migrations don’t fail because the cloud is bad, or the vendor is bad, or the consultancy is bad. They fail because someone agreed to move workloads without agreeing what shape the company looked like on the other side. That’s the conversation worth having before you start, and the only one worth having if you’re already stuck.

If you’re navigating one of these and want a second pair of eyes, our cloud solutions and legacy modernisation work is built around the kinds of operating-model gaps this post is about.