Why Rehosting Is the Wrong First Move for Cloud Cost Optimization

Everyone says the fastest way to the cloud is to lift and shift. They're wrong. Not about the speed—rehosting is indeed the quickest migration path, but that's precisely the problem. It's a cost trap that will haunt your budget long after the migration fireworks fade. I've seen it happen too many times: teams celebrate a successful rehost, only to watch their cloud bill balloon because they didn't change anything about the application. The cloud isn't a cheaper data center; it's a different operating model. And if you treat it as a simple relocation, you're leaving money on the table—or rather, setting it on fire.

The question I want to answer is this: Should you rehost as your default migration strategy when your goal is cost optimization? My answer is a resounding no. Rehosting has its place, but it should be the exception, not the rule. For most applications, you're better off replatforming or refactoring—even if it takes longer. Here's why.

The Rehosting Illusion: Fast, But Expensive

Rehosting, or lift-and-shift, moves applications to the cloud as-is, with no code changes (DigitalOcean). It's fast, simple, and low-risk initially. But the cloud's elasticity works against you when your app isn't designed for it. A rehosted app still runs like it's on-premises: it expects fixed resources, doesn't scale down automatically, and often runs 24/7 even when no one's using it. That's a recipe for wasted spend.

And the numbers back me up. Flexera's 2025 State of the Cloud report found that 84% of organizations struggle to manage cloud spend, and wasted spend on IaaS and PaaS rose to 29% in 2026—the first increase in five years (Flexera 2026). That's nearly a third of your cloud budget evaporating. Rehosting contributes directly to that waste because it doesn't optimize anything. You're paying for the same capacity you had on-premises, but now at cloud rates, with no efficiency gains.

The justification for rehosting is usually speed. You can migrate thousands of servers quickly, and AWS's rehosting service, Application Migration Service, automates the conversion of source servers to EC2 instances with minimal downtime (AWS Transform MGN). That's great for a tactical move, but it's not a cost strategy. As Red Hat points out, rehosting without modification can lead to higher long-term costs because you're running applications in the cloud without cloud-native capabilities (Red Hat).

So, when should you rehost? Only when you have a clear exit plan—like a temporary migration to decommission a data center quickly, or when an app is slated for replacement soon. But don't make it your default. The cloud is not a colocation facility.

The Smarter Path: Replatforming First

If you want to optimize costs, replatforming is your best friend. Replatforming, or 'lift, tinker, and shift,' makes minor optimizations during migration—like switching to a cloud-managed database—without changing the core architecture (DigitalOcean). It's not as fast as rehosting, but it's not as slow as refactoring, and it delivers meaningful savings.

Red Hat's survey shows that replatforming is the most common migration approach, at 20% (Red Hat). Why? Because it's the sweet spot between speed and optimization. For example, instead of moving your SQL Server to a VM, you move to Amazon RDS for SQL Server, which handles backups, patching, and scaling automatically (AWS Prescriptive Guidance). That's a small change that cuts your administrative overhead and allows you to scale down when demand is low.

And here's a key insight: many organizations are already skipping rehosting. Red Hat found that 47% of organizations plan to skip rehosting and go straight to replatforming (Red Hat). That's a smart move. Why waste time on a step you'll have to redo? Replatforming is the first step toward cloud-native efficiency without the full commitment of refactoring.

But don't stop there. Replatforming is a stepping stone. Once you've replatformed, you can gradually refactor specific components that are cost drivers. The goal is to get your applications to a state where they can leverage auto-scaling, serverless, and other cloud-native features that actually reduce spend.

Refactoring: The Real Cost Killer

Refactoring, or re-architecting, is the most complex and costly migration strategy, but it delivers the most benefit (DigitalOcean). It means breaking a monolithic application into microservices, using containers, or going serverless. Yes, it's a big investment, but the payback is enormous.

Consider this: a rehosted application runs 24/7, but a refactored application using serverless only runs when there's an event. Red Hat defines serverless as an event-driven execution model metered on demand, where an idle function costs nothing (Red Hat). That's a direct cost reduction. Similarly, containers and Kubernetes allow you to pack workloads densely, so you use fewer resources. Kubernetes is self-healing and can automatically restart containers that fail, which means you don't need to over-provision for resilience (Kubernetes).

AWS warns that refactoring is not recommended for large-scale migrations because it modernizes during the migration, which is complex to manage across many applications (AWS Prescriptive Guidance). But that doesn't mean you should avoid it. It means you should be selective. Pick the applications that are your biggest cost centers or that will benefit most from elasticity. For those, refactoring is worth the effort.

And don't forget the 'retire' strategy. 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). These are prime candidates for retirement. In my experience, most organizations have a surprising number of these. Retiring them is the cheapest migration of all—you save money without moving anything.

The Cost of Not Optimizing: A Concrete Example

Let me make this tangible. Suppose you have a web application that runs on 10 virtual machines on-premises, each with 8 vCPUs and 16 GB of RAM. You rehost it to the cloud as-is. You're now paying for 10 EC2 instances, each running 24/7. Even with reserved instances, that's a significant monthly bill.

Now, if you replatformed it to use a managed database and set up auto-scaling, you might only need 4 instances during peak hours and drop to 1 during off-peak. That's a potential 60-70% reduction in compute costs. And if you refactored it into microservices with serverless functions for certain tasks, you could eliminate idle capacity entirely.

Flexera reports that 87% of organizations say cost efficiency/savings is the number one metric for assessing cloud goals, and 64% measure value delivered to business units (Flexera 2025, Flexera 2026). That's the right mindset. But to actually achieve cost savings, you need to move beyond rehosting.

Of course, there are legitimate reasons to retain applications on-premises, like data residency compliance or technical constraints (AWS Prescriptive Guidance). And for those, you shouldn't force a migration. But for the rest, the cloud is an opportunity to optimize, not just a place to park your workloads.

My Recommendation: Skip Rehosting, Embrace Replatforming

So, here's my advice, plain and simple: when planning a cloud migration for cost optimization, do not start with rehosting. Instead, assess your portfolio and identify quick wins for retirement, then replatform the majority of your applications. Reserve refactoring for your most critical or costly apps. And if you're tempted to rehost, ask yourself: 'What's the exit plan?' If you don't have one, you're just creating a future migration project.

Remember, the cloud is not a destination; it's a way of operating. The sooner you treat it that way, the sooner you'll see the savings.

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
• 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/
• AWS Transform MGN - https://aws.amazon.com/application-migration-service/