A total cost of ownership model is only useful when both columns carry every real cost. On premises tends to understate refresh cycles, facilities, spare capacity, and the people who keep the lights on. Cloud tends to understate data transfer, idle and overprovisioned resources, premium support, and the savings you only capture if you commit. A fair model puts a multi year horizon on both sides, loads each with its true running cost, and then compares like for like. The output is rarely a clean win for either side. It is usually a map of which workloads belong where, and what each placement costs once nothing is hidden.
The number that decides is not the headline monthly bill. It is the fully loaded annual cost over the asset life of the on premises option, set against the optimized cloud run rate over the same window. Figures below are indicative and the structure matters more than any single rate.
What belongs in an honest TCO model?
Both columns need the same cost categories so the comparison is fair. On the on premises side: hardware purchase amortized over its useful life, the data center or colocation facility, power and cooling, network and bandwidth, storage arrays, software and hypervisor licensing, hardware support contracts, spare capacity held for peak and failure, and the staff time to rack, patch, and operate it. On the cloud side: compute and storage at the rate you will actually pay after commitments, data transfer and egress, load balancers and managed service fees, premium support, backup and disaster recovery, and the platform team that runs the cloud estate. Leave a category out of one column and the model lies. The most common error is comparing a cloud bill against on premises hardware alone, ignoring the facility and people that the hardware needs to run.
Which on premises costs get understated?
On premises looks cheap when the model counts only the server. Refresh is the first omission: hardware is replaced on a three to five year cycle, so a model that amortizes over ten years flatters the owned option. Spare capacity is the second: you buy for peak plus a failure margin, so utilization of forty to sixty percent is normal, which means you pay for idle iron the cloud would let you shed. Facilities are the third: floor space, power, cooling, and physical security are real and rising. People are the fourth and largest hidden line: the engineers who patch firmware, swap failed disks, and carry the pager are a recurring cost that does not appear on a purchase order. Load all four and the owned option is usually more expensive than its sticker suggests, though for very stable, very high utilization workloads it can still win.
Which cloud costs get understated?
Cloud looks cheap when the model uses on demand list rates for a steady workload and forgets the trimmings. Data transfer is the classic surprise: egress and cross zone traffic accumulate quietly and are easy to omit from a forecast. Idle and overprovisioned resources are the second leak, because the elasticity that should save money only does so if someone turns things off and rightsizes them. Commitments are the third factor, but in the other direction: a steady workload at on demand rates overstates the cloud cost, because AWS Savings Plans and Reserved Instances, Azure Reservations and the Azure Savings Plan, GCP Committed Use Discounts, and OCI Universal Credits discount roughly 20 to 72 percent in exchange for utilization risk. Premium support, backup, and the platform team round out the loaded cost. A credible cloud column uses the committed rate for the stable base and on demand only for the variable band.
A worked example: a 200 server estate
Consider an anonymized mid market estate of roughly 200 virtualized servers running a steady production workload. The figures are indicative and verified against anonymized billing data on the cloud side; treat them as a structure to populate with your own numbers, not as a benchmark.
| Cost line | On premises, per year | Cloud, per year |
|---|---|---|
| Compute and hardware refresh | amortized over 4 years, high | committed rate on stable base |
| Facility, power, cooling | material and fixed | included in provider rate |
| Spare and idle capacity | paid for at 40 to 60 percent use | shed if rightsized and scheduled |
| Data transfer and egress | low | can be material if not designed for |
| Software and support licensing | hypervisor and OS contracts | managed service and premium support |
| People to operate | large, often hidden | platform team, smaller per workload |
The pattern that usually emerges: a steady, fully utilized workload narrows the gap and can favor on premises, while a spiky or growing workload favors cloud because you stop paying for peak capacity year round. The decision turns on utilization and growth, not on the cloud being cheap in the abstract.
How do commitments change the cloud side?
Commitments are the single biggest swing factor in the cloud column and the most common reason a model is wrong. Pricing a steady workload at on demand rates overstates cloud cost by the full commitment discount, which can be the difference between a clear cloud win and a clear loss. The honest approach is to size commitments to a defensible forecast: cover the stable base you are confident will run with Savings Plans, Reservations, CUDs, or Universal Credits, and leave the uncertain or shrinking part on demand. Enterprise agreements layer on top, the AWS Enterprise Discount Program, the Azure MACC, GCP enterprise agreements, and Oracle Universal Credits, trading a multi year spend commitment for a deeper tier, with the MACC shortfall clause meaning unspent commitment is still owed. A TCO model that ignores commitments is not comparing the cloud you would actually buy.
Price the on premises column over the real asset life with refresh, facilities, spare capacity, and people included, and price the cloud column at the committed rate for the stable base plus on demand for the variable band. Comparing a loaded owned estate against an unoptimized on demand cloud bill is the error that produces both the false cloud win and the false repatriation case.
What decision should the model produce?
A good TCO model does not produce a verdict that the cloud or the owned estate wins everywhere. It produces a placement map. Steady, high utilization, latency sensitive, or licensing heavy workloads may be cheaper owned or in a hybrid estate. Variable, growing, globally distributed, or fast iterating workloads usually favor cloud once elasticity is actually used. The model should also expose the conditions under which the answer flips, so you can revisit it when utilization, growth, or commitment coverage changes. The point is not to win an argument about cloud versus on premises. It is to place each workload where its fully loaded cost is lowest, and to know the number you would defend in front of finance.
Frequently asked questions
Build a TCO model your board will trust
We build buyer side TCO models that load both columns honestly, price the cloud side at the rate you would actually pay after commitments, and produce a workload placement map rather than a foregone conclusion, as an independent advisory with zero provider commissions. Our guarantee: we reduce your cloud spend or we reimburse our service fee, on a Fixed Fee or no risk Gainshare basis. Read the cross cloud cost optimization guide, see how to build a migration business case that holds, and study the hybrid estate cost model.
Put a defensible number on your cloud spend.
No provider in the room, no published price list. Tell us your footprint and we will scope the savings against your billing data — we reduce your cloud spend or we reimburse our service fee.
The Cloud Spend Navigator: what changed in cloud pricing, commitments, and FinOps — no vendor spin.