An Honest On-Premise vs Cloud TCO Model, Hidden Costs Included

Nearly every on-premise versus cloud cost comparison you have seen leans one way, and usually not because anyone cheated. The more common cause is that each side counts carefully the costs it lives with and skips the ones outside its remit. The infrastructure team counts server list price and forgets power and on-call time; the cloud team counts hourly compute and forgets egress and support plans.

This article does not conclude which side is cheaper, because the answer depends entirely on your workload profile, your real utilisation and your capital structure. What it gives you is an algebraic framework you can fill with your own figures and produce a comparison your finance team will accept.

Principle: normalise the unit before comparing anything

The foundational mistake is comparing the total cost of two things that are not equivalent. Before adding a single number, fix three things:

• The unit of work. It might be a business transaction, a thousand requests, an active customer account, or a terabyte served. Everything resolves to cost per unit of work per month.
• The time horizon. Use exactly one hardware refresh cycle, typically three to five years. Comparing one year of cloud spend against a five-year server purchase is meaningless.
• The service level. Both options must target the same availability, recovery time and acceptable data loss. If the on-premise option has no secondary site while the cloud option replicates across zones, most of the cost gap comes from service level, not from the delivery model.

Notation used here: N is units of work per month, T is months in the analysis window, r is your annual cost of capital, and U is average utilisation of self-run infrastructure as a percentage of purchased capacity.

One organisational point before the numbers. This model should not be built by the infrastructure team alone, and not by a vendor alone either. Finance owns r, depreciation policy and the fully loaded hourly cost of staff. The business owns the definition and the forecast of N. Engineering owns utilisation data and the architecture assumptions. If any of those three is missing from the room, the model will be challenged on exactly the input that party would have supplied, and the decision slips another quarter.

On-premise: the costs usually left out

Equipment purchase price is almost always the smaller part of the total. These are the lines internal estimates tend to miss:

• Facility. Machine room floor space or colocation rack fees, plus the opportunity cost of the space if the room sits inside an office.
• Power. Not only the draw of the equipment but the facility’s power usage effectiveness, since every unit of power to the machines drags along a share for cooling and losses.
• Cooling. Precision cooling units, scheduled maintenance, and replacement at end of life.
• Backup power. UPS units, batteries replaced on a cycle, generators and fuel, plus the load tests.
• Network. Primary and secondary transit, switches, firewalls, load balancers, and the annual licence renewals those devices carry.
• Spares. Disks, power supplies and memory modules held in inventory. Capital sitting idle there is a real cost.
• Support contracts. Annual maintenance for hardware, operating systems, virtualisation, backup and monitoring. These typically rise as equipment ages.
• Staff time. Patching, replacing failed parts, out-of-hours incidents, audit preparation. Record it as hours multiplied by fully loaded hourly cost, not base salary.
• Refresh cycle. Replacing the platform after three to five years, plus data migration and project time.
• Capital tied up. Money spent is money unavailable elsewhere. For an investment C over T months, the opportunity cost approximates to C times r times T divided by twelve.
• Over-provisioning. Self-run infrastructure must be bought for peak. If U is only thirty percent, real cost per unit of work is more than three times the cost per nominal unit of capacity.
• Decommissioning. Secure data destruction, removal, and electronic waste disposal.

Cloud: the costs usually left out

Cloud pricing is public, but the actual invoice carries lines the original estimate did not:

• Egress. Usually the biggest surprise, particularly for content-serving systems or anything synchronising with external parties.
• Inter-AZ and cross-region traffic. A chatty multi-tier architecture can generate more internal traffic than user-facing traffic.
• Snapshots and backups. Overly long retention is the most common reason storage cost climbs steadily without anyone noticing.
• Support plans. Typically priced as a percentage of spend, so they scale with the system rather than staying fixed.
• Licence model changes. Some commercial software is priced differently on shared infrastructure, or requires dedicated hosts. Omitting this can invalidate the whole model.
• Managed service premiums. Managed databases, queues and similar generally cost more than self-running them on virtual machines, in exchange for reduced staff time. Record both directions.
• Orphaned resources. Unattached volumes, reserved addresses, test environments nobody switches off.
• Logging and observability. Ingestion and retention cost scales with traffic, often faster than the compute it observes.
• Traffic-processing network components. Address translation gateways, load balancers and similar bill on data processed.
• Minimum commitments. Long-term agreements lower unit price but lock you to a consumption level; if load falls, the commitment is still payable.

And one thing worth saying plainly: unoptimised cloud is expensive. That is not a defect of the model, it is what happens when peak-sized buying habits are carried into an environment that bills by consumption.

The algebraic framework

The table lists cost groups and how each resolves to the normalised unit. You fill in the last column with your own numbers.

Group	On-premise	Cloud	Normalisation
Compute	Monthly depreciation divided by U	Compute spend after commitments	Divide by N
Storage	Disk depreciation plus spares	Capacity plus snapshots plus backups	Divide by N
Network and transfer	Transit plus network hardware	Egress plus internal traffic	Divide by N
Facility	Space, power, cooling, backup power	Included in unit price	Divide by N
Staff and support	Hours at fully loaded cost	Support plan plus remaining hours	Divide by N
Licensing	Per core or per socket licences	Cloud licensing model	Divide by N
Cost of capital	C times r times T divided by twelve	Close to zero	Divide by N and T
Refresh and exit	End-of-cycle replacement	Data transfer cost on exit	Divide by N and T

Three mistakes that break any model

1. Comparing nominal capacity instead of used capacity. Without dividing by U, the self-run side will always look cheaper than it is.
2. Ignoring the time value of money. One large payment in month one and a stream of monthly charges are not equivalent even when the totals match.
3. Assuming the architecture stays the same. Lifting a system unchanged into cloud and concluding cloud is expensive is a conclusion about the migration approach, not about cloud.

Optimise before you conclude

If the model says cloud is more expensive, check the basics before taking that to a meeting: rightsize instances against real utilisation data, apply commitments to the baseline load, tier storage by access frequency, set lifecycle policies on snapshots and logs, shut down development environments outside working hours, and autoscale the variable portion. The equivalent discipline on the self-run side is measuring real cluster utilisation before buying more capacity, and consolidating underused clusters before signing another support renewal.

Optimisation is not a one-off exercise either, and the model should reflect that. Rightsizing decays as workloads change, commitments expire, and storage accumulates. Budget a recurring share of engineering time for cost review and include that time in the cloud column, otherwise the model quietly assumes an optimised state that nobody is paid to maintain.

Presenting the result to leadership

Do not present a single number. Present a range, with a sensitivity analysis on the three variables that matter most, usually growth in N, utilisation U, and data transfer volume. Show three scenarios: load falls, load holds, load doubles. A model showing option A wins in two of three scenarios is persuasive; a figure quoted to the nearest unit is not.

How HiTechCloud can help

HiTechCloud is an AWS partner and a Google Premier Partner and operates in-country infrastructure, so we work across self-run, cloud and hybrid models. We can help collect real utilisation data, build the TCO model on your own variables, review hidden costs on both sides, and identify optimisation steps to take before the decision is made.