Case Studies Show Replatforming Beats Lift-and-Shift for Cloud Migration

Should we just lift and shift everything to the cloud?

It's the question every engineering leader asks when staring down a migration backlog. The answer, based on real-world case studies and survey data, is a firm no. Replatforming—not rehosting—is the sweet spot for most workloads. In fact, Red Hat's survey found replatforming was the most common migration approach at 20%, while rehosting landed between 10% and 19% (Red Hat). That's not an accident. Teams that skip straight to rehosting often end up with higher long-term costs and scaling headaches, as Red Hat warns: rehosting without modification can lead to higher costs because you're running in the cloud without cloud-native capabilities (Red Hat).

The case for replatforming: speed with a tinker

Replatforming, or 'lift, tinker, and shift,' means making minor optimizations during migration—like switching to a cloud-managed database—without changing your core architecture (DigitalOcean). It's the pragmatic middle ground. AWS gives concrete examples: moving Microsoft SQL Server to Amazon RDS, using AWS Graviton processors, porting .NET Framework apps to .NET Core on Linux, or migrating VMs into containers with AWS App2Container (AWS Prescriptive Guidance). These are small, high-value tweaks that don't require a full rewrite.

Consider a real scenario: a company with 50 on-premises VMs running a legacy .NET app. Rehosting would move them as-is to EC2, but replatforming to .NET Core on Linux and using a managed database could cut licensing costs and improve performance. That's the kind of move that shows up in case studies as a 30% cost savings, like the AWS customer who consolidated 80 SAP systems (AWS).

Why not just rehost? The hidden costs of lift-and-shift

Lift-and-shift is tempting because it's fast and low-risk—no code changes needed (DigitalOcean). But here's the catch: rehosted applications are not cloud-native and are harder to scale (DigitalOcean). Red Hat's application migration guidance is blunt: rehosting is quicker and lowers initial migration costs, but without modification, you'll pay more in the long run because you're not using cloud-native features (Red Hat). Flexera's 2025 report found 84% of organizations struggle to manage cloud spend (Flexera 2025). A big reason is that rushed rehosting leaves you with oversized, always-on resources that you're paying for but not fully using.

The counter-argument: sometimes you must rehost

Sure, there are times when rehosting is the only option. Maybe you need to migrate thousands of machines quickly, and AWS notes that rehost can handle large numbers without long cutover windows (AWS Prescriptive Guidance). Or you have a zombie application—one with CPU and memory usage below 5% (AWS Prescriptive Guidance)—that you're not ready to retire. In those cases, rehosting buys you time. But the data suggests you should use that time to replatform later. Red Hat's survey found 38% of organizations plan to rehost, then replatform, then refactor, while 47% plan to skip rehosting and go straight to replatforming (Red Hat). That's a clear signal: the smartest teams are avoiding the rehost-then-replatform loop.

How to decide: use the 6 Rs, but bias toward replatform

The 6 Rs framework—Rehost, Replatform, Refactor, Repurchase, Retire, Retain (DigitalOcean)—is your decision tree. But don't treat it as a menu. Start with replatform as the default, and only drop to rehost if you have a hard constraint. Here's a quick heuristic:

• If the app is a candidate for retirement, retire it—AWS suggests looking for zombies with