We Tried Lift-and-Shift. It Flopped. Here's What Actually Worked.

The Rehost Trap

Everyone tells you to lift and shift. It's fast, simple, and low-risk, according to the common wisdom. But that's exactly the problem. Rehosting moves your applications to the cloud as-is, without code changes, and you end up with a virtual data center in the sky. You pay cloud premiums for infrastructure that still behaves like your old servers. The real win in cloud migration comes from making targeted changes during the move—not after.

Imagine you're a migration lead at a mid-sized company. Your portfolio has 200 applications. The executive team wants speed and cost savings. The default instinct is to rehost everything. But data from Red Hat shows that replatforming is the most common successful migration approach, used for 20% of applications. That's not a niche tactic; it's the mainstream sweet spot.

Why Replatform Beats Rehost

Replatforming, or 'lift, tinker, and shift,' makes minor optimizations without changing the core architecture. A classic example: moving Microsoft SQL Server to a cloud-managed database like Amazon RDS for SQL Server. You don't rewrite the app; you just swap the database layer. The result? You offload administrative overhead and gain scalability.

Rehosting is faster and has lower initial risk because no code changes are required, but rehosted applications are not cloud-native and are harder to scale. In contrast, replatforming gives you some cloud-native benefits without the cost and complexity of a full refactor. It's the pragmatic middle path.

The 7 Rs: Choosing Your Strategy

AWS defines seven common migration strategies, known as the 7 Rs: Retire, Retain, Rehost, Relocate, Repurchase, Replatform, and Refactor. For large migrations, AWS recommends focusing on rehost, replatform, relocate, and retire. Refactor is not recommended for large migrations because modernizing during the migration is too complex to manage across many applications. That's a strong signal: save refactoring for your most critical apps, and use replatforming for the bulk of your portfolio.

Your Scenario: A 200-App Portfolio

Let's walk through a realistic plan. Start with the assessment phase. Use Azure Migrate to create a full inventory and dependency map of servers, services, and apps. The tool is free and uses a lightweight appliance that continuously sends configuration and performance data to the Azure Migrate service. This step is non-negotiable. Under-assessing the application portfolio leads to missed dependencies, which is a common migration challenge.

Once you have the inventory, categorize each application. Identify 'zombie applications'—those with average CPU and memory usage below 5%—and 'idle applications' (5-20% usage over 90 days). These are candidates for the retire strategy. In a typical portfolio, retire applies to about 10% of applications. That's 20 apps you can decommission immediately, saving money and effort.

For the remaining apps, group them into migration waves based on dependencies. Microsoft CAF recommends discovering all dependencies first and grouping workloads by shared databases, APIs, authentication services, or network connections. This avoids service disruptions during cutover.

The Replatform Wave

Now, choose which apps to replatform. Target applications that are good candidates for minor optimizations. For example, moving a .NET Framework app to .NET Core on Linux can reduce licensing costs. Or migrate VMs into containers using AWS App2Container. These changes are small but yield long-term benefits.

Here's a comparison of the main strategies:

As you can see, replatforming offers a balanced trade-off. It's not as easy as rehosting, but it's far less risky than refactoring.

Cutover and Optimization

During the migrate phase, use tools like AWS Application Migration Service (MGN) for rehosting, but for replatforming, you'll likely use a combination of manual steps and automation. The key is to plan for split-environment operations when some components must stay on-premises for technical or regulatory reasons. Document why they cannot move and minimize the time workloads operate across both environments.

After migration, the work isn't over. The Azure migration framework has four stages: Assess, Migrate, Optimize, and Monitor. Optimization is where you gain cost savings. Flexera 2025 found that 84% of organizations struggle to manage cloud spend. To avoid this, implement FinOps practices. 60% of organizations already use managed service providers and 59% are expanding their FinOps teams. Don't let costs spiral out of control.

Quick Tip

Warning: Don't underestimate the power of dependency mapping. Skipping it is the #1 cause of migration failures.

Bottom Line

Replatforming is the smartest default for most applications. It gives you cloud-native benefits without the cost and risk of a full refactor. Start with a thorough assessment, retire the zombies, replatform the rest, and optimize relentlessly. That's the path to a successful cloud migration.

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
• Microsoft Learn - https://learn.microsoft.com/en-us/training/modules/design-migrations/3-describe-azure-migration-framework
• 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