Stop Lifting and Shifting: Pick a Cloud Migration Strategy That Pays

Imagine you're the IT lead at a mid-sized company. Your CEO just read a report that 78% of IT leaders have moved storage and backups to the cloud (AWS). The board wants a migration. You have a portfolio of 200 legacy apps, some running on aging hardware, and a mandate to 'modernize.' If you're like most teams, your instinct is to lift and shift everything—it's fast, it's simple, and it gets you to the cloud in weeks. But that instinct is exactly what will sink your cloud strategy.

I've seen too many migrations that treat the cloud as just someone else's data center. They rehost everything, celebrate the cutover, and then watch costs balloon and performance stagnate. The truth is, rehosting has its place, but it's not a strategy—it's a starting point. The real work is deciding which applications deserve a deeper transformation.

This guide is for anyone planning a migration who wants to avoid the 'lift-and-shift regret.' I'm going to walk you through a practical, step-by-step approach to choosing and executing the right migration strategy for each workload. You'll learn the vocabulary, the trade-offs, and the one mistake that will quietly destroy your budget.

1. Know Your Alphabet Soup: The Rs and the Phases

Before you touch a single server, get the framework straight. The core vocabulary comes from Gartner's original 5 Rs, now commonly expanded to 6 or 7 (Red Hat). The most useful set for me is the 7 Rs from AWS: Retire, Retain, Rehost, Relocate, Repurchase, Replatform, and Refactor (AWS Prescriptive Guidance). Understanding these terms isn't academic—it's the difference between a thoughtful plan and a chaotic scramble.

You also need a process. The cloud providers have you covered. Microsoft's Azure migration framework uses four stages: Assess, Migrate, Optimize, and Monitor (Microsoft Learn). AWS breaks large-scale migrations into three phases: assess, mobilize, and migrate (AWS Prescriptive Guidance). IBM lists six steps, and DigitalOcean recommends five (IBM, DigitalOcean). The details differ, but the pattern is consistent: inventory, plan, execute, and then—crucially—optimize. Don't skip the last part; it's where the real value lives.

2. Start with an Honest Inventory: Find the Zombies

You can't choose a strategy for applications you don't know you have. The first phase is a full inventory and dependency map (Microsoft Learn). This is where you'll find the 'zombie applications'—the ones with average CPU and memory usage below 5% over 90 days, or no inbound connections in that window (AWS Prescriptive Guidance). These are prime candidates for the Retire strategy. I've consulted with companies that discovered 15% of their portfolio was dead weight. Retiring them saves money and reduces attack surface.

For everything else, you need dependency mapping. Azure Migrate provides a lightweight appliance that continuously sends configuration and performance data to the service, and it includes dependency analysis to avoid missing critical connections (Azure Migrate). This is not optional. The biggest reason migrations fail is missed dependencies, which lead to broken applications and unhappy users (DigitalOcean).

3. Classify Each Workload: Rehost, Replatform, Refactor, or Retire

Now the fun part: assign a strategy to every application. Here's my blunt advice: don't default to rehosting. Rehosting, or lift and shift, moves applications as-is with no code changes (DigitalOcean). It's the fastest and easiest, but you won't get cloud-native benefits like auto-scaling or managed services. In a Red Hat survey, 38% of organizations planned to rehost first, then replatform or refactor, while 47% planned to skip rehosting entirely and go straight to replatforming (Red Hat). The latter group gets it.

Replatforming, or 'lift, tinker, and shift,' makes small optimizations—like moving SQL Server to a managed database service—without changing the core architecture (DigitalOcean). This is often the sweet spot. AWS gives great examples: moving Microsoft SQL Server to Amazon RDS, or porting .NET Framework apps to .NET Core on Linux (AWS Prescriptive Guidance). Refactoring, or re-architecting, is the most complex and costly, but it unlocks the full potential of cloud-native features like microservices and serverless (DigitalOcean). Only do this for applications that are business-critical or need to scale.

Don't forget Repurchase: replacing a custom app with a SaaS solution like moving from a self-hosted CRM to Salesforce (DigitalOcean). And Retain: keeping some applications on-premises for compliance or technical reasons (DigitalOcean). You don't have to move everything.

4. Plan for the Long Haul: Cost, Security, and the Shared Responsibility Trap

