The Private Cloud Return: A Business Case for Repatriation That Survives Finance

Almost every enterprise that went all-in on public cloud now has at least one workload it quietly suspects would be cheaper to run itself. Few have a business case for moving it back that survives a second meeting with the CFO. The repatriation trend is real, but the way most teams argue for it is not.

The signal is easy to read. Flexera's 2024 State of the Cloud Report shows a growing share of organizations moving at least some workloads off public cloud, and the trade press has turned a handful of loud exits into a movement. What the headline misses is that repatriation is not a reversal of the cloud decision. It is a correction to a small number of placement decisions that were wrong for a specific reason. Treat it as the former and you will either overcorrect into a datacenter you cannot staff, or lose the argument to a finance team that has seen this slide before.

We build these cases for a living, and the ones that hold up share a frame that the loud exits rarely explain.

Why the run-cost arbitrage frame fails

The standard repatriation pitch is a subtraction problem. Here is the cloud bill, here is the estimated cost of owning the hardware, the second number is smaller, so move. It is the mirror image of the migration pitch from a decade ago, and it fails for the same reason that one did: the number on the slide is not the number you will actually pay.

Two things break the arithmetic. First, the cloud bill you are comparing against is a bill you have usually never optimized. We have audited estates about to be repatriated where 25 to 30% of the spend was recoverable with commitment discipline and idle-resource cleanup alone. Repatriating an un-optimized bill books savings against waste you could have deleted at no cost, and the datacenter inherits a workload that was never right-sized. Fix the bill first, then compare.

Second, the owned-hardware estimate on the slide is almost always the sticker price of servers and nothing else. It leaves out the datacenter or colocation space, the power and cooling, the network, the software licensing that often climbs when you leave the cloud, the hardware refresh in year four, and the people who will run all of it at 3 AM. That is not a rounding error. It is frequently the majority of the real cost.

The contrarian point is simple. The headline cloud bill is the worst possible starting number for a repatriation case, because it flatters the decision you already want to make.

The variable that actually decides it

Public cloud and private infrastructure have different cost shapes, and the shape is what matters. Cloud is mostly a variable cost: you pay close to zero when a workload is idle and a premium when it runs. Owned infrastructure is mostly a fixed cost: you pay for the capacity whether you use it or not, and the per-unit cost falls the more you keep it busy.

That single difference sets the whole case. A workload that runs flat-out, 24 hours a day, at steady and predictable load, amortizes fixed hardware across constant use and makes the cloud premium look expensive. A workload that is spiky, seasonal, or elastic spends most of its life idle, and in the cloud you simply stop paying for the idle hours. Repatriate it and you buy enough capacity for the peak, then watch most of that capacity sit dark.

So the deciding variable is sustained utilization, not the size of the workload and not the headline bill. In our modeling, the crossover usually sits somewhere above 60 to 70% sustained utilization of committed capacity. Below that line the cloud's ability to charge you nothing for idle time wins. Above it, the economics of owning the iron start to pay, and keep paying for as long as the load stays high. The public cloud premium itself, often quoted at 2 to 3 times the raw cost of equivalent owned hardware, is only a premium at all when the hardware would have been busy. At 20 percent utilization there is no premium to recover, because you would have been paying for four-fifths of nothing.

This is why wholesale "leave the cloud" is as wrong as the wholesale "all-in on cloud" it is reacting against. The estate is a mix of load shapes. The case has to be built one workload at a time.

What a fully loaded TCO includes

A repatriation case that survives finance is a three to five year, fully loaded total cost of ownership comparison, not a monthly bill next to a hardware quote. Five cost categories get left off the slide, and together they usually decide the outcome.

• Facilities and power. Colocation space, power draw, and cooling are a recurring line that scales with the fleet. Public reference points from the Uptime Institute's data center research show how much of a facility's energy never reaches the servers at all, which is cost you simply do not see on a cloud invoice.
• Software licensing. This often rises on exit. Per-core licensing for databases and virtualization, and the recent repricing of VMware under Broadcom, have turned the hypervisor layer into a line item that can erase a chunk of the hardware savings on its own. Model it on the terms you will actually sign, not last year's.
• The refresh cycle. Servers depreciate on a four to five year schedule, and the business case must fund the replacement, not just the first purchase. A TCO that ends in year three conveniently stops before the refresh bill arrives.
• Capital tied up. Hardware you buy is capital you cannot spend on the product. A cloud bill is operating expense that flexes with demand. Some CFOs want the capex-to-opex shift reversed, and some want it kept. Either way it belongs in the model as a cost of capital, not ignored.
• The operations team. This is the big one, and it gets its own section below.

