"The cloud will save us money" is the assumption most migrations start with, and it's wrong often enough that total cost of ownership analysis has become its own discipline. TCO in cloud computing means pricing the full lifecycle of a cloud decision, not just the invoice, against what the same workload actually costs to run where it is today.
What TCO Actually Means in a Cloud Context
Total cost of ownership is the sum of every cost a workload generates over a defined period, typically three to five years, not just the monthly bill from the provider. For cloud specifically, that means compute and storage charges, but also data egress fees, migration costs, re-architecture work, licensing changes, and the ongoing staff time to manage an environment that behaves very differently from on-premise infrastructure. Comparing only the sticker price of a cloud instance against a server's depreciation schedule is the single most common way a TCO analysis goes wrong before it even starts.
| Category | On-premise / colocation side | Cloud side |
|---|---|---|
| Direct infrastructure | Hardware purchase, depreciation, facility and power costs | Compute, storage, and network charges at current usage |
| One-time transition | N/A if staying put | Migration labor, re-architecture, parallel-run overlap costs |
| Ongoing operations | Internal IT staff, maintenance contracts, hardware refresh cycles | Cloud management tooling, FinOps oversight, egress and support fees |
| Risk and flexibility | Capacity sized for peak, often underutilized | Elastic scaling, but with real cost if usage isn't actively managed |
Where TCO Analysis Usually Goes Wrong
Three mistakes account for most bad cloud decisions built on a TCO analysis that looked solid on paper. The first is comparing list price to list price instead of modeling actual usage patterns, a workload with predictable, steady demand prices very differently in the cloud than one with sharp peaks. The second is ignoring the migration cost itself: re-architecting an application to actually benefit from cloud-native pricing isn't free, and a "lift and shift" that skips this step routinely costs more in the cloud than it did on-premise. The third is modeling year one and stopping there, when the real comparison needs to run three to five years out, since cloud costs tend to creep upward with usage growth in ways a static on-premise cost doesn't.
Building a TCO Model That Holds Up
A credible model starts with the current state: actual infrastructure spend, actual utilization, actual staff time, not estimates. It then prices the cloud alternative at realistic future usage, not today's usage, since growth is exactly where "lift and shift" cost overruns tend to appear. Finally, it separates one-time migration costs from ongoing run costs, so a board or CFO can see payback period and steady-state cost as two different numbers, not one blended guess.
Who Should Own the TCO Analysis
A credible TCO model needs input from Finance (what the current infrastructure actually costs today, including depreciation and facility overhead that IT often doesn't track directly), IT (what the technical migration and re-architecture work actually involves), and whoever owns the vendor relationship (what the real negotiated pricing looks like, not the published rate card). A model built by only one of these functions tends to be wrong in a predictable direction: IT-only models underweight financial detail like depreciation schedules, Finance-only models underweight technical reality like re-architecture effort, and vendor-only models, unsurprisingly, tend to favor whichever platform the vendor sells.
Signals Your Current TCO Model Is Wrong
A few patterns show up reliably in TCO models that don't hold up under scrutiny. If the model compares cloud list price against on-premise cost with no migration or re-architecture line item, it's incomplete by construction. If it models only the first twelve months, it's measuring a cloud bill before usage, and therefore cost, has had time to grow into its natural pattern. And if the model was built entirely by the team recommending the move, without anyone independently checking the assumptions, it's worth a second look regardless of how confident the original analysis sounds.
Buy vs. Build, and Where Market
Benchmarking Fits
A TCO model answers "cloud or on-premise," but it doesn't answer whether the specific cloud pricing on the table is actually competitive. Those are two separate questions, and conflating them is a common mistake. Once the directional decision favors cloud, the model's assumed pricing should be benchmarked against what comparable organizations are actually negotiating, not the provider's list price used to build the original case. A TCO analysis built on list price and never revisited after the actual contract is negotiated is measuring a decision that no longer reflects the deal actually signed.
Frequently Asked Questions
Is cloud always cheaper than on-premise? No. For steady, predictable workloads with already-depreciated hardware, on-premise or colocation can be cheaper. Cloud tends to win on elasticity, disaster recovery, and avoiding capital expenditure, not automatically on raw cost.
How far out should a TCO model project? Three to five years is standard. Shorter windows understate migration costs; longer windows get too speculative about pricing and usage to be reliable.
What's the biggest hidden cost in a cloud TCO model? Data egress fees and the cost of re-architecting applications to actually benefit from cloud-native pricing, both are routinely left out of first-pass estimates.
Should a TCO analysis happen before or after choosing a specific cloud provider? Before, ideally. A TCO model built to validate a decision already made tends to find what it's looking for. A model built before the provider choice is made is more likely to surface a genuinely comparative answer.
What discount rate should a multi-year TCO model use?Most mid-market analyses use the company's standard capital planning rate; the specific number matters less than applying it consistently across both the cloud and on-premise sides of the comparison.
Should sunk costs in existing hardware factor into the decision?Only partially. Already-depreciated hardware with remaining useful life represents a real opportunity cost if retired early, but it shouldn't anchor the decision if the ongoing operating cost comparison clearly favors a change.
Where to Go Next
For the architecture decision behind a cloud strategy, see Hybrid Cloud Infrastructure.. For what outside help with this analysis looks like, see IT Cloud Consulting. For the ongoing cost discipline after migration, see Cloud Cost Optimization & FinOps.
