Stop Lift-and-Shifting Everything: How to Pick the Right Migration Strategy

Who This Is For

You're a cloud architect or migration lead staring at a spreadsheet of hundreds of applications, and someone just said, "Let's lift and shift everything to AWS." That's a trap. The fastest path to the cloud isn't always the smartest one. This guide walks through how to actually decide what to do with each workload—using the 7 Rs—so you don't end up with a pile of rehosted apps that are expensive to run and hard to scale.

The Misconception: Rehost Is the Default

Most teams default to rehosting because it's quick and feels low-risk. But rehosting is just moving the problem—you get the same app, now running in the cloud, but you've added the complexity of cloud operations without any of the benefits. Red Hat's survey found that 38% of organizations plan to rehost first, then replatform, then refactor, while 47% plan to skip rehosting and go straight to replatforming (Red Hat). That's telling: the smartest teams are skipping the easy step because they know it's a trap. Rehosting is a valid strategy, but it's not a default.

Step 1: Inventory Everything—Even the Zombies

Before you can decide, you need a full inventory of what you have. Azure Migrate's assessment phase includes creating a complete inventory and dependency map of servers, services, and apps (Microsoft Learn). And don't forget the zombies—AWS defines "zombie applications" as those with average CPU and memory usage below 5% and "idle applications" as 5-20% over 90 days. Both are candidates for retirement (AWS Prescriptive Guidance). So, first step: build that inventory, including the zombie detectors.

Step 2: Apply the 7 Rs—with Brutal Honesty

Now, take each workload and run it through the 7 Rs. The framework from AWS includes Retire, Retain, Rehost, Relocate, Repurchase, Replatform, and Refactor (AWS Prescriptive Guidance). Here's how to apply each one:

• Retire: If it's a zombie, kill it. No reason to move something nobody uses.
• Retain: Keep it on-premises if you must—data residency, high-risk apps, or dependencies (AWS Prescriptive Guidance).
• Rehost: When speed matters more than innovation. Use it for quick wins, but know you're not getting cloud-native benefits.
• Relocate: If you're on VMware, moving to VMware Cloud on AWS is the quickest way—it's a hypervisor-level lift and shift (AWS Prescriptive Guidance).
• Repurchase: Ditch the custom CRM and buy Salesforce (DigitalOcean). Sometimes the cloud is just a catalyst for replacing software.
• Replatform: Make small changes—like moving SQL Server to Amazon RDS for SQL Server (AWS Prescriptive Guidance). This is often the sweet spot.
• Refactor: The big one—re-architect into microservices or serverless. It's the most complex and costly, but it's where the real value is (AWS Prescriptive Guidance).

Step 3: Don't Refactor Everything in a Large Migration

Here's a warning: if you're migrating thousands of apps, do not try to refactor them all during the migration. AWS explicitly says refactor is not recommended for large migrations because it's the most complex strategy to manage across many applications (AWS Prescriptive Guidance). Instead, use rehost, replatform, relocate, and retire as your primary strategies. Save refactoring for a pilot or for a few critical apps. You can always modernize later.

Step 4: Plan for the Long Term—Not Just the Move

Rehosting without modification can lead to higher long-term costs because you're running apps in the cloud without cloud-native capabilities (Red Hat). That's the hidden cost. So, after you move, you need a plan to optimize. That's where FinOps comes in. Flexera 2026 found that 63% of organizations have a dedicated FinOps team (Flexera 2026). And wasted cloud spend on IaaS and PaaS rose to 29% in 2026, the first increase after five years of decline (Flexera 2026). Don't be part of that waste—build cost monitoring into your migration plan from day one.

Step 5: Use the Right Tools—and Know the Shared Responsibility

You don't have to do this by hand. Azure Migrate is a free service that includes a lightweight appliance for discovery and continuous data collection (Azure Migrate). AWS has Application Migration Service (MGN) for automated rehosting (AWS Transform MGN). And for data, Microsoft's CAF lists four paths: ExpressRoute for private, dedicated connections; VPN for encrypted tunnels; Azure Data Box for offline shipping of large volumes; and the public internet as the least secure option (Microsoft CAF).

But whatever tool you use, remember the shared responsibility model. Under AWS, you're responsible for the guest OS, application software, and security groups on EC2; under Azure, you always own your data and access management (AWS Shared Responsibility, Microsoft Learn). Don't assume the cloud provider secures everything.

What Can Go Wrong

Here's the classic failure: you rehost a legacy app, but you missed a dependency—a database that has to stay on-premises for compliance. Microsoft CAF warns about split-environment operations: when some components must stay in the source environment, you need to document why and minimize the time workloads operate across both (Microsoft CAF). If you skip dependency mapping, you'll have an app that crashes in production because it can't reach its database.

Bottom Line

The single best move is to stop reflexively rehosting. Go through the 7 Rs for every workload, be brutally honest about which are zombies, and replatform or refactor where it matters—but save refactoring for the few, not the many. That's how you migrate without creating a legacy cloud problem.

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
• Flexera 2026 - https://www.flexera.com/blog/finops/the-new-era-of-cloud-what-2026-data-tells-us-about-spend-scale-and-strategy/