Your Cloud Migration Is a Case Study: Pick Replatform First

You've heard it a thousand times: the fastest way to the cloud is lift-and-shift. It's wrong. Rehosting gets you to the cloud, sure, but it also drags along every inefficiency of your on-premises data center. In a Red Hat survey, only 20% of organizations chose replatform as their primary strategy, while 38% planned to rehost first, then replatform, then refactor. That's the herd. The smarter play? Skip the rehost step entirely and go straight to replatform. Here's why, and how to do it in a way that doesn't blow up your budget.

The Case for Replatforming First

Replatform, or 'lift, tinker, and shift,' is the sweet spot between speed and sanity. You make minor optimizations during migration—like swapping a self-managed database for a cloud-managed one—without rearchitecting the core of your application. AWS gives concrete examples: moving Microsoft SQL Server to Amazon RDS, switching to AWS Graviton processors, or porting a .NET Framework app to .NET Core on Linux. These are small changes with outsized impact. Rehost, by contrast, is fast and simple, but it doesn't fully leverage cloud-native features, and it makes scaling harder down the line.

So why do so many teams default to rehost? Because it feels safe. No code changes, no rework, just a copy-paste job. But that safety is an illusion. You're paying for a cloud that behaves exactly like your old data center, minus the hardware headaches. You've gained nothing except a new bill.

The 6 Rs: Your Decision Framework

Before you touch a single server, you need to run every workload through the 6 Rs: Rehost, Replatform, Refactor, Repurchase, Retire, and Retain (DigitalOcean). Most teams skip the last two, and that's a mistake. Retire is your chance to kill 'zombie applications'—AWS defines these as apps with average CPU and memory usage below 5% over 90 days, or no inbound connections in the same period. Those are dead weight, and you should decommission them before you migrate anything. Retain is for workloads that genuinely can't move yet—data residency rules, mainframe systems like IBM AS/400, or apps with unresolved dependencies (AWS).

For everything else, resist the urge to rehost. Replatform should be your default. It gives you tangible benefits—managed databases, better performance, lower operational overhead—without the full cost and complexity of a refactor. Refactor, which AWS calls the most complex and costly strategy, is best reserved for a few high-value apps where you're willing to break a monolith into microservices. And repurchase, like moving from a self-hosted CRM to Salesforce, is a business decision more than a technical one.

Assess Before You Migrate: The Real Work

The reason most migrations fail is not the migration itself—it's the assessment. You can't replatform what you don't understand. Microsoft Learn's Azure migration framework starts with an Assess stage: create a full inventory and dependency map of servers, services, and apps, and estimate cost savings with the Azure TCO Calculator. That's the foundation. Skip it, and you'll miss dependencies that cause outages and budget overruns.

Azure Migrate is a free service that does the heavy lifting for you. You deploy a lightweight appliance in your data center that continuously sends configuration and performance data to Azure. It then produces assessments covering readiness, right-sizing, cost estimation, and dependency analysis. The business case feature compares your on-premises TCO against Azure, year over year, showing the shift from CapEx to OpEx. That's the kind of data you need to convince your CFO that replatforming is worth the effort.

Migrate, Optimize, and Monitor: Don't Stop at Go-Live

Once you've assessed, you migrate. But the Azure framework doesn't stop there—it has four stages: Assess, Migrate, Optimize, and Monitor (Microsoft Learn). Optimize is where you actually save money. Right-size your instances, shut down idle ones, and use managed services to reduce operational overhead. Monitor is where you catch problems before they become costly.

Here's a concrete scenario. Imagine you're a mid-size company with 200 VMs running a mix of custom .NET apps and a SQL Server database. If you rehost everything, you'll end up with 200 virtual machines in Azure, each with its own license and management overhead. Instead, you replatform: move the SQL Server to Azure SQL Database (a managed service), port the .NET apps to .NET Core on Linux and run them on Azure App Service, and right-size the remaining VMs. You'll cut your VM count by half, eliminate patching chores, and reduce your bill by 20-30%—numbers that match what AWS customers see when they do this (AWS).

But don't take my word for it. 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 after five years of decline. That's a direct result of rehosting without optimizing. You can avoid that by building FinOps practices from day one—Flexera shows that 63% of organizations now have a dedicated FinOps team, and those that do are better at measuring value delivered to business units (64%).

Quick tip: Before you migrate anything, turn on the AWS or Azure Cost Calculator and model both a rehost and replatform approach. The difference in monthly burn will shock you.

What I'd Actually Do

Here's my blunt recommendation: for any migration of more than a handful of servers, do a discovery pass with a tool like Azure Migrate or AWS Migration Hub. Classify every workload using the 6 Rs. Retire the zombies. Retain anything with a hard compliance reason not to move. For the rest, replatform first. Only rehost when there's a technical blocker—like a legacy OS that won't run on Linux—and even then, plan to refactor it within a year.

Skip the rehost-everything phase entirely. The Red Hat survey shows that 47% of organizations already plan to skip rehost and go straight to replatform. Join them. It's not the fastest path to the cloud, but it's the fastest path to a cloud that actually pays off.

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