Skip the Lift-and-Shift: A Cost-First Migration Playbook

How do I keep my cloud migration from blowing up my budget? That's the question I hear from every IT leader who's read the headlines about cloud waste. And it's the right question, because the numbers are ugly: 84% of organizations say managing cloud spend is their top challenge (Flexera 2025). So let me give you a straight answer: stop lift-and-shifting everything, and start making cost a first-class citizen in your migration plan.

This is for anyone about to migrate—whether you're moving a dozen apps or a whole data center. I'm going to walk you through my five-step playbook, and I'm not going to sugarcoat it. You'll need to make some hard calls, like retiring apps you thought were essential and skipping the refactor that your engineers are itching to do. But if you follow this, you'll avoid the #1 mistake I see: treating migration as a purely technical exercise and ending up with a cloud bill that's 29% waste (Flexera 2026).

1. Kill the Zombies Before You Pay to Move Them

Before you even think about rehosting, you need to audit what you're actually running. I'm not talking about a quick spreadsheet. I'm talking about a real inventory with dependency mapping, because missed dependencies are a classic pitfall that derails projects (DigitalOcean). And here's the thing: you're probably running a bunch of servers that are doing nothing but burning cash.

AWS has a great way to identify these: if a server's average CPU and memory usage is below 5% for 90 days, it's a 'zombie application.' If it's between 5% and 20%, it's 'idle.' And if it hasn't had an inbound connection in 90 days, it's also a candidate. My rule: anything that's a zombie or idle gets retired—no exceptions. You'd be surprised how many 'critical' apps are actually just taking up space. Retiring them saves you the cost of migrating them, plus the ongoing compute you'd waste in the cloud.

But don't just kill things willy-nilly. For apps that are genuinely needed but have no cloud-friendly path, retain them on-premises. That's not a failure—it's a smart cost decision. AWS lists retain use cases like data residency compliance, high-risk apps that need more assessment, or mainframe systems like IBM AS/400 that are a nightmare to move (AWS Prescriptive Guidance). The point is to be ruthless about what actually earns its keep in the cloud.

2. Pick Replatform Over Rehost—and Definitely Over Refactor

Once you've cleared out the dead weight, you have to choose a strategy for the survivors. And here's where I'm going to be blunt: stop lift-and-shifting everything. Rehost is fast and simple because you don't change code, but you also don't get cloud-native benefits like auto-scaling (DigitalOcean). You're basically renting a server that behaves exactly like your old one, and you'll pay for the privilege. In fact, rehosted apps are harder to scale and you miss out on cost savings from managed services.

Instead, make replatform your default. Replatform means making minor optimizations during migration, like moving your SQL Server to a cloud-managed database (AWS Prescriptive Guidance). It's not a rewrite, so it doesn't cost a fortune, but it lets you shed the overhead of patching and maintaining your own database. And the data backs me up: replatforming was the most common migration approach in a Red Hat survey at 20%, and 47% of organizations plan to skip rehosting and go straight to replatforming (Red Hat). Those folks are on the right track.

What about refactor? I get it—microservices are sexy, and breaking a monolith into microservices can give you massive flexibility (Red Hat). But AWS is crystal clear: refactor is the most complex and costly strategy, and for large migrations, it's not recommended (AWS Prescriptive Guidance). You're modernizing during a migration, which is a recipe for delays and budget overruns. Save refactoring for a few apps that absolutely need it, and even then, do it after the migration, as a separate project.

3. Use Azure Migrate to See the Real Numbers

Now, before you commit to a strategy, you need data. I'm a huge fan of Azure Migrate—it's free, and it gives you a business case that compares your on-premises TCO with Azure, showing year-over-year cash flows (Azure Migrate). It does this by deploying a lightweight appliance in your data center that continuously sends performance data back to the service. That's the kind of concrete data you need to make decisions, not guesses.

Azure Migrate also does dependency analysis, which is crucial for avoiding those missed dependencies I mentioned. And it helps you right-size your VMs and SQL configurations, which is where a lot of waste starts. If you're not on Azure, that's fine—AWS has similar tools, but Azure Migrate is the one I know best. The point is to use a tool that gives you a business case, not just a technical checklist.

4. Budget for FinOps from Day One

Here's the thing that most migration plans miss: you need to budget for FinOps. Not just hope for the best—actually hire people or train your team. Flexera found that 59% of organizations are expanding their FinOps teams to regain control over cloud spend (Flexera 2025). And it's working: 63% now have a dedicated FinOps team (Flexera 2026). But if you wait until after migration, you're already behind.

FinOps isn't just about tagging resources—it's about measuring value. In 2026, 64% of organizations measure the value delivered to business units, and 49% use unit economics to link cloud cost to business outcomes (Flexera 2026). That's the kind of discipline that prevents waste from creeping in. So build FinOps into your migration project from the start. Identify who owns cost, set up tagging and reporting, and review it monthly. This isn't optional—it's the only way to keep your bill under control.

5. Optimize Continuously—Don't Set and Forget

Last, and this is a warning: don't think migration ends when you cut over. The Azure framework has four stages: Assess, Migrate, Optimize, and Monitor (Microsoft Learn). Most people do the first two and skip the last two. That's a mistake. Right after migration, you'll have workloads that are over-provisioned or just not performing as expected. You need to optimize.

Take a hard look at your usage patterns and right-size. And consider serverless for spiky workloads. Serverless is event-driven and metered on demand—if an idle function costs nothing, that's a huge win for cost (Red Hat). For example, if you have a nightly batch job that runs for 10 minutes, don't pay for a VM that's up 24/7. Use a serverless function and pay only for those 10 minutes.

Also, keep an eye on the metrics that matter. Flexera found that 87% of organizations now say cost efficiency is their #1 metric for assessing cloud goals, and tracking workload volume migrated jumped from 36% to 78% (Flexera 2025). That's a shift in mindset. You have to measure, or you'll never improve.

Quick tip: Don't forget to repurchase when it makes sense. If you're running a CRM that's a commodity, moving to a SaaS like Salesforce is often cheaper than any rehost or replatform (DigitalOcean).

Warning: The biggest risk is scope creep. You'll be tempted to refactor everything because it's 'the right thing to do.' Resist. AWS says refactor is the most complex strategy, and for large migrations it's a trap (AWS Prescriptive Guidance). Stick to your plan.

The single most important thing to remember: cloud cost is a migration strategy problem, not an afterthought. If you don't plan for cost from the start, you'll end up with a bill that's 29% waste (Flexera 2026). So kill the zombies, replatform, use Azure Migrate, build FinOps, and keep optimizing. That's how you win.

Sources

• 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/
• 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
• Red Hat - https://www.redhat.com/en/blog/how-should-you-modernize-your-applications
• DigitalOcean - https://www.digitalocean.com/resources/articles/cloud-migration-strategy