Stop Rehosting Everything: The Cost-Cutting Case for Replatforming First

Here's a contrarian take that might ruffle some feathers: if your cloud migration plan starts with rehosting everything, you're already losing the cost battle. I know, I know—lift-and-shift is the safe, fast, boring choice. But boring is expensive. The data is clear: rehosting is the most common strategy, yet it's the one that leaves the most money on the table. In this piece, I'll argue that replatforming—not rehosting—should be your default migration move, and I'll back it up with numbers and a clear-eyed look at the trade-offs.

The Rehosting Reflex Is a Cost Trap

Let's start with the uncomfortable truth: 47% of organizations plan to skip rehosting and go straight to replatforming, according to a Red Hat survey. That's nearly half of your peers already avoiding the lift-and-shift path. Why? Because rehosting—moving apps as-is to the cloud—is the fastest and simplest method, but it doesn't fully leverage cloud-native features (DigitalOcean). That's a polite way of saying you're paying for a data center in the sky, not a cloud.

Think about it: you move a legacy app to a virtual machine in the cloud, and you still have to manage the OS, patch it, and scale it manually. You're not getting the elasticity, the managed services, or the pay-per-use granularity that makes cloud cheaper. In fact, 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 not a coincidence. Rehosting at scale without optimization is a one-way ticket to budget overruns.

Replatforming: The Sweet Spot of Effort and Savings

Replatforming—'lift, tinker, and shift'—makes minor optimizations during migration, like switching to a cloud-managed database, without changing core architecture (DigitalOcean). It's not as sexy as refactoring into microservices, but it's a fraction of the effort and still captures significant cost benefits.

Here's a concrete example: AWS suggests moving Microsoft SQL Server to Amazon RDS for SQL Server as a replatforming move (AWS Prescriptive Guidance). That single change offloads database administration, gives you automated backups, and lets you scale compute independently of storage. You're not rewriting code; you're just choosing a managed service. The cost savings come from reduced operational overhead and better resource utilization.

And the numbers back this up: replatforming was the most common migration approach at 20% in Red Hat's survey, with other strategies ranging between 10% and 19% (Red Hat). It's already popular, but it should be even more so. The 7 Rs framework from AWS includes replatform as one of the common strategies for large migrations, alongside rehost, relocate, and retire—but notably, refactor is not recommended for large migrations because it's too complex (AWS Prescriptive Guidance). So replatform is the cost-effective middle ground that gives you cloud benefits without the refactoring headache.

The Counter-Argument: Speed and Risk

But wait, you might say, rehosting is faster and less risky. No code changes, no tinkering, just move and go. That's true—rehosting does offer speed and lower initial risk because no code changes are required (DigitalOcean). For a quick win, it's tempting. But that speed comes at a hidden cost: rehosted applications are not cloud-native and are harder to scale (DigitalOcean). You're locking in a future of manual scaling and over-provisioning, which is exactly what drives cloud waste.

In fact, AWS's own guidance for large migrations says that rehost, replatform, relocate, and retire are common, but refactor is not recommended because it's the most complex strategy to manage across many applications (AWS Prescriptive Guidance). That's a tacit admission that rehosting alone doesn't optimize costs—it just gets you there fast. And what happens after you're there? You have to go back and fix the mess, which costs more in the long run.

Optimize from Day One: The FinOps Imperative

If you're not thinking about FinOps from the start, you're already behind. Flexera's 2026 data shows that 63% of organizations have a dedicated FinOps team, and 71% have a Cloud Center of Excellence (Flexera 2026). These teams exist to control cloud spend, but they can't fix a migration that was designed to ignore them.

Here's the thing: replatforming sets you up for FinOps success because it forces you to make conscious choices about which managed services to use, and that opens the door to right-sizing and cost tracking. Azure Migrate, for example, provides assessments that cover Azure readiness, right-sizing of VM sizes, and cost estimation—all before you move (Azure Migrate). If you rehost, you skip that analysis and end up with oversized VMs and idle resources. If you replatform, you're already in the mindset of optimizing.

And the payoff is real: AWS cites a case study where a customer consolidated 80 SAP systems and achieved 30% cost savings with a cloud-native transformation (AWS). That's not a rehosting story; that's a replatforming and refactoring story. The savings come from the transformation, not the move.

My Recommendation: Replatform First, Rehost Only When Necessary

So here's my advice, and I'm not shy about it: for the majority of your applications, make replatforming your default. Rehost only when you have a truly time-sensitive deadline or an app that's already cloud-ready. And don't even think about refactoring everything—that's a recipe for paralysis.

Start by assessing your portfolio with tools like Azure Migrate, which can identify workloads and estimate TCO of on-premises versus Azure (Azure Migrate). Then, for each app, ask: can I switch to a managed database? Can I move to a container? Can I use a cloud-native service for a minor component? If yes, replatform. If not, rehost—but plan to optimize later.

And here's a practical number to guide you: Flexera 2025 found that 87% of organizations say cost efficiency/savings is the number one metric for assessing cloud goals (Flexera 2025). If that's your metric, then rehosting is a failure out of the gate. Replatforming is the only strategy that balances effort, speed, and cost optimization.

Let me address the strongest counter-argument one more time: 'But we have 500 apps and no time to replatform each one.' Fair point. But you don't have to replatform all of them. 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—those are candidates for retirement, not migration (AWS Prescriptive Guidance). Kill the zombies first, replatform the valuable ones, and rehost only the stragglers. That's a cost-first migration playbook.

Bottom line

Don't lift and shift by default. Replatform first, retire the zombies, and rehost only when you must. That's the single best move you can make for cloud cost optimization.

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/
• Azure Migrate - https://learn.microsoft.com/en-us/azure/migrate/migrate-services-overview