Cloud Migration Case Studies: The Wins Come From Retiring Apps, Not Lifting Them

Three weeks from cutover. Your inventory: 400 workloads. Dependency map: 900 connections. Vendor deck: lift and shift is fast, simple, low risk. So you move all 400 as-is, high-five, and then spend two years paying for servers nobody uses and apps nobody can scale.

That failure mode is so common it's almost a rite of passage. But the cloud migration case studies worth copying? They're the ones that retired and replatformed aggressively. Not the ones that rehosted everything. Rehosting is a transport decision. Not a transformation.

Rehost is a moving truck, not a strategy

Rehosting, or lift and shift, moves applications as-is with no code changes. Fastest, simplest path. Doesn't use cloud-native features (DigitalOcean). That trade-off is real, and sometimes correct. AWS rehosting lets you migrate large numbers of machines from physical, virtual, or other cloud sources without long cutover windows or long-distance replication (AWS Prescriptive Guidance). If you're exiting a data center on a deadline, that matters.

But speed is not the goal. The goal is a lower cost base and a system you can actually operate. Red Hat's application migration guidance is blunt: rehosting without modification can raise long-term costs because you run the same application in the cloud without cloud-native capabilities (Red Hat). You moved the problem. You did not fix it.

Here's the trap in numbers. In a Red Hat survey, replatforming was the most common approach at 20%, with other strategies landing between 10% and 19%. Meanwhile, 38% of organizations planned to rehost, then replatform, then refactor, while 47% planned to skip rehosting entirely and go straight to replatforming (Red Hat). Nearly half the market already knows the truck is not the destination.

Delete first, migrate second

The most underrated case study move is subtraction. AWS defines zombie applications as those averaging below 5% CPU and memory use, and idle applications as 5-20% use over 90 days; both, plus anything with no inbound connection in 90 days, are retire candidates (AWS Prescriptive Guidance).

Do the math on your own fleet. If 15% of your 400 workloads are zombies, that's 60 applications you can shut off before the first byte moves. No migration wave. No cutover window. No runbook. Just a decommission. In Red Hat's survey, retire applied to only 10% of applications, which tells me most teams are leaving that free win on the table.

And the payoff is not theoretical. An AWS case study describes a customer that consolidated 80 SAP systems and cut costs 30% through cloud-native transformation, while another exited 17 data centers in 30 months using generative and agentic AI (AWS). Neither of those is a lift-and-shift story.

The counter-argument: rehosting is correct when the clock is the constraint

The strongest pushback is timing. If your data center lease ends in 12 months, refactoring 400 apps is fantasy. AWS itself recommends rehost, replatform, relocate, and retire as the common strategies for large migrations, and explicitly does not recommend refactor at that scale because modernizing during migration is the most complex strategy to manage across many applications (AWS Prescriptive Guidance).

Fair. I accept that. Rehost the long tail. But qualify it hard: rehosting is a first wave, not a final state. AWS's own three-phase approach is assess, mobilize, then migrate, which sets up a foundation and moves the first applications in weeks (AWS Prescriptive Guidance (phases)). The phrase "first set" is doing a lot of work there. If your case study ends at the first wave, you have a moving story, not a migration story.

What the money says about where to focus

Cost is the reason this debate matters. In Flexera's 2025 State of the Cloud report, 84% of respondents named managing cloud spend their top challenge, and cloud budgets overran by 17% (Flexera 2025). That's what happens when you rehost 400 workloads and inherit 400 cost profiles with no optimization.

The counterweight: 87% said cost efficiency is the number one metric for assessing cloud goals, the sixth straight year and a 22-point jump from 2024 (Flexera 2025). Teams are measuring this. They're just measuring it too late.

Where does selective replatforming fit? AWS lists concrete examples: SQL Server to Amazon RDS, Graviton processors, .NET Framework to .NET Core on Linux, and VMs into containers with App2Container (AWS Prescriptive Guidance). Those are tinkers, not rebuilds. They're the highest-return hours you'll spend in the whole program.

• Retire: kill zombies and idle apps before any wave planning.
• Replatform: managed databases, newer runtimes, containers for the apps that matter.
• Rehost: the long tail, on a deadline, with a documented second pass.

Quick tip: run your utilization report before your migration wave plan. AWS's thresholds are simple and unforgiving: under 5% average use over 90 days is a retire candidate, and so is anything with no inbound connection in that window (AWS Prescriptive Guidance).

What I'd actually do

Run a 90-day utilization and connection report across the whole estate. Anything under 5% average CPU and memory, or silent for 90 days, goes to the retire pile with an owner's sign-off. That's your free 10-15%.

Then group what's left into waves by shared databases, APIs, authentication, and network dependencies, and plan for split-environment operation for anything that legally cannot move (Microsoft CAF). For each wave, pick one replatform target: managed database, newer runtime, or containers. Rehost the rest, but write down the date you will revisit it. A case study that ends with "and then we optimized" is the only kind worth reading.

Sources

• DigitalOcean - https://www.digitalocean.com/resources/articles/cloud-migration-strategy
• Red Hat - https://www.redhat.com/en/topics/cloud-native-apps/application-migration
• AWS Prescriptive Guidance - https://docs.aws.amazon.com/prescriptive-guidance/latest/large-migration-guide/migration-strategies.html
• Flexera 2025 - https://www.flexera.com/about-us/press-center/new-flexera-report-finds-84-percent-of-organizations-struggle-to-manage-cloud-spend
• AWS - https://aws.amazon.com/cloud-migration/
• Microsoft CAF - https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/get-started/migrate