Rehost vs. Replatform vs. Refactor: Which Cloud Migration Strategy Wins?

Imagine you're a CTO staring at a spreadsheet of 200 aging applications, each with cryptic dependencies and a business owner who insists theirs is 'mission-critical.' Your board has given you a mandate: move to the cloud within a year. The pressure is on, and the last thing you need is a migration that drags on for years or blows the budget. This is the reality for most organizations today, and the choices you make now will echo for a decade.

I've been in this seat more times than I care to count, and I've seen the full spectrum of migration strategies—from the slapdash lift-and-shift to the over-engineered re-architecture that never ships. After years of watching teams flounder, I have a strong opinion: the 'right' strategy isn't a single answer, but a portfolio. Still, if you're looking for a starting point, replatforming is the unsung hero that most teams should default to. Here's why.

The Contenders: Rehost, Replatform, Refactor

Let's set the stage. The industry's migration playbook—the 'Rs'—has been around since Gartner coined the 5 Rs back in 2010, and it's evolved into the 6 Rs (Rehost, Replatform, Refactor, Repurchase, Retire, Retain) and even a 7 Rs variant that adds Relocate (DigitalOcean, Red Hat). For this comparison, I'm focusing on the three that matter most for application workloads: rehost, replatform, and refactor.

Rehost is the classic 'lift and shift.' You pick up your virtual machine and plop it into the cloud, code untouched. It's fast and simple, but you're not getting cloud-native benefits—your app won't magically scale or become more resilient (DigitalOcean). AWS notes that rehosting can move large numbers of machines from physical, virtual, or other clouds without long cutover windows (AWS Prescriptive Guidance).

Replatform is 'lift, tinker, and shift.' You make small, targeted changes—like swapping your on-premises MySQL for a cloud-managed database—without re-architecting the app (DigitalOcean). AWS gives concrete examples: moving SQL Server to Amazon RDS, porting .NET Framework to .NET Core on Linux, or migrating VMs into containers via App2Container (AWS Prescriptive Guidance).

Refactor is the full re-architecture. You're breaking that monolith into microservices or going serverless. It's the most complex and costly strategy, and AWS explicitly warns against it for large-scale migrations because it modernizes during the move, which is a nightmare to manage across many apps (AWS Prescriptive Guidance, DigitalOcean).

Assessing Your Portfolio: The Reality Check

Before you pick a strategy, you need to know what you're dealing with. The assessment phase is non-negotiable. Microsoft's Azure migration framework starts with Assess, where you create a full inventory and dependency map, and estimate cost savings using the Azure TCO Calculator (Microsoft Learn). AWS's three-phase approach—assess, mobilize, migrate—is designed to get you moving in weeks (AWS Prescriptive Guidance). IBM's workflow also begins with assess and plan (IBM).

But here's where teams stumble: they under-assess. DigitalOcean lists common pitfalls like missed dependencies and budget overruns (DigitalOcean). I've seen a 'simple' rehost turn into a fire drill because no one mapped the network connections between servers—Azure Migrate's dependency analysis exists precisely to avoid that (Azure Migrate).

So, how do you triage? Look at your portfolio through the lens of the 7 Rs. AWS defines 'zombie applications' (CPU and memory below 5%) and 'idle applications' (5-20% usage over 90 days) as candidates for retirement (AWS Prescriptive Guidance). That's your first win: decommission the dead weight before you move anything. For the rest, your default should be replatform, not rehost.

Why Replatform Beats Rehost (Most of the Time)

Let's look at the numbers. In Red Hat's survey, replatforming was the most common approach at 20%, but 38% of organizations plan to rehost first, then replatform, then refactor (Red Hat). That's a mistake. Rehosting is quicker and cheaper upfront, but it's a trap: Red Hat warns that rehosting without modification can lead to higher long-term costs because you're running in the cloud without cloud-native capabilities (Red Hat). You're paying for the cloud's premium without getting the benefits.

Replatforming, on the other hand, gives you a taste of cloud-native without the full rewrite. You can move your database to a managed service, which handles backups, patching, and scaling—saving your team hours of toil. AWS's examples are practical: moving to RDS or Graviton processors is a small change with big returns (AWS Prescriptive Guidance).

