Almost every cloud migration we audit landed over budget. The number we hear from clients is 30–60% above projection in the first year, recovering toward parity in years 2–3 with disciplined FinOps. The reason isn't usually mistakes during execution. It's architectural decisions made at lift-and-shift time, before anyone modeled what the cost shape would actually look like in production.
The cost-shape variables
- Compute architecture (instance size + autoscaling response shape)
- Storage architecture (hot vs warm vs cold tier ratios under real access patterns)
- Egress / inter-region data transfer (often invisible in TCO calculators)
- Reserved Instance / Savings Plan strategy (which can swing 30–50%)
- Managed-service uplift vs DIY operational cost
- Observability cost (Datadog, New Relic, etc. scale with metrics volume)
Why lift-and-shift produces the worst cost shape
Lift-and-shift preserves your on-prem architectural assumptions in a different cost regime. On-prem, idle capacity is free; in the cloud, idle capacity is meter-on. On-prem, intra-DC bandwidth is free; in the cloud, cross-AZ traffic costs $0.01 per GB. On-prem, you sized for peak; in the cloud, sizing for peak with no autoscaling burns most of your savings on idle compute. Lift-and-shift gets you cloud-hosted but not cloud-native economics.
What we model in discovery
Six things, in writing, before any workload moves: workload load profile (peak, sustained, idle); architectural disposition (lift / replatform / rearchitect); RI / SP commit envelope (typically 60–80% of baseline); egress estimate (intra-cloud, cross-region, internet); managed-service uplift (where managed services replace operational labor); observability cost projection (often 5–12% of cloud bill at scale).