Cloud Migration TCO: On-Prem vs Azure, AWS & GCP
Every migration is approved on a business case and then quietly judged on the first cloud bill. The gap between the two is almost always a TCO model that compared the wrong things. Here is how to build one that survives contact with reality.
The on-prem costs teams forget
The instinct is to compare a server’s purchase price to a cloud VM’s monthly rate. That comparison is rigged against the cloud, because it ignores everything the datacenter quietly absorbs. A fair on-prem run-rate includes:
- Hardware amortization (servers, storage, network gear) over its real life.
- The hypervisor and OS licensing — the line that got a lot bigger recently.
- Power, cooling, rack space, and the datacenter lease or facility cost.
- Over-provisioning: you bought for peak plus headroom and run at a fraction of it.
- The people: patching, hardware replacement, capacity planning, on-call for the metal.
- DR: the second set of everything you keep for failover.
The cloud costs teams underestimate
Then the mirror image — the cloud costs that surprise people three months in:
- Egress — data leaving the cloud is metered; chatty hybrid links add up.
- Storage tiers and IOPS — premium disk and provisioned throughput are not the default cheap tier.
- Lift-and-shift over-sizing — mapping an idle 16-core VM 1:1 carries the waste into a place that charges for it.
- Always-on non-prod — dev/test that never sleeps because nobody wired up a schedule.
- Support plans, backup storage, and inter-AZ traffic.
Compare designs, not servers
The honest comparison is current on-prem run-rate vs the projected cost of the target design — and the target design matters enormously. A workload that replatformsits database to a managed service and right-sizes its compute can be dramatically cheaper than the same workload rehosted 1:1. That means you can’t cost a migration from the inventory alone; you have to cost the design.
See the number while you design
This is why cost estimation belongs on the canvas, not in a separate spreadsheet you update weekly. As you build the target architecture in CloudForge, it estimates the monthly cost of each resource in place — so an over-provisioned instance or a premium storage tier shows its price before it ships, and you can try a cheaper shape and see the delta immediately. Pair that projected cloud cost with your honest on-prem run-rate and you have a defensible TCO per workload, not a hopeful average.
Model the migration cost too
One-time costs are real: dual-running during cutover (you pay for both for a while), data transfer, refactoring effort, and training. Amortize them across the payback period. A migration that’s cheaper on run-rate but takes 18 months to pay back its one-time cost is a different decision than one that pays back in four — say so in the business case.
Keep the model honest after you land
TCO isn’t a one-time gate; it drifts. After migrating, keep comparing the design’s estimate against the target you deployed, and use drift detection to catch the un-costed resources that appear when someone clicks around a console. The teams that stay on budget are the ones whose cost model lives next to their architecture, not in a finance folder.
Costing sits inside the larger flow — see the full migration playbook for where it fits.