NIST's definition of cloud computing describes a private cloud as infrastructure provisioned for exclusive use, which can be owned and operated by the organization or a third party. That third-party option matters: managed private cloud and bare-metal hosting sit between the hyperscaler and the self-run datacenter, and they change the staffing math considerably. The business case should price at least two private options, not assume the hardest one.

A counter-take: repatriate the floor, not the estate

Conventional repatriation advice says to identify your biggest cloud bills and move them. We disagree, because bill size tells you where the money is, not where the savings are.

The counter-take we offer is to repatriate the floor and leave the spikes in the cloud. Most workloads decompose into a steady baseline that runs all the time and a variable layer that comes and goes. The baseline is the part with high sustained utilization, which is exactly the part that pays to own. The variable layer is the part that spends its life idle, which is exactly the part the cloud prices best. Buy owned capacity for the floor, burst into public cloud for the peaks, and you capture the ownership economics without paying to keep peak capacity dark.

This is the same logic that drives a cloud commitment ladder, run in reverse. On the cloud side we tell clients to lock three-year commitments on their steady-state floor and leave the top of the load curve on-demand. Repatriation is that idea taken one step further: the floor is stable enough and large enough that owning it beats even a committed cloud rate. The variable layer is not, so it stays where variability is free. The decision is not cloud or not-cloud. It is placing the split between the two at the right point on the load curve.

The operational muscle you have to rebuild

The cost that sinks most repatriation cases is not on any hardware quote. It is the operational capability the organization spent a decade deliberately atrophying.

Going to the cloud let teams delete whole job families. Nobody racks servers, plans capacity 18 months out, manages a hardware vendor relationship, or carries a pager for a failed power supply. Repatriation brings all of that back. You need people who can run physical infrastructure, and that skill set has grown scarcer and more expensive precisely because the cloud made it look obsolete. We have seen credible hardware-savings cases evaporate once the loaded cost of three to six rebuilt operations roles went into the model.

The capacity-planning discipline is the harder loss. In the cloud, getting capacity wrong costs you a slightly larger bill next month. In your own datacenter, getting it wrong means either a procurement cycle measured in weeks while a workload throttles, or a rack of idle servers you cannot return. The cloud made over-provisioning cheap to fix and under-provisioning invisible. Owned infrastructure makes both expensive again, and the forecast has to be good the first time.

None of this argues against repatriation. It argues that the operations rebuild is a real, fundable program with a real timeline, and a business case that hides it inside "and then we run it ourselves" is not a business case. It is a hope.

How to build the case

Repatriation is a legitimate correction for a specific set of workloads, and a costly mistake when it is run as a cloud-exit crusade. The work is in telling the two apart with numbers. Build the case in this order.

1. Optimize the cloud bill before you model anything. Strip the waste, apply the commitments, and compare against the real steady-state spend, not the un-managed invoice. Anything else books savings against your own neglect.
2. Score each workload on sustained utilization. Flat, high-utilization, predictable workloads are the candidates. Spiky, seasonal, and elastic workloads stay in the cloud. The line sits above roughly 60 to 70% sustained utilization in most of our models.
3. Build a five-year fully loaded TCO. Include facilities, power, licensing on the terms you will sign, the year-four refresh, the cost of capital, and the operations headcount. Model a managed-private option alongside the self-run one.
4. Fund the operations rebuild explicitly. Name the roles, the timeline, and the capacity-planning process. If you cannot staff it, you cannot repatriate it, and the case stops here.
5. Repatriate the floor and keep the spikes. Set the split on the load curve. Own the steady baseline, burst the variable layer into public cloud, and revisit the boundary every year as the load shape changes.

The organizations that get repatriation right are not the ones with the boldest cloud-exit story. They are the ones who moved three workloads back, kept forty in the cloud, and can show you the utilization curve that justified every one of those calls.