Here's where the rubber meets the road. In Flexera's 2025 State of the Cloud report, 84% of respondents said managing cloud spend is their top challenge (Flexera 2025). And in 2026, wasted cloud spend on IaaS and PaaS rose to 29%—the first increase after five years of decline (Flexera 2026). That's not a coincidence; it's a direct result of rehosting everything without a cost strategy.

Security is the other trap. The shared responsibility model is clear: the cloud provider secures the infrastructure, but you're responsible for your data, access management, and compliance (AWS Shared Responsibility). With IaaS like EC2, you manage the guest OS and patches; with PaaS like S3, you manage data classification and IAM permissions (AWS Shared Responsibility). If you rehost a legacy app and forget to patch the OS, that's on you.

5. Execute in Waves, Not a Big Bang

Don't try to migrate everything at once. Use the phased approach. AWS says their three-phase method lets you migrate the first set of applications in weeks (AWS Prescriptive Guidance). Group workloads into migration waves based on dependencies (Microsoft CAF). Start with the easy wins—apps that are self-contained and low-risk. Then tackle the complex ones once your team has experience.

For each wave, pick the right tool. AWS has Application Migration Service (MGN) for automated rehosting, which uses continuous block-level replication for minimal downtime (AWS Transform MGN). Azure has Azure Migrate for assessment and migration (Azure Migrate). For data, consider the paths: ExpressRoute for a private connection, VPN for encrypted tunnels, or Azure Data Box for offline transfer of large volumes (Microsoft CAF). The public internet is the least secure option—avoid it for sensitive data.

6. Optimize and Monitor: The Cloud Is Not a Set-and-Forget

Migration isn't over when the cutover is done. The Optimize and Monitor stages are where you actually save money and improve performance (Microsoft Learn). In Flexera's 2026 report, 63% of organizations have a dedicated FinOps team, and 71% have a Cloud Center of Excellence (Flexera 2026). You need someone watching the spend. The 2025 data showed that cloud budgets exceeded limits by 17%, and cloud spend was expected to increase by 28% in the coming year (Flexera 2025). If you don't have a cost control mechanism, you'll get a nasty bill.

Here's a concrete example: Suppose you rehost a legacy application with 10 virtual machines. On-premises, you had overprovisioned for peak load. In the cloud, you can right-size those VMs using Azure's assessments, which estimate the right VM size and cost (Azure Migrate). That alone can cut your bill by 30%—a real AWS customer consolidated 80 SAP systems and achieved 30% cost savings with a cloud-native transformation (AWS). That's the payoff of doing it right.

What Can Go Wrong: The Cost of Skipping Refactoring

Here's the warning I promised. The most common failure is rehosting everything and then assuming you're done. In Red Hat's survey, 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 pay for VMs that sit idle, you miss out on auto-scaling, and you're still managing patching and upgrades yourself. The Flexera 2026 data shows that wasted spend rose to 29%—that's nearly a third of your cloud bill going up in smoke (Flexera 2026). If you don't build a modernization roadmap that includes replatforming or refactoring over time, you'll be stuck with a 'cloudy' data center that costs more than the one you left.

Also, watch out for 'cloud-to-cloud' migrations—moving from one cloud to another to reduce costs or avoid lock-in (DigitalOcean). That's a whole different beast, and it's often a sign that the first migration wasn't thought through.

My Recommendation: Be Strategic, Not Reactive

Here's my blunt advice: stop treating migration as a single event. Treat it as a portfolio exercise. Retire the zombies, retain what must stay, rehost only the trivial apps, replatform the majority, and refactor the few that truly need it. Use the 7 Rs as your filter, and don't let the 'lift and shift' crowd convince you that speed is everything. Speed without a strategy is just a faster way to waste money.

Start with a thorough assessment. Use Azure Migrate or AWS's tools to map dependencies and estimate costs. Then, classify each workload and plan your waves. And above all, budget for optimization. The cloud is a pay-as-you-go model, but it's also a 'pay-for-what-you-use' model—and if you use it inefficiently, you'll pay for that inefficiency.

The organizations that get this right are the ones that see the cloud as a transformation opportunity, not a data center relocation. They're the ones that achieve 30% cost savings and exit data centers in record time (AWS). You can be one of them—if you're willing to think beyond the lift.

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
• 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/