Stop Rehosting Everything: Why Replatforming Is the Unsung Hero of Cloud Migration

Imagine you're the IT director at a mid-size manufacturer. You've been told to 'move to the cloud' by year-end. Your team is stretched, the CFO is watching costs, and the CEO expects a digital transformation story for the board. The default playbook says: lift and shift. Rehost everything, get it over with, and call it a migration. But I've seen this script too many times, and it's a trap. Rehosting is not a strategy; it's a procrastination tactic. The real work—and the real payoff—comes from replatforming.

Here's my thesis, and I'll defend it with the data: Replatforming is the most underrated migration strategy, and most organizations should lead with it, not rehosting. In a Red Hat survey, replatforming was the most common approach at 20%, with other strategies ranging between 10% and 19% (Red Hat). But that's still barely a fifth of applications. Meanwhile, 47% of organizations plan to skip rehosting entirely and go straight to replatforming (Red Hat). That's the smart crowd. The rest? They're about to spend millions to recreate their data center in the cloud—and wonder why their bills are higher.

The Lure of Lift-and-Shift

Rehosting is seductive because it's fast and low-risk in the short term. You move applications as-is, change no code, and get to the cloud in weeks (DigitalOcean). AWS even has a dedicated service, AWS Transform MGN (formerly Application Migration Service), that automates the conversion of source servers into native EC2 instances with continuous block-level replication and orchestrated cutover (AWS Prescriptive Guidance). That's powerful. But rehosted applications are not cloud-native. They don't scale automatically, they don't benefit from managed services, and you're still patching operating systems and managing servers—just now in someone else's building.

The Hidden Costs of Rehosting

Here's the kicker: rehosting without modification can lead to higher long-term costs because you're running applications in the cloud without cloud-native capabilities (Red Hat). You're paying for elasticity you never use. And the waste is staggering. Flexera's 2025 State of the Cloud report found that 84% of organizations struggle to manage cloud spend (Flexera 2025). That's not a coincidence. When you lift and shift a server that was sized for peak on-premises load, you're paying for idle capacity. AWS even defines 'zombie applications' as those with average CPU and memory usage below 5% over 90 days (AWS Prescriptive Guidance). How many of those are you about to rehost?

Replatforming: The Sweet Spot

Replatforming—or 'lift, tinker, and shift'—makes minor optimizations during migration without changing core architecture (DigitalOcean). You might move a Microsoft SQL Server to Amazon RDS for SQL Server, or port a .NET Framework app to .NET Core on Linux (AWS Prescriptive Guidance). These are small changes with outsized benefits. You get managed services, automatic backups, patching, and scaling—without a full rewrite. It's not as sexy as refactoring into microservices, but it's pragmatic. And the data backs it up: 38% of organizations plan to rehost, then replatform, then refactor (Red Hat). That's a sensible sequence, but why waste the first step?

Refactoring: The Overhyped Endgame

Now, the counter-argument: 'Why not just refactor everything? That's where the real cloud value is.' True, refactoring—re-architecting to use microservices, serverless, or containers—delivers the most benefit (DigitalOcean). But it's also the most complex and costly strategy (AWS Prescriptive Guidance). AWS explicitly recommends against refactoring for large migrations because it's the hardest to manage across many applications (AWS Prescriptive Guidance). And for compliance reasons, you might need to split a database so some tables stay on premises (AWS Prescriptive Guidance). That's a massive undertaking. Most organizations don't have the appetite or the talent for that scale of change.

The Case for Replatform-First

Look at the real-world results. AWS cites a customer that consolidated 80 SAP systems and achieved 30% cost savings with a cloud-native transformation (AWS). That's refactoring, but it's also a huge, multi-year program. For most of us, replatforming is the pragmatic middle path. It gives you some cloud benefits without the risk. In Red Hat's survey, retire applied to just 10% of applications (Red Hat). So you can't just delete your way out. You have to move most of them.

Here's a concrete scenario: your company runs a legacy Java application on a Windows server. A pure rehost would put that on EC2, and you'd still manage the OS, the Java runtime, and the application yourself. A replatform would move it to AWS Elastic Beanstalk or Azure App Service, which handles the platform for you. The change is minimal—maybe a few configuration tweaks—but you've eliminated a whole class of maintenance. That's the kind of win that compounds.

Yes, But What About Speed?

I can hear the objections: 'But rehosting is faster!' True, but not by as much as you'd think. AWS says its three-phase approach—assess, mobilize, migrate—lets you migrate the first set of applications in weeks (AWS Prescriptive Guidance). That's not a multi-year slog. And with replatforming, you're not rewriting code; you're making targeted changes. The extra time is measured in days, not months. Meanwhile, you're avoiding the long-term cost trap.

Quick tip: Before you commit to a strategy for each application, run a dependency analysis. DigitalOcean warns that under-assessing the application portfolio leads to missed dependencies (DigitalOcean). Azure Migrate can help with that, using a lightweight appliance to continuously send configuration and performance data (Azure Migrate). Don't skip this step.

The Bottom Line

Don't get me wrong—rehosting has its place. For some applications, especially those slated for retirement soon, it's fine. But making it the default is a mistake. Replatforming gives you the best return on effort for most workloads. It's not as flashy as refactoring, but it's the workhorse that will actually move your portfolio forward without blowing up your budget or your team.

The single most important thing to remember: Replatforming, not rehosting, should be your default migration strategy. It's the sweet spot between speed and modernization, and it's the one that will keep you from joining the 84% who struggle with cloud spend (Flexera 2025).

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
• AWS Prescriptive Guidance (phases) - https://docs.aws.amazon.com/prescriptive-guidance/latest/strategy-migration/introduction.html
• Flexera 2025 - https://www.flexera.com/about-us/press-center/new-flexera-report-finds-84-percent-of-organizations-struggle-to-manage-cloud-spend
• Azure Migrate - https://learn.microsoft.com/en-us/azure/migrate/migrate-services-overview