Moving workloads to the cloud without re-architecting them is sometimes the right call. Speed matters. Risk matters. Keeping the migration scope contained so you actually finish is often worth the architectural compromise.
But the bill that arrives three months later is almost always a surprise. And in my experience helping enterprises migrate and optimize their AWS environments, it doesn't have to be.
What Lift and Shift Actually Costs
When you lift and shift, you're essentially buying cloud hardware at cloud prices for on-premises utilization patterns. On-premises, it made sense to size servers for peak load — you owned the hardware, so idle capacity was a sunk cost. In the cloud, idle compute is a running invoice.
The typical enterprise running a lift-and-shift migration ends up with:
- EC2 instances sized for peak traffic running at 8–15% average CPU utilization
- GP2 EBS volumes that haven't been migrated to GP3, paying 20–30% more per GB
- Data transfer costs nobody modeled because on-premises data transfer was free
- Reserved Instance coverage at 20–30% when it should be 60–70% for stable workloads
- Logging and monitoring pipelines shipping 10x more data than anyone actually reads
I've seen organizations spend 40% more in year one of cloud than they spent on the equivalent on-premises infrastructure. Almost all of that gap is recoverable — but only if you go looking for it.
The FinOps Failure Mode
Most organizations treat cloud cost optimization as a cleanup job — something you do after the migration is done and the dust has settled. That's exactly backwards.
Cost structure decisions get baked in at migration time. If the team migrating your Oracle database to RDS doesn't know to evaluate Reserved Instances on day one, you'll spend twelve months at on-demand pricing before anyone notices. If the team migrating your file servers doesn't know about S3 Intelligent-Tiering, you'll pay S3 Standard pricing for data that gets accessed twice a year.
The fix is to embed FinOps thinking into the migration runbook itself. Every workload migration should include: a right-sizing recommendation, a compute purchasing strategy (on-demand vs. Reserved vs. Savings Plans), a storage class recommendation, and a data transfer cost estimate.
This adds maybe four hours of work per workload. It recovers tens of thousands of dollars per year for medium-sized deployments.
The Tagging Problem Nobody Fixes
You cannot optimize what you cannot attribute. And the number one reason enterprises can't attribute cloud spend is that their tagging strategy is incomplete, inconsistent, or simply absent.
I've walked into accounts where 60% of spend had no cost center tag. Finance had no way to chargeback to the business units consuming the resources. Engineering had no way to know which teams were running which workloads. Leadership had no way to evaluate cloud ROI by product or initiative.
Tagging policies need to be enforced at account level, not requested in a wiki doc. AWS Service Control Policies can prevent resource creation without required tags. AWS Config can flag non-compliant resources. Neither is complicated to implement — they just require someone to make it a priority before the migration, not eighteen months after.
What a Real Optimization Looks Like
I ran a FinOps engagement for a financial services client who had completed a lift-and-shift of roughly 400 workloads over eighteen months. Their annual AWS spend was $14M. Within ninety days we had identified and implemented $3.2M in annualized savings — a 23% reduction — without touching any application code.
The breakdown: $1.4M from Compute Savings Plans and Reserved Instance purchases for stable workloads. $800K from right-sizing EC2 instances using CloudWatch utilization data. $600K from GP2-to-GP3 EBS migrations. $400K from S3 lifecycle policies moving cold data to cheaper storage tiers.
None of this was exotic. All of it was available on day one of the migration. The gap was that nobody owned cloud cost as a business outcome — it was treated as an engineering concern, not a financial one.
The Organizational Fix
FinOps is not a tool. It's not a dashboard. It's a practice that requires a cross-functional team with representatives from finance, engineering, and product who meet regularly, own the numbers, and have authority to change things.
The organizations that get cloud economics right are the ones where someone — usually a principal engineer or a cloud financial analyst — has "reduce cloud waste" in their OKRs and the organizational access to act on it. Everything else is theater.
If you're planning a migration and haven't yet had a conversation about tagging strategy, Reserved Instance coverage targets, and right-sizing methodology, have that conversation before you write the first migration runbook. Your future self — and your CFO — will thank you.
