Honest TCO modelling for cloud repatriation — what numbers to actually compare

Most repatriation business cases start with two numbers on one slide: the monthly cloud invoice and a quote for servers. The second is smaller, the slide says “repatriate”, and eighteen months later the finance team asks why the savings never showed up in the accounts.

The problem is not that the numbers are wrong. They answer different questions. The invoice bundles hardware, facilities, managed services and a slice of operations work into one line. The hardware quote covers metal. Comparing them is like comparing a hotel bill with the price of a bed.

This article is about the structure of an honest model — which cost lines belong on each side and which assumptions decide the answer. It deliberately contains no example savings percentage. Any such number depends on your workloads, your discounts and your team, and a percentage borrowed from someone else’s estate is the fastest way to a wrong decision.

Compare one workload, priced twice

The unit of comparison is a workload, not the estate. Take one service — its vCPU and RAM, block and object storage, the managed databases and Kubernetes clusters it uses, its GPUs, its egress and cross-zone traffic — and price it twice: once as it runs today at the rates you actually pay, once as it would run on hardware you control.

That is how the cloud repatriation calculator on this site is built. It prices the footprint against hyperscaler list rates with your commitment and enterprise discounts applied, then against Cozystack on owned or rented hardware including power, PUE, colocation, network and the operations staffing the platform takes. Every rate carries its source and date, and the output is a multi-year saving with a migration payback point rather than a headline percentage. You can disagree with any input; you can see all of them.

Pricing the same workload twice forces you to put the same categories of cost on both sides. Most bad models fail because one side is complete and the other is not.

The cloud side: what the invoice hides

The invoice is the easiest number to get and the easiest to misread. Four lines deserve their own row.

Egress and cross-zone traffic. Data leaving the provider, and data moving between availability zones, is billed by volume. It hides inside service line items and grows with backups, observability pipelines and replication. Pull it out explicitly; it is also the line that changes most when you move.

Commitments. Reserved instances and savings plans lower the unit price only for capacity you actually use. Model the discount you realise, not the one in the contract. Record the expiry dates too: they do not change the total, but they decide when a workload can move without paying for capacity twice. The repatriation playbook covers sequencing around them.

Idle and over-sized resources. Instances that are larger than the load, or that run when nobody uses them, are real spend. They are also spend that cost optimisation can remove without moving anything. Count them honestly: if right-sizing in place closes most of the gap, that is a result, not a failure of the model.

Managed-service premium and the people around it. A managed database or Kubernetes service costs more than the compute under it, but it also removes operations work. Price what replaces it on the destination side — a managed service from the platform catalogue or a database your team runs itself — instead of dropping the line. The same goes for engineering time spent on cloud-specific plumbing: IAM policies, account structure, provider tooling. Some of that time is freed after a move; some is replaced by platform work.

The destination side: the lines that bite in year two

A destination estimate that looks too good usually is missing one of these.

Hardware and its refresh. Purchase price is only the start. If your horizon is five years, ask whether a refresh falls inside it and price it if it does. Size the cluster properly: the TCO calculator methodology shows a sizing chain worth copying — CPU oversubscription of 3:1, a RAM target of 85% utilisation, raw storage equal to usable capacity times the replication factor, and N+1 high-availability headroom with a minimum of 15%. Leave out replication or headroom and the node count comes out too low.

Facilities and network. Power multiplied by PUE, colocation or your own data-centre space, uplinks and bandwidth, and traffic between sites if you run more than one.

Backup and DR. A second copy of the data needs capacity somewhere, and a second site costs a second set of facilities. Price the design you will actually run. Cozystack supports stretched and multi-site layouts and backup and restore with runbooks; it does not provide automated cross-site failover, so budget the operational procedure, not a button.

People. This line is usually guessed. The methodology behind the TCO calculator models it as engineering days per month — a base of 0.25 day per node per month for node operations, scaled by an orchestration factor, plus days for each service the team runs itself, such as 0.75 day per self-run Kubernetes cluster and 0.5 day per self-run production database. These are Ænix field estimates and adjustable, but the shape is the point: operations effort scales with nodes and with what you run by hand, not with VM count. A managed-services catalogue moves work from your team to the platform.

