Cloud repatriation: how to tell whether moving workloads back will actually save money

Somewhere between 2015 and 2022, most Australian organisations were told to move everything to public cloud. A meaningful number are now moving some of it back.

That is what cloud repatriation means, and it is worth being precise about it, because the term gets used to describe two very different things. It is not a rejection of public cloud, and the organisations doing it well are not going backwards. They are correcting a decision that was made once for an entire estate when it should have been made workload by workload.

What cloud repatriation actually means

Cloud repatriation is the movement of workloads out of public cloud and back into private cloud, colocation or on-premises infrastructure. In practice it is almost always partial: a handful of steady, predictable systems come back, while everything elastic, customer-facing or built on managed services stays exactly where it is.

Full exits happen, but they are rare and they are usually a symptom of something other than cost. If someone is proposing to bring an entire estate home, the question to ask is which specific workloads are losing money, and what the number is.

Why it is happening now

Steady-state workloads were never the strongest case for public cloud

Public cloud pricing rewards elasticity. You pay for what you use, which is a saving when what you use varies and a premium when it does not. A production virtual machine running at seventy per cent utilisation, twenty-four hours a day, for four years is the worst case for on-demand pricing and the best case for owned or dedicated infrastructure.

Reserved instances and savings plans narrow that gap. They rarely close it once you add data egress, the support plan percentage, snapshot storage and the internal time spent managing the bill.

The VMware licensing change reopened a decision nobody had made in a decade

Broadcom’s acquisition of VMware moved the product line to subscription bundles and ended perpetual licensing. Renewal quotes went up sharply for a lot of organisations, and for many the hypervisor became a live decision for the first time since they bought it.

That matters here because virtualisation licensing is one of the largest single line items in a private infrastructure estate. If you last costed a private platform in 2021, the maths has moved, in both directions, and the old spreadsheet is no longer a guide.

Sovereignty and audit obligations got sharper

For Australian government agencies, councils, water corporations and regulated enterprises, where the data physically sits is not a preference. It is a control that has to be evidenced. Being able to name the facility, the rack and the person who can walk to it answers a question that a region name on a console does not always answer to an auditor’s satisfaction.

The workloads that usually do cost less off public cloud

• Steady-state production systems. Anything that runs at a consistent load all year and cannot be scaled down overnight.
• Large, stable data sets that get read a lot. Egress charges are the line item that most often turns a modelled saving into an overspend.
• Licence-heavy database workloads. Per-core licensing on a cloud instance can cost more than the compute underneath it.
• Systems with hard, predictable performance requirements. Dedicated hardware gives you IOPS you can guarantee rather than IOPS you can request.
• Anything tethered to a physical site. Building systems, operational technology, plant and depot infrastructure. Latency and dependency both argue for proximity.

The workloads that almost never do

• Development and test environments. They are idle most of the time, which is exactly what on-demand pricing is good at.
• Genuinely spiky, public-facing applications. If load varies by an order of magnitude, elasticity is worth paying for.
• Anything built on managed platform services. A workload sitting on a managed database, queue or identity service is not a migration. It is a rebuild, and the rebuild cost usually exceeds several years of the saving.
• Small estates. Below a certain size there is not enough workload to amortise a platform, and the fixed costs land on too few systems.

How to compare the cost honestly

The most common mistake is comparing a monthly cloud bill against a hardware quote. Those are not the same kind of number, and the comparison always flatters the hardware.

Model both sides over three years, and put everything in.

On the private side: hardware amortised over its real life rather than its warranty; hypervisor, backup and monitoring licensing at current pricing; data centre space, power and cooling, or the colocation equivalent; network links and their redundancy; a disaster recovery position that actually meets your recovery objectives rather than one that assumes nothing fails; and the engineering hours to run it, which is the cost most models leave out entirely.

On the public side: reserved and on-demand pricing at your real utilisation rather than your provisioned capacity; the support plan as a percentage of spend; egress at observed volumes, not estimated ones; backup and snapshot storage; and the internal time spent on cost management.

And in the middle: the migration itself. Moving a workload costs money, consumes your engineers for a quarter, and carries risk.

If the two three-year numbers land within fifteen per cent of each other, stay where you are. A marginal saving does not justify the risk of moving a production system.

Where managed private cloud fits

Repatriation does not have to mean going back to owning and staffing infrastructure. That is the assumption that stops most of these conversations, and it is out of date.

A managed private cloud is dedicated infrastructure, run for you by a provider, and consumed on a fixed monthly fee. You get the isolation, performance and data location of private infrastructure without buying the hardware, carrying the refresh cycle, or hiring the people to run the platform. The difference from the old on-premises model is who holds the capital cost and the operational risk.

It is also not automatically the right answer. It suits organisations with enough steady-state workload to justify dedicated capacity, real constraints on where data can live, and a small internal team that would rather spend its time on applications than on firmware.

We took this position at Bayside City Council at the height of cloud-first policy, when the expected recommendation was a full migration to public cloud. The numbers did not support it for their workload profile, so we advised against it and built a private cloud on their own premises instead. That platform is still doing its job.

VMware alternatives, if that is what started this

A lot of repatriation conversations are really licensing conversations. If a renewal quote is what brought you here, the realistic options are narrower than the internet suggests.

• Stay and negotiate. Unglamorous, and often the cheapest outcome once you price the alternatives properly. Bundle scope and term are both negotiable.
• Nutanix AHV. The most mature commercial alternative, with a real migration path. You are trading one vendor relationship for another rather than escaping vendor pricing.
• Proxmox. Genuinely capable and inexpensive to licence. The cost moves to your team, and support expectations need to be honest.
• Hyper-V. Worth costing if you already hold the Microsoft agreements, because the licensing may be sitting there unused.
• Move to a provider’s platform. Someone else owns the hypervisor decision and its pricing risk.

Whichever way you go, the cost that gets underestimated is the migration. Changing hypervisor means retesting every workload, rebuilding backup and replication, retraining the people who run it, and accepting a period where two platforms run at once.

Six questions that settle it

1. 1. Which specific workloads are you unhappy with, and what do they cost per month right now?
2. 2. What is their real utilisation, as opposed to what you provisioned?
3. 3. How much egress do they actually generate?
4. 4. Do any of them depend on managed services you would have to rebuild?
5. 5. Do you have a data location or audit obligation that public cloud is not satisfying?
6. 6. Who runs the private platform afterwards, and is that cost in your model?

If you cannot answer the first three from data, that is the work to do before anything moves. Most of the repatriation projects that go wrong were costed on assumptions that nobody checked.

Common questions

Is private cloud cheaper than public cloud?

For steady-state workloads at reasonable scale, usually yes over three years. For variable, bursty or small workloads, usually no. The answer depends on the workload profile rather than on the model, which is why estate-wide decisions in either direction tend to be wrong somewhere.

Why are companies moving away from public cloud?

Three reasons dominate: predictable workloads that cost more on consumption pricing than they would on dedicated capacity, egress charges that were not modelled accurately at migration, and data sovereignty or audit requirements that are simpler to evidence on infrastructure you can point at.

Is repatriation the same as going back on-premises?

No. On-premises is one destination. Colocation and managed private cloud are the others, and both avoid the capital cost and the staffing burden that made the original move to public cloud attractive.

How long does moving a workload back take?

For a straightforward virtual machine estate with no managed service dependencies, plan on a quarter from decision to cutover, most of which is testing rather than moving. Anything that needs rebuilding rather than lifting takes considerably longer, and that is the case to scrutinise hardest.