The idea in one paragraph
Total cost of ownership, often shortened to TCO, is an estimate of everything it costs to acquire, run and eventually leave a system over a defined period. The reason to calculate it is simple: the price in a quote usually covers only part of the story. Two options with different licence fees can have quite different overall costs once setup, integration, training, support and staff time are included.
TCO is an estimate, not a measurement. Its value lies in making assumptions visible and comparable, not in producing a precise figure.
Cost categories beyond the licence
It helps to think in groups.
Acquisition and setup (usually one-off)
- implementation and configuration work
- moving existing information in, which is the effort covered under data migration
- connecting the tool to other systems
- hardware or hosting changes, where relevant
- project management and your own staff time during setup
People and adoption
- training for users and administrators
- reduced productivity while people learn
- communication and support during the change
Running costs (recurring)
- licences or subscriptions, including any tier changes as usage grows
- support plans and add-ons
- hosting, storage and usage charges
- administration: someone must manage users, settings and updates
- maintenance of integrations and customizations
- upgrades and testing after vendor changes
Risk and exit
- security and compliance work
- downtime or business disruption
- the cost of eventually moving away, including exporting data and running the old and new tools side by side
Staff time is the item most often left out, because it does not arrive as an invoice. It is still a real cost, and often a large one.
A simple hypothetical example
The numbers below are invented to illustrate the method. They do not represent typical prices. Imagine a team of 20 users comparing two options over three years (36 months), with internal staff time valued at 40 per hour.
Option A (higher licence fee, simpler to run)
- Licences: 20 users x 30 per month x 36 months = 21,600
- Implementation: 8,000
- Training: 2,000
- Integration work: 5,000
- Data migration: 3,000
- Administration: 5 hours per month x 36 months = 180 hours, x 40 = 7,200
- Total: 46,800
Option B (lower licence fee, more effort to run)
- Licences: 20 users x 22 per month x 36 months = 15,840
- Implementation: 8,000
- Training: 2,000
- Integration work: 12,000
- Data migration: 3,000
- Administration: 10 hours per month x 36 months = 360 hours, x 40 = 14,400
- Total: 55,240
Option B has licences that are 5,760 cheaper (21,600 minus 15,840), but it is about 8,440 more expensive overall (55,240 minus 46,800). In Option A, licences are 21,600 of 46,800, which is under half of the total. In other words, the licence is only part of what the organization pays.
The same method could easily produce the opposite result with different assumptions, for example if Option B needed little integration. That is why the assumptions matter more than the answer.
How to build an estimate
- Pick a period. Three to five years is common. Use the same period for every option.
- List the categories above and add any specific to your situation.
- Gather quotes and ask vendors what is not included. Questions to raise are suggested under vendor due diligence.
- Estimate internal time honestly. Ask the people who will do the work, and include the time of those who will be trained.
- Record assumptions next to each number, such as expected user growth.
- Add a contingency for items you cannot yet size, and say how much and why.
- Test the sensitivity. Vary the big assumptions to see whether the ranking changes.
Common mistakes
- Comparing first-year costs only, when the cost patterns differ after year one.
- Ignoring growth. Per-user or usage-based pricing can change the picture as the organization grows.
- Counting software but not process change, even though changing how people work often costs more than the product.
- Assuming integration is free because a connector is advertised.
- Forgetting the cost of leaving, which relates to vendor lock-in.
- Treating cost as the only criterion. TCO shows what an option costs, not what it delivers. Pair it with a view of benefits and use it alongside a weighted scoring matrix.
Build, buy or configure
TCO is especially useful when comparing routes, since custom development, packaged products and configuring existing tools have different shapes of cost. Custom work front-loads expense and then carries maintenance for years, while subscriptions spread cost evenly. A fair build versus buy comparison needs both on the same time horizon.
Keeping the estimate honest
Review the estimate after purchase against what actually happened. Differences teach you where your assumptions were optimistic and improve the next estimate. Present TCO figures as ranges where uncertainty is high, and avoid implying that a number to the last unit is reliable. Any figure here is an illustration only; for financial decisions of significance, involve your finance team or a qualified adviser.