Cloud vs On-Premise TCO: What It Actually Costs

Almost every cloud versus on-premise cost comparison I have been handed over the last decade arrived with the conclusion already written. Sometimes it came from a software vendor whose subscription model depends on the cloud answer. Sometimes it came from an infrastructure team whose budget, headcount and professional identity depend on the on-premise answer. Occasionally it came from an internal finance model that was genuinely neutral and simply missing half the cost lines. The comparison itself is not hard arithmetic. What makes it hard is that the two models have different cost shapes, the horizon you choose silently decides the winner, and several of the biggest lines are the ones nobody remembers to include.

The message up front: there is no general answer to whether cloud or on-premise costs less, and any article that gives you one is selling something. What there is, is a method. Define the capability, define the period, enumerate every cost line on both sides including the forgotten ones, model the timing rather than only the total, find the crossover year, and write down every assumption so somebody can argue with it. The output is a range with stated assumptions, not a number.

1. What total cost of ownership actually means

Total cost of ownership is the full cost of owning a capability for a defined period, counting everything you spend to acquire it, run it, support it, keep it compliant and eventually leave it. That definition carries two words people skip over: capability and period.

Capability matters because a TCO comparison is only valid between two things that deliver the same outcome. If the on-premise option has no disaster recovery site and the cloud option includes resilience as standard, you are not comparing like with like. You are comparing a cheaper thing to a better thing and declaring the cheaper thing cheaper. Either add the cost of building that capability on-premise, or state plainly in the model that the two options differ in what they deliver.

Period matters because the period you pick frequently determines the winner before you have added a single number. That is not a subtle effect at the margin. It is the dominant variable in most comparisons I have seen, and it is almost always chosen without discussion, usually inherited from whatever a previous business case used.

Three things get confused with TCO regularly enough to be worth separating:

• Purchase price is what appears on the quote. It is a single line in a TCO model and often a minority of it. A licence cost comparison is not a TCO comparison.
• Annual run cost is what the system costs you in a steady-state year once it is live. Useful, but it deliberately excludes the implementation, the refresh and the exit, which is where the two models diverge most.
• The business case is a different document. TCO is cost only. A business case weighs that cost against benefit, risk and the alternatives, including doing nothing. TCO is an input to a business case, not a substitute for one. If you need the benefit side of the equation, the CAFM business case and ROI framework covers how to build it, and measuring automation ROI honestly covers the discipline of not inflating the benefit half.

2. Why the comparison is genuinely hard

The difficulty is not that one model is expensive and the other is cheap. It is that the two have different cost shapes, and shapes are harder to compare than totals.

On-premise is lumpy. A large outlay at the start, a long flat stretch where the running cost is comparatively modest, then another large outlay when the hardware reaches end of life, and periodic project-sized spikes for version upgrades. Cloud is smooth. A subscription that starts the month you go live and continues, drifting upward with user count, data volume and whatever the renewal negotiation produces.

Comparing a lumpy series to a smooth one by adding each up and seeing which total is lower throws away the information that matters most. Two options with identical totals over seven years can have completely different consequences for cash, for the balance sheet and for the budget cycle you actually have to survive.

There is also an organisational fact that purely financial models miss. Capital expenditure and operating expenditure are typically approved by different people under different rules on different timetables. A capital request may compete against building works and vehicles in an annual cycle with a hard ceiling. An operating subscription may sit inside a departmental budget that renews without the same scrutiny. The practical result is that the easier money to get is frequently not the cheaper money.

3. The cost components, both sides, including the forgotten ones

This is the structural core of any honest comparison. Work the list, line by line, and say for each one whether it applies, who carries it and what you are assuming. Lines you deliberately exclude should be written down as excluded, with a reason. An omission you recorded is a decision. An omission you forgot is a defect.

