I am not in the business of talking people out of public cloud. For a large class of workloads it is clearly the right answer, and for a few it is the only sane answer. What I am in the business of is making sure the comparison being presented to a finance committee is an actual comparison.

Three questions do most of the work. All three are about numbers that are usually absent rather than wrong.

1. What is the egress, per month, in reality?

Compute and storage pricing is easy to model and everybody models it. Data transfer out is the line that arrives later and grows.

The trap is that egress does not correlate with your data volume, it correlates with your access pattern. An archive of 200 TB that nobody reads costs almost nothing to hold and almost nothing to move. A 20 TB dataset that a reporting system re-reads from another environment every night is a permanent monthly bill.

So the question is not “how much data do we have” but “how much data crosses the boundary, how often, and in which direction”. Most teams cannot answer this on the spot, which is itself the finding. Instrument it for a month before signing anything.

The related version: what does it cost to leave? Not because you plan to, but because a number you cannot compute is a lock-in you have not priced.

2. What is the utilisation assumption, and does it survive contact with the workload?

The cloud economic case is fundamentally about elasticity. You pay for what you use, so you stop paying for the idle capacity that an owned platform forces you to buy.

This is compelling and true for workloads that are genuinely variable. It is exactly backwards for workloads that run at steady utilisation all day, every day. A database that is busy at 70% for 24 hours has no idle capacity to stop paying for; it just has a meter running.

Look at the estate honestly and sort it. Variable and bursty workloads: strong case. Steady-state production: run the five-year arithmetic, including reserved or committed pricing, and see where it lands. Frequently it lands somewhere that surprises the person who assumed the answer.

The mistake is applying an average conclusion to a bimodal estate. Most estates are bimodal.

3. What does the operating model cost?

This is the one that is genuinely hard, and the one most often left out entirely because it is not on an invoice.

Running infrastructure in a public cloud is not the same job as running it on premises, and it is not obviously less work. You trade hardware lifecycle and facilities for identity architecture, network design, cost governance, tagging discipline, and a permanent ongoing effort to prevent spend from drifting upward. Those are real roles filled by real people.

The organisations that do well have a named function that owns cloud cost and architecture standards. The organisations that are surprised by their bill in year two are the ones who assumed the operating model came with the platform.

Put a number on it. Even a rough one. A comparison that counts the staff cost on one side and not the other is not a comparison.

What I am not saying

I am not making a repatriation argument. Moving workloads back is also expensive, also underestimated, and often driven by one bad bill rather than by analysis.

What I am arguing for is symmetry. Whatever rigour you apply to the on-premises option — refresh cycles, power, floor space, staff, the cost of capital — apply the same rigour to the cloud option. Egress, committed-use discounts, the cost of the platform team, the cost of exit.

When people do that, the answer is very often a split: some workloads clearly go, some clearly stay, and a middle group where the decision is genuinely close and should be made on things other than cost, like where the team’s skills are and where the data has to live for legal reasons.

A split answer feels less decisive and is usually more correct. The single-platform answer is a strategy slide. The split is an architecture.