Don't Lift and Shift Everything: A Practitioner's Guide to Cloud Migration Strategies

So you're staring at a spreadsheet of hundreds of applications and your boss wants a cloud migration plan by Friday. The question you're probably typing into a search bar right now is: "Which migration strategy should I use for each app?" I've been through this more times than I can count, and the answer isn't a one-size-fits-all. It's a portfolio decision, and the framework that actually works is the 6 Rs—Rehost, Replatform, Refactor, Repurchase, Retire, and Retain (DigitalOcean). But here's the thing: most teams default to rehosting because it feels safe, and that's a mistake. This article is for the practitioner who wants to make deliberate, defensible choices—not just check boxes.

Who This Is For and the One Rule to Start With

This is for the cloud architect, the migration lead, the engineer who's been handed a legacy portfolio and told to "make it work." You're not building a greenfield app; you're moving what's already there. The first rule is brutally simple: before you pick a strategy, you need a full inventory. Not a spreadsheet you threw together in an afternoon—a real discovery. Azure Migrate, for example, is a free service that uses a lightweight appliance deployed in your datacenter to continuously send configuration and performance data to Azure (Azure Migrate). That's the kind of data you need to make decisions, not guesses. And if you're on AWS, the same principle applies: you must know what you have, how it's used, and what depends on it before you can choose a path.

Step 1: Assess and Classify Your Portfolio

The assessment phase is where you build that full inventory and map dependencies—every server, service, and app—and estimate cost savings using a TCO calculator (Microsoft Learn). This isn't just about counting VMs; it's about understanding what talks to what. Microsoft's Cloud Adoption Framework recommends discovering all dependencies first and grouping workloads into migration waves based on shared databases, APIs, authentication services, or network connections (Microsoft CAF). I've seen teams skip this and then watch a seemingly simple rehost fail because they missed a database dependency that was still on-premises. The other part of assessment is identifying the zombies. AWS defines 'zombie applications' as those with average CPU and memory usage below 5% over 90 days, and 'idle applications' as 5-20% usage over the same period (AWS Prescriptive Guidance). Those are your retire candidates right there. You'd be surprised how many apps you can just turn off.

Step 2: Match Each App to a Strategy—Not the Other Way Around

Now comes the fun part. For each app, you pick from the 6 Rs. Let's walk through them in the order I actually use them. First, Retire. If it's a zombie or has no inbound connection in the last 90 days, retire it (AWS Prescriptive Guidance). That's the cheapest migration of all. Second, Retain. Some apps stay on-premises for compliance, data residency, or because they run on mainframes like IBM AS/400 or Oracle Solaris (AWS Prescriptive Guidance). Don't fight it; document why and move on. Third, Rehost—lift and shift. This moves applications as-is without code changes, and it's the fastest and simplest method (DigitalOcean). AWS's rehosting service, now called AWS Transform MGN, automates the conversion of source servers into native EC2 instances using continuous block-level replication and orchestrated cutover (AWS Transform MGN). It's tempting because it's quick, but here's the warning: rehosted apps are not cloud-native and are harder to scale (DigitalOcean). Red Hat also notes that rehosting without modification can lead to higher long-term costs because you're running the same app without cloud-native capabilities (Red Hat). So use it for apps that are stable, don't need to scale, and are cheap to run as-is. Fourth, Replatform—lift, tinker, and shift. This makes minor optimizations, like moving Microsoft SQL Server to Amazon RDS for SQL Server (AWS Prescriptive Guidance). It's a sweet spot: you get some cloud benefits without a full rewrite. In Red Hat's survey, replatforming was the most common approach at 20% (Red Hat). That tells me it's practical. Fifth, Refactor—re-architect. This is the big one: break a monolith into microservices, move to serverless, or use containers. It delivers the most benefit but requires the most effort (DigitalOcean). AWS warns that refactoring is the most complex and costly strategy, and for large migrations they don't recommend it because modernizing during migration is too hard to manage across many apps (AWS Prescriptive Guidance). So save refactor for the handful of apps that are business-critical and need to scale. Finally, Repurchase—replace with a SaaS solution, like moving from a self-hosted CRM to Salesforce (DigitalOcean). This is often the fastest way to get off legacy software, but it means changing your processes. In Red Hat's survey, 13% of respondents intended to repurchase (Red Hat). That's a real option.

