TCO Analysis

What TCO analysis is actually for

A TCO analysis is not primarily a cost-reduction argument. It is a decision-making tool. Its purpose is to make visible all costs — including those that are currently invisible — so that a comparison between the current state and the cloud target state is honest and complete.

The most common mistake in TCO analysis is treating it as a budget exercise: comparing the invoice from the cloud provider against the invoice from the current hosting provider. That comparison is almost always misleading, because it ignores the majority of relevant costs on the on-premises side.

The sixteen cost categories

A complete TCO model covers sixteen categories across four groups.

Direct infrastructure costs include hardware acquisition and depreciation, data centre space (power, cooling, space), network infrastructure, and storage systems. These are the costs most organisations can already see — but even here, the fully loaded cost is often underestimated because hardware refresh cycles are treated as capital expenditure rather than operating cost.

Software and licensing costs include operating system licences, virtualisation licences (VMware, Hyper-V), database licences, monitoring and management tooling, and backup and recovery software. Licensing is often the category where the largest surprises occur in cloud migration projects: licences that were purchased once and amortised over many years appear as a large one-time cost when they must be replaced or renegotiated.

Operations and personnel costs include IT operations staff (system administration, network operations, storage management), on-call costs, and the opportunity cost of skilled staff spending time on infrastructure rather than on business-value work. Personnel costs are typically the largest single category in a complete TCO model — and the one most frequently omitted from cloud business cases.

Compliance and risk costs include security tooling and personnel, compliance audit preparation and execution, insurance, and the cost of maintaining certifications (ISO 27001, BSI IT-Grundschutz). These costs are frequently invisible in the current state because they are distributed across multiple cost centres and headcount — but they are real, and cloud platforms that provide compliance features as a managed service reduce them materially.

The hidden costs

Beyond the sixteen standard categories, there are costs that most TCO analyses miss entirely. Downtime cost — the financial impact of system outages, calculated as revenue at risk per hour multiplied by historical availability figures. Technical debt amortisation — the cost of maintaining increasingly outdated infrastructure that cannot be fully modernised within current budgets. Talent acquisition premium — the cost of recruiting and retaining infrastructure engineers in a market where cloud skills command a premium over legacy infrastructure skills. Shadow IT — the cost of business units buying cloud services outside the official IT budget because official IT is too slow, which creates uncontrolled cloud spend and security gaps.

Building the comparison

The comparison between on-premises and cloud should cover a three-year period, since that is the typical payback horizon for cloud transformation investments. Both the current state and the cloud target state should be modelled on a year-by-year basis, because cloud costs are not constant: they typically decrease as reserved capacity is optimised, as workloads are right-sized, and as FinOps practices mature.

The current state model should include all sixteen cost categories, including the ones that are currently hidden. The cloud target state model should include provider costs (compute, storage, network, managed services), migration investment, staff retraining, and ongoing FinOps operations — but should credit back the infrastructure costs that will be retired.

The migration investment — the one-time cost of the transformation itself — should be presented separately from the ongoing run cost, so that the board can evaluate it as a capital decision distinct from the operational efficiency improvement.