Cloud Migration Cost Myths: Why Lift-and-Shift Isn't Always Cheaper

Imagine you're a cloud architect at a mid-sized company. The CFO has just told you to cut cloud costs by 20%, and the CIO is pushing a "cloud-first" mandate. Your inbox is full of bids from consultancies, each promising a "seamless" migration. The easy answer seems to be: lift everything as-is, because that's what everyone says is cheapest and fastest. But after a year, your cloud bill is 30% higher than your on-premises data center costs, and the CFO is asking why. Sound familiar? You're not alone.

Here's the uncomfortable truth: the cheapest migration is rarely the cheapest operation. We've been in the trenches migrating everything from tiny WordPress sites to sprawling SAP estates, and the one pattern that keeps repeating is that teams confuse migration cost with cloud cost. They're different numbers, and if you optimize for the first, you'll blow up the second.

This article is a myth-busting FAQ on cloud migration cost optimization. We'll cut through the vendor hype and give you the straight talk from people who actually plan and execute these moves. We'll tell you which strategies save money and which ones quietly bleed it.

Isn't lift-and-shift the cheapest way to migrate?

Short answer: it's the fastest and lowest-risk migration, but it often leads to higher operating costs. Lift-and-shift (or rehost) moves applications to the cloud without code changes, which means you can migrate thousands of servers quickly using automated tools like AWS Application Migration Service (AWS MGN). That's why 38% of organizations plan to rehost first, according to Red Hat's survey. But here's the rub: rehosted apps aren't cloud-native. They don't auto-scale, they don't use managed services, and they often run on oversized VMs because you didn't take time to right-size them. As Red Hat bluntly warns, rehosting without modification can lead to higher long-term costs because you're paying cloud rates for on-premises inefficiencies.

Our advice: treat lift-and-shift as a tactical move, not a strategy. Use it to get out of a data center lease quickly, but budget for a second phase of optimization. If you're going to be in the cloud for more than a couple of years, you'll likely need to replatform or refactor the heavy hitters eventually.

What's the difference between rehost, replatform, and refactor, and which is cheapest?