The database licence deserves its own sentence because it causes more TCO surprises than any other line. On a self-hosted enterprise application the database can be a substantial cost in its own right, licensed on a basis that has nothing to do with how many people use the application, and it frequently arrives late in the process from a different vendor than the application. If your on-premise column does not have a database line with a named licensing basis next to it, the model is not finished. The same discipline applies to reading the terms themselves: see how to read an enterprise software licensing agreement for the clauses that turn into costs later.

4. The lines that decide it, and that nobody models

Most of the enumerated list above is mechanical. A handful of lines carry almost all of the uncertainty, and they are the ones worth spending your modelling effort on.

• Hardware refresh timing. Whether the refresh falls inside or outside your horizon can change the result entirely, and the same estate bought in year one versus inherited in year four produces two completely different comparisons. If you are mid-way through the life of existing hardware, the on-premise option is being subsidised by a decision somebody already paid for, and the model should say so.
• Internal staff time. The infrastructure team will tell you the system takes a fraction of a person to run. The cloud advocate will tell you it takes most of one. Both are guessing. The only honest approach is to put a stated assumption in the model, show what happens if it is wrong in either direction, and resist the temptation to set it to whatever makes your preferred option win. Note also that cloud does not take this line to zero: somebody still administers users, configures, tests releases and manages the vendor relationship.
• Data growth and egress. Consumption-based pricing grows with the data you keep and the data you move. A model that holds storage flat across seven years is modelling an organisation that never accumulates records, which is not an organisation. Egress in particular is the line that surprises people who move large volumes between the platform and systems that stayed on-premise.
• Non-production environments. On-premise, a test environment is often spare capacity on hardware you already bought. In a subscription model it can be a priced item, sometimes at a meaningful proportion of production. If you need development, test and training copies, price them explicitly rather than assuming they come along.
• Upgrades. On-premise, a major version upgrade is a project with testing, downtime and rework of anything customised. In a cloud subscription, upgrades are typically included and continuous, which removes the project cost but transfers the schedule to the vendor and imposes a regression-testing cadence you do not control. Both are real costs, in different currencies.
• Capability you do not have today. The commonest distortion in these models is comparing a cloud option that includes proper resilience against an on-premise status quo that has none, without pricing the gap. If the current arrangement would not survive a site failure, the honest comparison adds what fixing that would cost, or states clearly that one option buys a capability the other does not.

5. Time horizon: the variable that quietly picks the winner

Run the same cost lines over three, five and seven years and the shape of the answer changes without a single input changing.

Over a short horizon, cloud tends to look favourable, because there is no capital outlay to absorb and the implementation is usually the dominant one-off cost on both sides. Over a long horizon, on-premise can look favourable, because the capital asset is depreciated and the remaining spend is support and staff. That is the standard framing, and it comes with a condition that is nearly always omitted.

On-premise only looks better later if you do not refresh the hardware. A seven-year model that carries the same servers from year one to year seven with no replacement, no extended-support premium and no risk cost is not a conservative model, it is a wrong one. Hardware ages out of vendor support, firmware stops being patched, and the operating system or database version it runs eventually falls out of support too, which is its own forced project. A long-horizon on-premise model without a refresh line is the most common way these comparisons get rigged, and it is usually done by accident rather than design.

Choose the horizon deliberately, state why, and run at least two. If the answer flips between them, that is the single most useful finding in your analysis and it belongs at the top of the paper, not in an appendix.

6. An illustrative model, carried across three horizons

What follows is a hypothetical comparison for a mid-size deployment. Every figure below is invented for the purpose of showing the shape of the two curves. They are not benchmarks, not quotes, not derived from any real engagement and not representative of any product. I have deliberately used round numbers in abstract "cost units" rather than a currency, so that nobody can mistake them for pricing. Use the structure, discard the numbers, and put your own quoted figures in.

Stated assumptions for the illustration: a single enterprise application, a few hundred named users across two sites; implementation effort assumed broadly similar on both sides; the on-premise option buys new hardware in year one and refreshes it in year five; the on-premise option includes a standby capability and backup target; the cloud option is a per-user subscription with one non-production environment and modest annual growth in data volume; internal administration assumed at a fixed fraction of a role on cloud and a larger fraction on-premise; one major on-premise upgrade project assumed in year four; no exit cost included in either column.

