Stop Refactoring Everything: The Case for Rehosting First

You've been told that cloud migration means modernizing everything. That's wrong. If you refactor every application as you move it, you'll burn through your budget and your team's patience before you see a single benefit. The smarter play is to rehost first, then optimize what actually matters. I'm going to defend that position with hard numbers, and then I'll address the one argument that might make you reconsider.

The 6 Rs aren't a menu — they're a sequence

The 6 Rs framework (Rehost, Replatform, Refactor, Repurchase, Retire, Retain) is widely used, but too many teams treat it as a multiple-choice test where the "best" answer is always refactor. In reality, these strategies form a sequence. You start with the fastest, least risky moves to get workloads into the cloud, then you optimize selectively. Rehosting, or lift-and-shift, moves applications as-is without code changes. It's the quickest and simplest method, and it doesn't fully leverage cloud-native features (DigitalOcean). That's fine. Your first goal is to exit the data center, not to win an architecture beauty contest.

What the data actually says about how teams migrate

Red Hat's survey found that replatforming was the most common approach at 20%, with other strategies ranging between 10% and 19%. More tellingly, 38% of organizations plan to rehost, then replatform, then refactor, while 47% plan to skip rehosting and go straight to replatforming (Red Hat). That second group is onto something: they're not trying to refactor everything at once. They're making small changes — like switching to a managed database — without redesigning the whole application.

And if you think refactoring is the norm, consider this: retire applied to just 10% of applications, and only 13% of respondents intended to repurchase applications (Red Hat). Most organizations aren't rewriting from scratch. They're moving what they have and improving incrementally.

Why refactoring first is a budget killer

Flexera's 2025 State of the Cloud report found that 84% of organizations say managing cloud spend is their top challenge (Flexera 2025). If you refactor everything, you're not just paying for cloud infrastructure — you're paying for months of engineering time before you see any operational savings. Meanwhile, 33% of organizations already spend more than $12 million annually on public cloud, and budgets exceeded limits by 17% (Flexera 2025). Refactoring first makes those overruns worse.

Contrast that with a rehost-first approach. AWS's rehosting service, Transform MGN, automates conversion of source servers into native Amazon EC2 instances with minimal downtime. You can move large numbers of machines from physical, virtual, or other cloud platforms without long cutover windows (AWS Transform MGN). That speed means you start saving on data center costs sooner, and you can then refactor only the workloads that justify the effort.

The counter-argument: you'll just pay more later

The strongest objection is that rehosted applications aren't cloud-native and are harder to scale, leading to higher long-term costs (DigitalOcean). Red Hat agrees: rehosting without modification can lead to higher long-term costs from running applications in the cloud without cloud-native capabilities (Red Hat). That's a real risk. But it's a risk you can manage. You don't have to leave everything rehosted forever. You can rehost, measure, and then replatform or refactor the 20% of applications that drive 80% of your costs or performance bottlenecks. The alternative — refactoring everything upfront — guarantees you'll spend that engineering time and money before you even know which apps need it.

And don't forget the retire option. AWS defines zombie applications as those with average CPU and memory usage below 5% and idle applications as those with 5–20% usage over 90 days (AWS Prescriptive Guidance). If you rehost first, you get real usage data in the cloud. That data often reveals that you can retire a chunk of your portfolio entirely. You can't get that insight as easily when you're still on-premises.

How to do rehost-first without creating a mess

Start with a proper assessment. The Azure migration framework's Assess stage involves creating a full inventory and dependency map of servers, services, and apps, and estimating cost savings using the Azure TCO Calculator (Microsoft Learn). Do that before you move anything. Then group workloads into migration waves based on shared dependencies (Microsoft CAF). Rehost the waves that are low-risk and high-value first. For the applications that are tightly coupled to on-premises hardware or have compliance constraints, retain them for now — AWS lists data residency compliance and mainframe systems as valid retain use cases (AWS Prescriptive Guidance).

Once you're in the cloud, use the data you collect to decide what to replatform. Examples include moving SQL Server to Amazon RDS or porting .NET Framework apps to .NET Core on Linux (AWS Prescriptive Guidance). These are incremental changes that don't require a full rewrite. And if you do decide to refactor, do it for a specific business reason — not because someone told you it's the "right" way.

The one thing to remember

Migration is not a single event. It's a process of moving, measuring, and improving. The 47% of organizations that skip rehosting and go straight to replatforming are on the right track, but even they shouldn't rule out a quick rehost for workloads that are stable and low-risk. Your goal is to get out of the data center, then optimize based on evidence — not ideology. Rehost first, refactor later, and let the data tell you where to invest your engineering hours.

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
• Flexera 2025 - https://www.flexera.com/about-us/press-center/new-flexera-report-finds-84-percent-of-organizations-struggle-to-manage-cloud-spend
• AWS Prescriptive Guidance - https://docs.aws.amazon.com/prescriptive-guidance/latest/large-migration-guide/migration-strategies.html
• AWS Transform MGN - https://aws.amazon.com/application-migration-service/
• Microsoft Learn - https://learn.microsoft.com/en-us/training/modules/design-migrations/3-describe-azure-migration-framework