Platform subscription. Cozystack is open source under Apache 2.0, so there is no per-core or per-VM licence. What you pay for is support and commercial modules. The Ænix Public Cloud Platform subscription — the same tiers cover support for self-run Cozystack — starts at $1,250 per 10 nodes per month on annual billing (Basic); the full matrix is on the pricing page. Ænix Private Cloud Platform and Ænix AI Platform are quoted per RFP.

Migration and dual-run. The calculators use an indicative one-time migration figure of $8,000 plus $140 per VM; the final quote follows scoping. During the move you pay for both environments. The TCO calculator does not price this dual-run by default, so add it yourself.

Use the right calculator for the question

Two calculators on this site look relevant, and they answer different questions. The TCO calculator compares on-prem platforms — VMware, Nutanix, OpenShift, Proxmox, OpenStack and others against Cozystack — and excludes hardware and facilities because they are identical on both sides. Its own methodology lists public cloud as out of scope. Using it to justify a cloud exit would leave out exactly the lines that change.

For a cloud exit, use the cloud repatriation calculator for single workloads and the Cloud Repatriation TCO Worksheet for the whole estate. The worksheet walks through current cloud state, destination architecture, per-workload classification, a five-year trajectory with the break-even point, and a stay / partial / full decision.

One habit from the TCO calculator is worth adopting whatever tool you use: its methodology publishes a sanity table that includes the scenarios where Cozystack loses. A model that cannot show you a losing case has not been tested.

Stress the assumptions that move the answer

A single TCO number is a forecast with the uncertainty removed. Run at least three scenarios and watch which inputs swing the result.

Utilisation. Owned hardware costs the same whether it runs busy or half-empty. If your destination cluster settles at a lower steady-state utilisation than you assumed, the cost per workload rises with it.

Growth. Fast growth pulls hardware purchases and refreshes forward; slow growth leaves capacity idle. Both change the cash curve.

Egress volume. Because egress grows with backups, analytics and customer traffic, a forecast error here hits the cloud side harder than any other line.

Discounts. If you can negotiate a better enterprise discount at renewal, rerun the model with it. Repatriation should win against your best realistic cloud price, not against list price.

People. Vary the operations effort. If the case only works when the platform needs almost no engineering time, it does not work.

Report the break-even point and payback for each scenario. A case that pays back in every scenario is strong; one that pays back only in the optimistic one is a negotiation tactic.

Decide per workload

At portfolio level, the answer is often close to neutral, and that average hides the decision. The largest steady-state workloads usually carry the bulk of the cost case. Small services, elastic spike workloads and anything built deep into one provider’s proprietary services often cost more to move than they save.

So classify every workload as repatriate now, repatriate later or stay, and rank by net return and risk. Partial repatriation is a common and valid outcome.

GPU workloads deserve their own row because their economics differ from general compute. Two published case studies show the range. In From public cloud to bare metal, an academic-computing SaaS moved off a hyperscaler onto owned bare metal on Cozystack and found GPUs on a sovereign cloud roughly 5× cheaper than the previous setup, accounting for the prior model’s margin. In 8xH100 inference on your own bare metal, a mobile app moved inference off a per-hour GPU rental and reports 2–3× better GPU efficiency. Both are steady GPU workloads; neither number transfers to a whole estate.

When repatriation does not pay

Be ready for the model to say “stay”. That is the likely answer when workloads are elastic and spiky, when the estate is small and the team is a handful of people, when the architecture depends on hyperscaler-only services, or when nobody will run the destination platform afterwards. In those cases, tune the cloud spend and revisit the model at the next commitment renewal.

Running the model

Start with the worksheet and the cloud repatriation calculator, and fill them in together with finance and platform engineering — each side catches the other’s blind spots. If you want a second opinion with a destination architecture attached, the Platform Readiness Assessment runs the cost workstream at a fixed price over 14 or 28 days and ends with a per-workload ranking. Engagement details are on the cloud repatriation page; the open-source platform itself is documented at cozystack.io, the CNCF Sandbox project Ænix created and co-maintains.