Read the shape rather than the totals. The on-premise column is spiky, with two large years and a long flat stretch. The cloud column is smooth and rising. Over the illustrated seven years the two converge and would plausibly cross somewhere beyond it, which is exactly the point: the answer in this made-up case is "it depends on how long you intend to run it, and whether you refresh".

Now notice what moves it. Push the refresh from year five to year eight and the on-premise column wins comfortably at seven years, which is the trick every on-premise business case plays, legitimately or otherwise. Add a second non-production environment to the cloud column and its annual line rises for every year. Halve the assumed internal staff time on-premise and it wins earlier. None of these are exotic adjustments. They are the ordinary content of a disagreement between two teams, which is why the assumptions deserve more scrutiny than the arithmetic.

7. Break-even: more useful than a total

A single seven-year total answers a question nobody actually asked. The more useful output is the crossover: the point at which the cumulative cost of one option overtakes the other, if it does at all.

Finding it is straightforward once the lines are in place. Build each option as a year-by-year series rather than a lump sum. Accumulate each series. Plot or tabulate the two cumulative totals and look for the year the ordering changes. If your organisation discounts future cash flows, apply the discount rate finance gives you before comparing, because a cost in year seven is not worth the same as a cost in year one and a model that treats them as equal flatters whichever option back-loads its spending.

What the crossover tells you is not "which is cheaper" but "how long you need to intend to keep this before the other option starts to pay". That reframes the decision into a question the business can actually answer. If the crossover sits beyond the point at which you expect the application, the process or the organisation to have changed shape, the long-horizon advantage is theoretical. If there is no crossover inside any plausible horizon, you have a clear answer and you can stop modelling.

8. This is a cost method, not a deployment decision

Cost is one input. The deployment decision also turns on data residency, latency to operational technology, integration patterns, security posture, internal capability and regulatory obligation, and those routinely outweigh the money. A TCO model that comes out marginally in favour of one option should not override a hard residency requirement or an operational-technology constraint that only one model satisfies.

Those questions have their own treatment on this site rather than being re-litigated here. For maintenance systems specifically, cloud-based CMMS versus on-premise works through the four deployment models, upgrade behaviour, integration, operational-technology security and residency. For warehouse systems, where latency to physical equipment changes the calculus, cloud WMS versus on-premise covers the specifics. If the question is what cloud asset management looks like as a category, cloud-based asset management software is the overview.

The practical sequence I would advise: settle the hard constraints first, see which models survive them, and only then build the TCO comparison between the survivors. Costing an option that a residency rule or an integration requirement has already excluded is wasted work, and worse, it puts a number in front of a committee that may then argue for the excluded option on price.

9. Exit and lock-in, on both sides

Neither vendor will model the cost of leaving them, and both are real.

Leaving a cloud service costs you data extraction in a usable format rather than a proprietary one, the egress charges on moving it, the conversion work to make it loadable elsewhere, a period of parallel running, and whatever remains of a contract term you cannot exit early. Where the service holds history you are obliged to retain, you may also need to keep paying for read access after you have stopped using it, or pay to archive it somewhere you control. The relevant contract terms are usually visible before you sign, which is the moment to price them.

Leaving on-premise hardware costs you the migration project itself, secure data destruction and disposal, the residual value you will not recover, any software licences that do not transfer, and often a period of running both estates at once. There is also a quieter cost: ageing hardware that nobody wants to replace tends to acquire workarounds, unsupported versions and institutional nervousness, and the longer the replacement is deferred the more expensive and risky it becomes.

I would include an exit line in both columns even if it is a placeholder with a stated assumption. Its main value is not precision. It is that it forces the conversation about what happens at the end, which otherwise occurs for the first time under pressure. If you are already facing that move, migrating CMMS and EAM to the cloud covers the mechanics: routes, discovery, customisations, cutover and rollback.

10. Which model suits which constraint

