There is a version of the cloud conversation that every enterprise IT leader is tired of having. It starts with pressure from above, "we need to be cloud-first", and ends with a lift-and-shift migration that costs more than expected, delivers less than promised, and leaves the organization running its old workloads on someone else's hardware.
Cloud migration is not a strategy. It is an execution challenge. And treating it like a strategy is why so many cloud programs disappoint.
The question nobody asks before the roadmap
Before a cloud migration begins, someone needs to answer a specific question: what does better look like, and how will we know when we've gotten there?
The answer isn't "we'll be in the cloud." That's a location, not an outcome. The outcomes worth pursuing are things like: we'll reduce infrastructure maintenance cost by a measurable percentage; we'll improve deployment frequency from quarterly to weekly; we'll eliminate a specific category of availability risk we've experienced repeatedly. Those outcomes are worth migrating for. "Being cloud-first" is not.
The reason this question gets skipped is that it's uncomfortable. It requires admitting that the organization doesn't have full clarity on why it's spending several million dollars and twelve to eighteen months on a program. It also requires committing to a definition of success that can later be used to evaluate whether the investment worked.
Organizations that skip this step tend to end up in the same place: migrated, technically, with a cloud bill that surprises everyone, and a post-migration roadmap full of the optimization work that should have been part of the original program.
The lift-and-shift trap
Lift-and-shift migrations, moving workloads from on-premises to cloud VMs with minimal rearchitecting, are fast, low-risk, and usually the wrong answer.
They're fast because they require the least change. They're low-risk for the same reason. And they're usually the wrong answer because they reproduce the on-premises architecture in the cloud without capturing any of the value that justifies the cost of migration.
A cloud VM running an application that was designed for on-premises infrastructure doesn't gain the scalability benefits of cloud architecture. It doesn't automatically become more resilient. It doesn't reduce operational overhead in the ways that the cloud promises, because those benefits come from rearchitecting, from taking advantage of managed services, autoscaling, infrastructure-as-code, and the operational model changes that come with them.
Lift-and-shift has a legitimate use case: when the goal is datacenter exit by a hard date, and rearchitecting isn't feasible in the available time. In that scenario, lift-and-shift is a bridge, not a destination. The organizations that treat it as a destination end up paying cloud prices for on-premises architecture.
What cloud migration actually requires
A cloud migration that delivers on its business case usually requires three things that don't get enough attention in the initial planning:
An application portfolio assessment that drives sequencing. Not all workloads should go to the cloud in the same way. Some are good candidates for rehosting. Some should be replaced by SaaS alternatives. Some should be retired. Some need rearchitecting before they can run well in a cloud environment. A migration that doesn't do this assessment first will eventually do it under pressure, mid-program, when it's harder.
A target operating model. What does the organization look like when the migration is complete? Who manages cloud infrastructure? Who owns cost governance? What tools are used for observability? How are provisioning decisions made? These questions don't have to be answered before the first workload migrates, but they need to be answered before the last one. Organizations that don't answer them discover their cloud costs are growing in ways nobody understands, and the team responsible for on-premises infrastructure is being asked to also manage a cloud environment they were never trained for.
A realistic cost model. Cloud economics are counterintuitive to organizations used to on-premises infrastructure. Compute costs are variable. Storage costs are ongoing. Egress charges add up in ways that on-premises architectures don't have. Getting to a cloud spend that is actually lower than on-premises infrastructure requires active cost management, tagging, right-sizing, reserved instance planning, not just migration.
The programs that work
Cloud migrations that deliver real business value tend to have one thing in common: they were designed backward from specific outcomes, not forward from a technical roadmap.
The outcome might be "reduce our infrastructure ops headcount by eliminating server maintenance." It might be "go from a six-week deployment cycle to a daily one." It might be "eliminate the class of availability incidents we had in 2023." Those outcomes drive architectural decisions in ways that "migrate to AWS" doesn't.
The technical work is substantial and important. But it's in service of something, and the organizations that are clear on what that something is before they start are the ones whose cloud programs we'd be comfortable putting in a case study.
