Imagine you are a VP of infrastructure at a mid-sized retailer. You've just finished a lift-and-shift of 200 virtual machines to the cloud. The board is happy because you came in under budget. But six months later, your finance team is staring at a cloud bill that's 35% higher than the on-premises cost you were trying to escape. Your CFO is asking why you moved at all. You're not alone—this is the story I hear again and again. The dirty secret of cloud migration is that rehosting is a cost trap disguised as a quick win. And the fix is not to avoid the cloud—it's to replatform with a FinOps team from day one. Here's how you do it.
The Myth of Cheap Lift-and-Shift
Lift-and-shift, or rehost, moves applications as-is without code changes. It's fast and simple, which is why it's so tempting. But here's the catch: rehosted applications aren't cloud-native, and they're harder to scale. You're essentially renting the same servers you used to own, but now you're paying for them monthly. Red Hat warns that rehosting without modification can lead to higher long-term costs because you're running applications in the cloud without cloud-native capabilities. In other words, you're paying for the cloud's convenience but not getting its efficiency.
So why does everyone do it? Because it's the path of least resistance. AWS even recommends rehost for large migrations because it's manageable across many applications. But manageable doesn't mean cost-effective. The real question is: what do you do after you've rehosted?
The Replatform Middle Ground
Replatform, or 'lift, tinker, and shift,' makes minor optimizations during migration—like switching to a cloud-managed database—without changing core architecture. It's the sweet spot between speed and savings. Red Hat's survey found that replatforming was the most common migration approach at 20%, and 47% of organizations plan to skip rehosting and go straight to replatforming. That's smart. You get the speed of lift-and-shift but with a few cloud-native tweaks that can cut your bill significantly.
For example, instead of moving your SQL Server to a VM, you could move it to Amazon RDS for SQL Server. That's a classic AWS-replatform move. You're not rearchitecting the app, but you're letting the cloud provider handle the database patching, backups, and high availability. That saves you admin time and can reduce your compute footprint. But replatforming alone isn't enough if you don't have a way to measure what you're spending and why.
Why Your FinOps Team Is Your Lifeline
Here's where the hard truth comes in. Flexera's 2025 State of the Cloud report found that 84% of organizations say managing cloud spend is their top challenge. And in 2026, wasted cloud spend on IaaS and PaaS rose to 29%—the first increase after five years of decline. That means nearly a third of your cloud bill is going to resources that are running but not doing anything useful. That's not a technology problem; it's a management problem.
The solution is FinOps. Flexera found that 60% of organizations use managed service providers and 59% are expanding their FinOps teams to regain control. By 2026, 63% have a dedicated FinOps team. FinOps isn't just about tracking costs—it's about creating accountability. You need a team that can tag resources, identify waste, and set budgets. Without that, your replatforming efforts will be undermined by forgotten dev servers that run all night.
The Assessment Phase Is Where You Win or Lose
Before you move anything, you need to assess what you have. The Azure migration framework starts with Assess—creating a full inventory and dependency map of every server, service, and app. You also need to estimate cost savings using a TCO calculator. Microsoft Learn suggests using the Azure TCO Calculator to compare on-premises vs. cloud costs. But here's the twist: you need to assess not just what you have, but what you don't need. AWS defines 'zombie applications' as those with CPU and memory usage below 5% for 90 days. Those are prime candidates for retirement—not migration. If you lift and shift a server that's barely using any resources, you're paying to move a zombie into your cloud.
So, in your assessment, you need to be ruthless. Look for applications with no inbound connections in 90 days. Retire them. For those that stay, you need to understand dependencies. Microsoft CAF recommends discovering all dependencies first and grouping workloads into migration waves. Don't move a database before the app that depends on it.
Optimize After You Migrate—Or Pay Forever
Migration isn't the finish line. Both DigitalOcean and IBM include an 'optimize' step after migration. DigitalOcean's five-phase process—prepare, plan, migrate, operate, optimize—ends with cost optimization and performance monitoring. IBM's six-step workflow also ends with optimize and maintain. But most teams skip this step. They move, they celebrate, and then they never look back.
That's a fatal mistake. Cloud resources are elastic, but they don't shrink on their own. You need to right-size your VMs, turn off idle resources, and use reserved instances or savings plans. Flexera found that cloud budgets exceeded limits by 17% in 2025, and spend was expected to rise 28%. If you don't optimize, your bill will only grow.
Why Replatforming Plus FinOps Beats Rehosting
So, what's the recommendation? Replatform your critical applications, retire the zombies, and build a FinOps team before you flip the switch. Don't just lift and shift and hope for the best. In Red Hat's survey, only 10% of applications were retired, and 13% were repurchased. That means most apps are staying in your portfolio—so you need to make them efficient.
Here's a comparison of the two main strategies I've seen play out:
| Criterion | Rehost (Lift-and-Shift) | Replatform (Lift, Tinker, Shift) |
|---|---|---|
| Speed | Fastest, no code changes | Slightly slower, minor changes |
| Initial cost | Lower migration cost | Higher migration cost |
| Long-term cloud cost | Higher due to lack of cloud-native features | Lower if you use managed services |
| Scalability | Limited, not cloud-native | Better, can leverage PaaS |
| FinOps fit | Needs heavy tagging and monitoring | Easier to optimize with managed services |
In one AWS case study, a customer consolidated 80 SAP systems and achieved 30% cost savings with a cloud-native transformation. That's the potential when you go beyond rehosting. But you don't have to refactor everything—replatforming gives you a middle path.
So, here's my advice: if you're planning a migration, resist the urge to rehost everything. Instead, replatform what you can, retire what you don't need, and bring in FinOps before you start. Your CFO will thank you.
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/
Comments (0)
Please sign in to post a comment.
Don't have an account? Create one
No comments yet. Be the first to comment!