Cost rarely decides this alone. The table below is the constraint-first view I would use to narrow the field before modelling, and the right-hand column is the part most comparisons leave out.

11. How to do this for real

The method, in the order I would run it:

• Define the capability precisely, including resilience, recovery expectations, environments and retention. Write it once and hold both options to it.
• Fix the horizon and justify it, then commit to running at least a second one. Three and seven are a reasonable pair because they tend to disagree.
• Get real quotes, for both columns, from the actual vendors, for your actual user count and data volume. A model built on list prices or published rate cards is a sketch, and in enterprise software the gap between list and negotiated can be large enough to invert the conclusion.
• Use the vendor calculators sceptically. The hyperscalers and several application vendors publish their own TCO calculators. They are genuinely useful for enumerating lines you might forget and for pricing specific resource configurations. They are also built by a party with an interest, and their default assumptions about staff time, utilisation and on-premise refresh cycles are where the thumb goes on the scale. Use them for structure, replace their defaults with yours.
• Model your own volumes, not a reference architecture. User count, data growth rate, transaction volume, number of environments and integration count are the inputs that make a model yours.
• Record every assumption in the model itself, next to the number it drives, with the name of whoever provided it. An assumption without an owner cannot be challenged or corrected.
• Run sensitivity on the three or four lines that matter most, which will typically be refresh timing, staff time, data growth and the discount rate. Show the result as a range.
• Publish a range with stated assumptions, not a single number. A single number invites the reader to trust a precision you do not have, and it will be quoted back at you for years.

One practical habit worth adopting: build the model so that a sceptic can change any assumption and watch the answer move. A model that cannot be challenged interactively will be challenged rhetorically instead, and that argument is much harder to win.

12. What TCO does not tell you

A cost model is a narrow instrument, and it is worth being explicit about what sits outside it.

None of that makes the exercise worthless. It makes it one input among several, which is how it should be presented. The worst outcome is a model treated as an oracle, where the decision is deferred to a spreadsheet nobody has interrogated because the number looked authoritative.

It is also worth saying that the costs change under you. Subscription pricing, licensing bases, hardware prices and cloud consumption rates all move, sometimes substantially, and a model built two years ago describes a world that no longer exists. Date the model, note the date each quote was obtained, and rebuild rather than reuse. For an example of a worked multi-year cost model on a narrower subject, what an operational data platform costs applies the same discipline to one specific capability.

The idea to walk away with

Cloud is not automatically cheaper and on-premise is not automatically cheaper. The result turns on a short list of nameable variables: the horizon you choose, whether a hardware refresh falls inside it, how much internal staff time you assume, how fast your data grows, how many environments you need, and whether you have priced the capability gap and the exit on both sides. Change any one of those and the answer can invert, which is precisely why so many published comparisons reach confident conclusions: the conclusion was chosen first and the assumptions were set to deliver it.

The defensible output is not a winner. It is a year-by-year model, a crossover point, a stated range, and a visible list of assumptions that anyone in the room is free to challenge. If somebody changes an assumption and the answer flips, you have not failed. You have found the thing the decision actually rests on.

Final thoughts

The most useful thing I can suggest to anyone starting this exercise is to build the cost lines before you form an opinion, and to write the assumptions down as you go rather than reconstructing them afterwards. Reconstructed assumptions have a way of arriving already aligned with the conclusion. Recorded ones keep you honest, and they survive the staff changes that happen between a model being built and the renewal where somebody asks how the original numbers were arrived at.

And when the two columns come out close, as they often do, say so. A result of "these are within the noise of our own assumptions, so decide it on residency, capability and risk instead" is a genuinely valuable finding. It is also, in my experience, a far more common honest outcome than the decisive margin that vendor comparisons tend to produce.

Related reading: Cloud-based CMMS vs on-premise, Cloud WMS vs on-premise, Migrating CMMS and EAM to the cloud, The CAFM business case and ROI, Reading an enterprise software licensing agreement, What an operational data platform costs.