Step 3: Sequence and Execute in Waves

Once you've classified, you need to sequence. The Azure migration framework uses four stages: Assess, Migrate, Optimize, and Monitor (Microsoft Learn). AWS breaks it into three phases: assess, mobilize, and migrate (AWS Prescriptive Guidance). IBM has six steps, but they all boil down to the same thing: plan, then move, then fix. I like to start with the quick wins—retire the zombies, rehost a few simple apps—to build momentum. Then tackle the replatforms, and save refactors for later or for a separate initiative. For large migrations, AWS recommends focusing on rehost, replatform, relocate, and retire, not refactor (AWS Prescriptive Guidance). That's a lesson from real-world projects. And when you're moving data, don't forget the paths. Microsoft CAF lists four: ExpressRoute (private, dedicated connection), VPN (encrypted tunnel), Azure Data Box (physical device for offline), and the public internet (least secure) (Microsoft CAF). For large volumes, Data Box is a lifesaver—you literally ship a hard drive.

Step 4: Optimize and Monitor—Or You'll Bleed Money

Migration doesn't end at cutover. The fourth stage is Optimize, then Monitor (Microsoft Learn). This is where most teams fail. Flexera's 2025 State of the Cloud report found that 84% of organizations struggle to manage cloud spend (Flexera 2025). And wasted spend on IaaS and PaaS rose to 29% in 2026, the first increase after five years of decline (Flexera 2026). That's a lot of money going up in smoke. So you need to rightsize, use reserved instances, and turn off idle resources. You also need to measure the value. Flexera 2026 found that 64% of organizations now measure the value delivered to business units, and 49% use unit economics to link cloud cost to business outcomes (Flexera 2026). That's the right direction. And don't forget security. Under the shared responsibility model, you're always responsible for your data, endpoints, and access management (Microsoft Learn; AWS Shared Responsibility). With IaaS, you manage the guest OS and patches; with SaaS, the provider handles more (AWS Shared Responsibility). So make sure you're not leaving the door open.

What Can Go Wrong: The Rehost Trap

Here's the warning I promised. The biggest mistake I see is teams that rehost everything because it's fast and low-risk. They follow the 47% who plan to skip rehosting and go straight to replatforming (Red Hat)—actually, that's the smarter move. But if you rehost without any changes, you're just renting your data center in the cloud. You get no elasticity, no managed services, and you'll likely end up with higher costs than on-premises. Red Hat found that rehosting is quicker and lowers migration costs, but it can lead to higher long-term costs (Red Hat). So don't default to rehost. Use it for apps that are short-lived or genuinely simple. For everything else, at least replatform.

What I'd Actually Do

If I were running a migration tomorrow, here's my playbook. First, do a thorough discovery with a tool like Azure Migrate to get the full inventory and dependency map. Second, classify every app into the 6 Rs using the criteria above. I'd expect to retire about 10% (Red Hat found retire applied to 10% of applications) and retain some for compliance. Then I'd rehost the truly simple stuff, but I'd push replatform hard—it's the sweet spot. For a typical portfolio, I'd aim for 20% rehost, 30% replatform, 10% refactor, 10% repurchase, 10% retire, and 20% retain. That's not from a survey; it's my experience. Third, sequence in waves: start with quick wins, then the replatforms, and leave refactors for later or for a separate cloud-native initiative. Fourth, set up FinOps from day one—Flexera 2026 says 63% of organizations have a dedicated FinOps team (Flexera 2026), and you should too. And finally, measure everything: cost per workload, value delivered, and downtime. If you do that, you'll avoid the 84% who struggle with 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
• 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