Don't Refactor Everything: Why Rehosting Still Wins the Cloud Migration Race

The Question We Should Be Asking

Imagine you're a cloud architect at a mid-sized company. The CIO has just announced a "cloud-first" mandate, and you're staring at a portfolio of 200 applications, most of them legacy monoliths. Your inbox is full of vendor pitches: "Refactor to microservices!" "Go serverless!" "Embrace Kubernetes!" But you've seen too many projects die in the refactoring swamp. The real question isn't "What's the most modern strategy?"—it's "What's the most effective strategy for our specific situation?" And the answer, more often than not, is rehosting. We've been in this field long enough to see the pattern: teams that start with rehosting get to the cloud faster, learn faster, and eventually modernize more successfully than those who try to boil the ocean with refactoring.

The Rehosting Renaissance

Let's be blunt: rehosting—or lift-and-shift—has a bad reputation. It's seen as the lazy man's migration, the path that leaves you with "cloud-native" apps that are just VMs in someone else's data center. But the data tells a different story. In a Red Hat survey, replatforming was the most common approach at 20%, but rehosting was a close second, and 38% of organizations plan to rehost first, then replatform, then refactor. More tellingly, 47% plan to skip rehosting entirely and go straight to replatforming—a risky move that adds complexity before you've even learned to walk in the cloud.

Why the hesitation? Because rehosting is fast and simple. AWS Prescriptive Guidance notes that rehosting moves applications without changes, and you can migrate large numbers of machines from physical, virtual, or other cloud platforms without long cutover windows. AWS even has a dedicated service, AWS Transform MGN (formerly Application Migration Service), that automates the conversion of source servers into native EC2 instances using continuous block-level replication, so you can migrate with minimal downtime. That's not theory; that's a tool built for exactly this purpose.

The counterargument is that rehosted apps are harder to scale and don't leverage cloud-native features. That's true—DigitalOcean points out that rehosted applications are not cloud-native and are harder to scale. But here's the thing: most applications don't need to scale to Netflix levels. They need to run reliably, cost-effectively, and be manageable. And rehosting gets you there in weeks, not years.

Why Refactoring Is a Trap (for Most)

Refactoring—re-architecting to use microservices, serverless, or containers—is the siren song of cloud migration. AWS calls it the most complex and costly migration strategy, and for good reason. It involves breaking monoliths into microservices, which is a huge undertaking. Red Hat describes microservices as an architecture where applications are broken into their smallest independent components, which sounds elegant but is incredibly difficult in practice. The Cloud Native Computing Foundation (CNCF) defines cloud-native as loosely coupled systems that are secure, resilient, and observable—a noble goal, but one that requires a cultural shift, not just a technical one.

Here's the kicker: AWS specifically recommends against refactoring for large migrations. In their prescriptive guidance, they say that for large migrations, rehost, replatform, relocate, and retire are common strategies, but refactor is not recommended because it modernizes during the migration, which is the most complex to manage across many applications. Yet teams still insist on refactoring everything because it's more "strategic." That's a mistake. You wouldn't rebuild your entire factory while moving to a new location; you'd move the equipment first, then optimize production lines.

Consider the compliance angle: AWS notes that refactoring might mean splitting a database so some tables stay on-premises for compliance reasons. That's not a technical problem; it's an organizational nightmare. And the survey data backs this up: retire applied to just 10% of applications in Red Hat's survey, and 13% planned to repurchase (move to SaaS). So, for the other 77%—the ones that need to move—rehosting is the pragmatic path.

The Pragmatic Middle: Replatforming and Retiring

Now, we're not saying you should rehost everything forever. The sweet spot is a mix: rehost what's stable and mission-critical, replatform what needs a minor boost, and retire the zombies. AWS defines zombie applications as those with average CPU and memory usage below 5% over 90 days, and idle applications as those with 5-20% usage. Those are prime candidates for retirement. Don't pay to move dead weight.

Replatforming—what DigitalOcean calls "lift, tinker, and shift"—is the middle ground. You make minor optimizations, like switching to a cloud-managed database, without changing the core architecture. AWS gives examples like moving SQL Server to Amazon RDS for SQL Server, or porting .NET Framework apps to .NET Core on Linux. That's smart: you get some cloud-native benefits without a rewrite. And the data suggests replatforming is already popular: it was the most common approach in Red Hat's survey at 20%.

But here's the thing: rehosting first doesn't preclude replatforming later. In fact, it accelerates it. Once you're in the cloud, you can see which apps are actually used and which are zombies. You can measure performance and cost with real data, not guesses. Then you can decide what to replatform, what to refactor, and what to retire. As Red Hat notes, rehosting without modification can lead to higher long-term costs, but that's a risk you can mitigate by planning your modernization roadmap after migration, not before.

Making the Call: A Recommendation

So, what's the practical takeaway? Start with an assessment. Microsoft Learn's Azure migration framework has four stages: Assess, Migrate, Optimize, and Monitor. In the Assess stage, you create a full inventory and dependency map, and estimate cost savings using the Azure TCO Calculator. That's where you identify your rehost, replatform, and retire candidates. Don't skip this step—under-assessing the portfolio is a common pitfall, as DigitalOcean warns.

Then, choose your default: rehost. For the vast majority of workloads, rehosting is the fastest, simplest, and lowest-risk path to the cloud. It gets you to the cloud in weeks, not years, and gives you a solid foundation to optimize from. AWS's three-phase approach—assess, mobilize, and migrate—is designed to get your first set of applications to the cloud in weeks, and that's only possible if you're not refactoring everything.

Finally, don't forget the people. Flexera's 2026 data shows that 63% of organizations have a dedicated FinOps team and 71% have a Cloud Center of Excellence (CCOE). That's not just about cost; it's about governance. You need a team that can manage the hybrid estate that 73% of organizations now operate. And as Flexera's 2025 report found, 84% struggle to manage cloud spend—so you need a plan for optimization from day one, not after the bill arrives.

In the end, the best migration strategy is the one that gets you to the cloud with minimal risk and maximum learning. Rehosting is that strategy. Refactoring is a destination, not a starting point. Start with rehost, learn the landscape, and then modernize with purpose. That's how you win the cloud migration race.

Sources

• DigitalOcean - https://www.digitalocean.com/resources/articles/cloud-migration-strategy
• Red Hat - https://www.redhat.com/en/blog/how-should-you-modernize-your-applications
• AWS Prescriptive Guidance - https://docs.aws.amazon.com/prescriptive-guidance/latest/large-migration-guide/migration-strategies.html
• 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