But there's a nuance. If your app is a stable, legacy system that's not going to change, rehost might be fine. I've seen teams rehost a CRM that's on its last legs, and it worked because they were planning to repurchase (move to SaaS) soon anyway (DigitalOcean). The key is intentionality.

When to Refactor (and When to Run Away)

Refactoring is sexy. Who doesn't want to break that monolith into microservices? But it's also the most complex and costly strategy (AWS Prescriptive Guidance). AWS doesn't recommend it for large migrations because it's too risky to modernize while moving (AWS Prescriptive Guidance). Red Hat notes that microservices are easier to build, test, deploy, and update, but they require a cultural shift and new skills (Red Hat).

Refactor only when the business value is undeniable. If you have a legacy app that's holding you back—say, it can't scale to handle peak loads, or you're paying licensing fees that are bleeding you dry—then yes, re-architect. But do it as a separate initiative, not as part of the mass migration. And if you're going to refactor, consider containers and Kubernetes. Kubernetes is the standard for container orchestration, and it's self-healing—it restarts failed containers and doesn't advertise them until they're ready (Kubernetes). That's powerful, but it's not a PaaS; you'll need to build your own platform on top (Kubernetes).

The Verdict: Match the Strategy to the Workload

So, which wins? It depends, but here's my rule of thumb: rehost for the quick wins and the soon-to-be-retired, replatform for the majority, and refactor only for the strategic few. In a typical portfolio, you might have 20% that are candidates for retire, 20% that are fine to rehost, 50% that should replatform, and 10% that genuinely need a refactor. That's not a scientific formula, but it's a starting point.

Let me ground this in a scenario. Suppose you have 100 apps. You assess and find 20 are zombies (AWS's definition). You retire those immediately—that's a 20% reduction in your migration scope. Of the remaining 80, 30 are simple, stable apps that are perfect for rehost. You can move them quickly using AWS's Application Migration Service, which automates the conversion to EC2 with minimal downtime (AWS). The other 50 are more complex, with dependencies and performance issues. For those, you replatform: move the database to RDS, maybe containerize a few. That's the sweet spot. The remaining 10, you refactor, but only the ones with clear business value—maybe a customer-facing app that needs to scale for a global rollout.

This portfolio approach is backed by industry trends. Flexera's 2025 report found that 84% of organizations struggle to manage cloud spend, and wasted spend on IaaS/PaaS rose to 29% in 2026 (Flexera 2025, Flexera 2026). If you rehost everything, you're likely to see your costs balloon. Replatforming helps you take advantage of managed services that can reduce operational overhead, and it sets you up for better cost management.

One more thing: don't forget the shared responsibility model. Whether you rehost or replatform, you're responsible for your data, access management, and compliance (Microsoft Learn, AWS). Security is not something you can outsource. And as you migrate, keep an eye on data transfer costs—Microsoft's CAF lists four data migration paths, from ExpressRoute (private, secure) to the public internet (least secure) (Microsoft CAF). Choose wisely.

In the end, the best strategy is the one that gets you to the cloud with the least risk and the most value. Replatforming is the balanced choice for most modern teams. It's not as fast as rehost, but it's not as risky as refactor. It's the pragmatic middle path that lets you modernize incrementally while keeping the lights on.

The Single Most Important Thing to Remember

Don't treat migration as a binary choice—it's a portfolio. Assess each workload, retire what's dead, rehost what's simple, replatform the majority, and refactor only when it pays off. Start with replatforming as your default, and you'll avoid the cost and complexity traps that plague so many migrations.

Sources

• DigitalOcean - https://www.digitalocean.com/resources/articles/cloud-migration-strategy
• AWS Prescriptive Guidance - https://docs.aws.amazon.com/prescriptive-guidance/latest/large-migration-guide/migration-strategies.html
• Red Hat - https://www.redhat.com/en/blog/how-should-you-modernize-your-applications
• Microsoft Learn - https://learn.microsoft.com/en-us/training/modules/design-migrations/3-describe-azure-migration-framework
• Flexera 2025 - https://www.flexera.com/about-us/press-center/new-flexera-report-finds-84-percent-of-organizations-struggle-to-manage-cloud-spend
• Flexera 2026 - https://www.flexera.com/blog/finops/the-new-era-of-cloud-what-2026-data-tells-us-about-spend-scale-and-strategy/