These are from the classic 6 Rs framework (or 7 Rs if you count AWS's relocate). Rehost is lift-and-shift. Replatform means making minor optimizations during migration—like moving a SQL Server database to a cloud-managed RDS instance—without changing the app's core architecture. Refactor (or re-architect) means redesigning the app to use cloud-native features like microservices or serverless. The cost curve is inverse to the effort. Rehost is cheapest upfront, refactor is the most expensive and complex, and AWS explicitly advises not to refactor during large migrations because it's too hard to manage across hundreds of apps. But here's the kicker: refactor delivers the most benefit over time. In practice, most organizations don't go straight to a full refactor. Red Hat's survey found that 20% of replatforming is the most common approach, and 47% skip rehosting altogether and go straight to replatforming. That's a smart middle ground: you get some cloud-native benefits without a full rewrite.

Why is my cloud bill higher than my on-premises costs?

If you lift-and-shift without right-sizing, you're paying for the same fat VMs you had on-premises, but now you're also paying for cloud networking, egress, and possibly premium support. A common trap is that on-premises servers are often over-provisioned to handle peak load, and you carry that same over-provisioning into the cloud. The cloud bills you for what you allocate, not what you use. That's why the assessment phase is critical. Azure Migrate can help you right-size VM sizes and estimate costs, and AWS has similar tools. But the bigger issue is that many teams skip the optimize phase that follows migration. Microsoft's Azure migration framework has four stages: Assess, Migrate, Optimize, and Monitor. Too many teams stop after Migrate. Then they're shocked when Flexera's 2025 report says 84% of organizations struggle to manage cloud spend, and wasted cloud spend on IaaS/PaaS hit 29% in 2026—the first increase after five years of decline.

Our take: if you don't have a FinOps practice, you're flying blind. Flexera found that 63% of organizations now have a dedicated FinOps team, and 71% have a Cloud Center of Excellence. If you're not there yet, start small—even one person tracking spend and tagging resources can make a dent.

Is it better to buy reserved instances or use serverless to save money?

It depends on your workload predictability. For steady-state, always-on workloads, reserved capacity (like AWS Reserved Instances or Azure Reserved VM Instances) can save up to 60% compared to on-demand. But if you have spiky or unpredictable traffic, serverless is a better bet because you only pay for what you use—an idle function costs nothing. Red Hat defines serverless as an event-driven model where servers are abstracted away, and you're metered on demand. The catch is that serverless (like AWS Lambda or Azure Functions) requires a refactor—you can't just lift a monolithic app into Lambda. So the cost optimization isn't about picking one over the other; it's about matching the right tool to the workload. Our recommendation: use reserved instances for your baseline, and use serverless for new or refactored components that have variable demand. And always, always right-size—don't just take the default VM size.

Should I retire or retain some applications instead of migrating them?

Absolutely. One of the biggest cost leaks is migrating applications that shouldn't be in the cloud at all. AWS defines "zombie applications" as those with average CPU and memory usage below 5% over 90 days—they're doing nothing but still incurring costs. "Idle applications" are between 5% and 20% usage. These are prime candidates for retire—just turn them off. In Red Hat's survey, retire applied to only 10% of applications, but that's a missed opportunity. And retain—keeping some apps on-premises—is often the right call for compliance or technical reasons. AWS lists data residency, recently upgraded apps, or unresolved dependencies as reasons to retain. Don't feel pressured to move everything. As Flexera's 2025 data shows, only 21% of cloud workloads have been repatriated, but that doesn't mean you should migrate the other 79% blindly. Do a portfolio assessment and kill the zombies before you pay to move them.

How do I estimate the total cost of ownership (TCO) before migrating?

You should do a proper TCO analysis during the assess phase. Azure Migrate has a business case feature that estimates on-premises vs. Azure costs, comparing cash flows year over year. AWS has a TCO calculator too. The key is to include not just compute and storage, but also networking, egress fees, and operational overhead like patching and monitoring. A common mistake is comparing only the raw infrastructure costs and ignoring the fact that cloud shifts you from CapEx to OpEx. That shift can be beneficial for cash flow, but it also means you have ongoing variable costs that need active management. One practical tip: use the free tools available. Azure Migrate is free to use, and it can do dependency analysis to avoid missing critical connections. But remember, a TCO estimate is only as good as your assumptions. If you're not planning to right-size, your Azure estimate will be too high.

What are the biggest cost pitfalls during migration, and how can I avoid them?

DigitalOcean lists common pitfalls: budget overruns, security vulnerabilities, and organizational resistance. But on the cost side, the biggest are these: (1) Under-assessing the portfolio—you miss dependencies, and you end up with surprise egress charges or rework. (2) Not using a wave plan. Microsoft's Cloud Adoption Framework recommends grouping workloads into migration waves based on dependencies to avoid service disruptions. If you move a database before the app that uses it, you'll have a mess. (3) Inadequate validation testing before cutover. If you have to roll back, you've wasted the migration effort and often paid double for a period. (4) Ignoring FinOps after migration. Flexera's 2025 report found that the share of organizations tracking volume of workloads migrated jumped from 36% to 78%, and cost avoidance tracking from 28% to 64%—a sign that people are starting to measure the right things, but there's still a long way to go. Our advice: build a rollback plan, do dependency mapping, and have a FinOps person on day one of the project, not after the bill arrives.

Quick tip: Before you migrate anything, turn on cost tagging in your cloud account and enforce it. If you can't tag it, you can't track it—and you'll be lost when the bill comes.

What's the real cost of multi-cloud or hybrid-cloud strategies?

Multi-cloud and hybrid can be justified—for resilience, avoiding lock-in, or meeting data residency—but they add complexity. Flexera 2026 shows 73% of organizations have hybrid cloud estates, and multi-cloud is growing. But complexity costs money: you need skilled staff who know multiple platforms, and you might duplicate security and management tooling. DigitalOcean notes that many companies do cloud-to-cloud migrations to reduce costs or improve performance, but that's different from running in multiple clouds simultaneously. Our view: don't adopt multi-cloud just for the sake of it. If you're doing it for cost leverage, remember that the discounts you get from a single cloud provider often outweigh the theoretical savings of shopping around. And if you do go hybrid, plan for split operations carefully—Microsoft CAF advises documenting why some components stay on-premises and minimizing the time you're running in both environments.

One concrete example: a customer consolidated 80 SAP systems and achieved 30% cost savings by moving to a cloud-native architecture, according to AWS. That's a refactor, not a lift-and-shift. It took time and investment, but the payoff was significant. The lesson is that the biggest savings come from modernization, not from simply moving the same old servers to new hardware.

The takeaway

Cloud migration cost optimization isn't about finding the cheapest migration strategy; it's about running your workloads efficiently once they're in the cloud. Rehosting gets you out the door fast, but if you don't right-size, modernize, and actively manage your spend with FinOps, you'll end up paying more than you did on-premises. So start with a thorough assessment, retire the zombies, replatform where you can, and don't be afraid to keep some things on-premises. And above all, treat cost optimization as an ongoing process, not a one-time event. The cloud bill doesn't stop when the migration ends—it's just the beginning.

Sources

• AWS Prescriptive Guidance - https://docs.aws.amazon.com/prescriptive-guidance/latest/large-migration-guide/migration-strategies.html
• Red Hat - https://www.redhat.com/en/blog/how-should-you-modernize-your-applications
• 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/
• Microsoft Learn - https://learn.microsoft.com/en-us/training/modules/design-migrations/3-describe-azure-migration-framework
• DigitalOcean - https://www.digitalocean.com/resources/articles/cloud-migration-checklist