Total Cost of Ownership
The purchase price is the smallest part of what a technology costs over its lifetime.
To an executive
The purchase price is only a small part of what a technology costs. People's time, upgrades and the eventual cost of leaving usually make up most of the bill.
To an engineer
Cost a choice over five years, including operations, integration, upgrades and exit. Count the team's time spent running it, and what else they could have built.
The idea
Total cost of ownership (TCO) counts everything a technology costs over its life: acquisition, integration, operation, training, support, upgrades, security, compliance and, eventually, exit. The ongoing costs usually dwarf the upfront ones.
Hidden costs concentrate in people's time: the platform team maintaining a self-hosted cluster, the specialists needed to customise a package, the upgrade project every few years, and the integration work every time a neighbouring system changes.
Why it works
It compares options on the same basis. A cheap licence with heavy operations and a pricier managed service can only be compared once both are expressed as lifetime cost.
It puts people's time on the bill. Engineering time spent operating something is time not spent on what differentiates the business.
It forces the exit question early. Counting the cost of leaving, before signing, changes how contracts and data formats are negotiated.
Where it applies
- Vendor selection and contract renewals, comparing packages, SaaS and managed services over the contract term and beyond.
- Build, buy or partner decisions, where an in-house build rarely includes its full running cost.
- Application portfolio reviews, finding systems whose running cost has outgrown their value.
- Cloud migration business cases, where the comparison must include operations, skills and exit, not just hosting.
How to apply
- Choose a horizon, typically three to five years, longer for core systems.
- List every cost category: acquisition, integration, operations, people, training, upgrades, security, compliance and exit.
- Estimate people's time explicitly, including on-call, upgrades and specialist skills.
- Compare options on the same horizon, and show the assumptions behind each number.
- Revisit at renewal, using actual costs to correct the original estimate.
Example scenario
Self-hosting an open-source search cluster looked free next to a managed service, and the business case nearly approved it on licence cost alone.
The architect added the hidden lines: several engineers' part-time operations work, the on-call burden, and a major upgrade project every couple of years. Over five years, the self-hosted option cost well over twice as much as the managed one. The team chose the managed service and kept its engineers on product work.
Questions to ask
- What does this cost over five years, including people's time?
- What would it cost us to leave, and when would we find out?
- What else could the team do with the time spent operating it?
When not to use it
- Small, short-lived or easily replaced tools, where a full lifetime analysis costs more than a wrong choice.
- Strategic choices driven by differentiation, where the cheapest option is not the goal; TCO informs the decision but should not make it alone.
How it misleads you
Spreadsheets that look precise but leave out hard-to-quantify costs such as cognitive load, vendor risk or lost flexibility. A tidy five-year number can also hide wildly uncertain assumptions; show the ranges, not just the total.
In the wild
Further reading
Last reviewed · Suggest an improvement