Every cloud migration starts with a business case. Compute costs will drop. You’ll stop paying for underutilized hardware. The capital expense becomes an operational expense. The numbers look good in a spreadsheet.
Then the bill arrives.
This isn’t a post arguing that cloud migration is a bad idea. For most organizations, moving to the cloud is the right call. But the gap between projected and actual costs is wide enough that it’s worth being honest about what the estimates usually miss.
The Lift-and-Shift Tax#
The cheapest migration, on paper, is lift-and-shift: take what you have, move it to the cloud unchanged, and optimize later. In practice, this often produces cloud infrastructure that costs more than the on-premise equivalent it replaced.
On-premise hardware is sized for peak load and then sits idle. In the cloud, you pay for what you run — which means that a server that’s at 15% utilization in your data center will cost you 85% more per unit of work in the cloud unless you right-size it. Lift-and-shift migrations frequently inherit the same oversizing patterns without the fixed-cost protection.
“Optimize later” is a plan that often doesn’t happen. Once services are running in the cloud and teams have moved on, the political will to re-architect for efficiency rarely materializes.
Data Transfer Costs#
Cloud providers charge for data leaving their network. This is called egress, and it surprises almost every organization that hasn’t budgeted for it.
The pattern is always the same: data going in is free or cheap, data coming out is not. For workloads that move significant amounts of data — analytics pipelines, content delivery, backup and restore workflows, applications with high-traffic APIs — egress can represent a substantial fraction of the total cloud bill.
This cost is particularly acute for organizations that run hybrid architectures, where data moves regularly between on-premise and cloud environments. Budget for it explicitly, and factor it into the architectural decisions about where data lives and how it moves.
The Operations Gap#
On-premise infrastructure comes with a staff that knows how to run it. They know which servers have had hardware issues, how the network is laid out, what the change management process looks like, and where the runbooks are.
Cloud infrastructure requires a different skill set. The tooling is different, the failure modes are different, and the operational patterns are different. Organizations that migrate without investing in training and hiring often find that their existing operations team is underwater, leading to incidents, slower deployments, and remediation costs.
This isn’t a reason to delay migration — it’s a reason to plan for the transition. Budget for training. Hire people with cloud experience before you need them. Accept that productivity will dip during the transition period.
Unused Resources#
Cloud resources are easy to create and easy to forget. Development environments spin up and never get torn down. Experiments run and the infrastructure persists. Snapshots accumulate. Reserved capacity goes unused after projects end.
In a data center, unused hardware is visible and occupies physical space. In the cloud, it’s invisible until you look at your bill. Organizations without good resource governance practices typically find 20-30% of their cloud spend going to resources that serve no current purpose.
The solution is governance infrastructure: tagging requirements, automated cleanup of old resources, regular cost reviews, and alerts for spending anomalies. This costs something to build and maintain, but it costs less than the waste it prevents.
Reserved Capacity Commitments#
Cloud providers offer significant discounts — often 30-60% — in exchange for committing to use a certain amount of compute for one to three years. These commitments are worth taking in stable parts of your infrastructure, but they introduce a new category of hidden cost: commitment waste.
If your workload shrinks, or you migrate to a different instance type, or a service gets deprecated, you may end up paying for reserved capacity you can’t use. The discount that looked attractive becomes a liability.
The mitigation is to commit conservatively, for shorter terms, and only for workloads you’re confident will remain stable. Cover your baseline with reservations and let variable workloads run on-demand.
The True Cost of Migration Projects#
The migration itself costs money. Engineering time to re-architect applications, build automation, test in new environments, and manage the cutover is significant. So is running parallel environments during the transition period, when you’re paying for both old and new infrastructure simultaneously.
These costs are often underestimated in initial migration business cases because they’re hard to forecast. A reasonable heuristic: double whatever the engineering estimate is, and assume you’ll run in parallel for longer than planned.
Getting the Numbers Right#
None of this means cloud migration doesn’t pencil out — it usually does. But the analysis needs to be honest.
A realistic cloud migration budget includes:
- Infrastructure costs, sized accurately for your actual workload
- Egress costs, estimated based on data movement patterns
- Reserved capacity strategy, with realistic assumptions about commitment risk
- Governance tooling and ongoing cost management
- Training and hiring to close the skills gap
- Migration project costs, including parallel running periods
Build the full picture before committing. Surprises in cloud bills are manageable when they’re expected and sized; they’re a crisis when they’re not.
The organizations that get cloud economics right treat the cloud as a different kind of infrastructure that requires different financial modeling — not as a data center with a pay-as-you-go billing model.