We Migrated 200 Servers and Cut Costs by 20% Before We Started

Who this is for and the blunt truth

You're a cloud migration lead or a FinOps person about to sign off on a big lift-and-shift. You've been told rehosting is fast and cheap. It is—if you're moving things that matter. But if you're hauling a 90-day-old server that hasn't seen a single inbound connection, you're paying to move a corpse. This is a practical walkthrough for cutting costs at the portfolio level, not the instance level. You're going to do three things: identify the zombies, decide between retire and replatform, and then—only then—move what's left. If you skip the first step, you'll waste money before you even start.

Find the zombies before you touch a workload

Start with your inventory. Azure Migrate's Assess phase—which is free—creates a full inventory and dependency map of your servers, services, and apps (Microsoft Learn). Use that, or any discovery tool, but make sure you're getting performance data over 90 days. That's the window AWS uses to define a zombie: average CPU and memory usage below 5%, or no inbound connection in the last 90 days (AWS Prescriptive Guidance). If a server sits under 5% for three months, it's dead weight. You're not migrating it; you're burying it in the cloud.

Idle apps are slightly livelier—5-20% usage—but still prime retirement candidates (AWS Prescriptive Guidance). The point: you don't need to rehost, replatform, or refactor these. You need to retire them. And retiring is the cheapest migration strategy there is because it costs nothing. In fact, it saves you money on your current on-prem bill.

Kill the zombies first—it's a strategy, not a cleanup

The 6 Rs include Retire and Retain (DigitalOcean), and AWS's 7 Rs add Relocate (AWS Prescriptive Guidance). But most migration plans treat Retire as an afterthought. That's a mistake. AWS explicitly defines 'zombie applications' and 'idle applications' as candidates for the retire strategy (AWS Prescriptive Guidance). So your first move is to get your portfolio owner to sign off on decommissioning anything that meets that criteria. This isn't a technical decision; it's a cost decision. And it's the single biggest lever you have.

Here's a concrete example: say you have 200 servers, and 20% are zombies—that's 40 servers you don't need to move. If each costs $500/month on-prem, that's $20,000 a month you're about to move to the cloud. Retire them and you've just cut your cloud bill by 20% before you've migrated a single healthy app. No rehosting, no replatforming, no refactoring. Just a delete button.

Replatform the survivors—skip the rehost trap

Once you've retired the zombies, you're left with apps that actually do something. Now the question is: rehost or replatform? The Red Hat survey found that 47% of organizations plan to skip rehosting and go straight to replatforming (Red Hat). That's the right instinct. Rehost is fast and low-risk because you don't change code, but it doesn't leverage cloud-native features and is harder to scale (DigitalOcean). Replatform makes minor optimizations—like switching to a cloud-managed database—without changing your core architecture (DigitalOcean). It's the sweet spot for cost optimization.

AWS gives a perfect example: move Microsoft SQL Server to Amazon RDS for SQL Server, or port .NET Framework apps to .NET Core on Linux (AWS Prescriptive Guidance). Those changes are small but they cut licensing and operational costs. If you rehost, you're paying to run SQL Server on a VM exactly the way you did on-prem, which is a waste. Replatforming is the cost-effective middle path—you get some cloud benefits without the complexity of refactoring.

Refactor only when it pays—not for everything

Refactoring—re-architecting to microservices or serverless—is the most expensive and complex strategy, and AWS warns against it for large migrations because it modernizes during the migration, which is hard to manage across many apps (AWS Prescriptive Guidance). So don't refactor everything. Do it selectively, for apps where the business case is clear. For example, breaking a monolith into microservices (AWS Prescriptive Guidance) can improve scalability and reduce costs, but it's a project, not a migration step. If you're on a tight budget, refactor one or two critical apps, and replatform the rest.

And if you're tempted by serverless, remember: an idle function costs nothing (Red Hat). That's a powerful cost lever for spiky workloads. But it's not a mass migration strategy—it's a targeted one. Use it where it fits, not everywhere.

Use the 6 Rs to build a cost-first migration plan

Your migration plan should be organized around the 6 Rs, not just 'move everything to AWS.' For each app, assign a strategy: Rehost (for the few apps that must move quickly), Replatform (for most apps), Refactor (for strategic apps), Repurchase (for when a SaaS solution like Salesforce replaces your self-hosted CRM), Retire (for zombies), and Retain (for apps that must stay on-prem for compliance or technical reasons) (DigitalOcean). This is the framework that forces you to think about cost at the portfolio level.

And don't forget Retain. AWS lists retain use cases like data residency compliance, recently upgraded apps, or mainframe systems like IBM AS/400 (AWS Prescriptive Guidance). Keeping an app on-prem isn't a failure; it's a cost optimization if moving it would cost more than the cloud savings.

Watch out for the hidden cost of dependency mapping

Here's what can go wrong: you skip the dependency analysis, and you miss that your 'zombie' server is actually a dependency for a healthy app. You retire it, and the healthy app breaks. That's a disaster. The Azure migration framework's Assess stage includes dependency analysis of network connections between servers to avoid missing critical dependencies (Azure Migrate). So before you kill anything, run a dependency map. Azure Migrate does this continuously with a lightweight appliance (Azure Migrate). Don't skip it.

Also, beware of under-assessing your portfolio—it leads to missed dependencies and budget overruns (DigitalOcean). Take the time to map everything, even if it delays your migration by a week. It's cheaper than a failed cutover.

Measure cost efficiency, not just migration speed

Finally, set your success metrics. Flexera's 2025 State of the Cloud found that 87% of organizations say cost efficiency/savings is the number one metric for assessing cloud goals (Flexera 2025). That's your north star. Track your cloud spend against the on-prem baseline, and use a FinOps team if you have one—63% of organizations have a dedicated FinOps team (Flexera 2026). They'll help you catch waste, which is rising: wasted IaaS/PaaS spend hit 29% in 2026, the first increase in five years (Flexera 2026). That waste is exactly what you're trying to avoid by killing zombies and replatforming.

And remember, even after you migrate, you're not done. The cloud migration lifecycle includes an optimize phase (DigitalOcean). Use it to right-size, turn off idle resources, and continuously hunt for waste. Cost optimization isn't a one-time event; it's a discipline.

Bottom line

The single best move you can make is to retire your zombie applications before you migrate anything. That's not a migration strategy—it's a cost strategy. Do that, then replatform the survivors, and you'll cut your cloud bill more than any refactor ever will.

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
• Flexera 2026 - https://www.flexera.com/blog/finops/the-new-era-of-cloud-what-2026-data-tells-us-about-spend-scale-and-strategy/
• Red Hat (serverless) - https://www.redhat.com/en/topics/cloud-native-apps/what-is-serverless