Cloud Repatriation: Portfolio Management, Not Ideology

Every few months someone sends me a headline about a company “leaving the cloud” and asks whether the pendulum is swinging back. My answer is always the same: there is no pendulum. There are workloads, and there are invoices, and in 2026 a lot of organisations are finally reading the second carefully enough to re-place the first.

That framing matters, because the repatriation conversation has become tribal. One camp treats any move off public cloud as a failure of engineering imagination. The other treats the cloud decade as a con that’s finally unravelling. Both camps are selling something. The useful position is duller: repatriation is portfolio management. You place each workload where its economics, performance, and compliance profile are best served, and you review those placements the way you’d review any portfolio — periodically, unsentimentally, position by position.

What the data actually says

The survey numbers behind the 2026 narrative are striking at first glance. Barclays’ CIO survey found 83% of CIOs planning to move at least some workloads back from public cloud — nearly double the 43% of 2020. IDC puts the share of enterprises expecting to repatriate some compute or storage in the next year at roughly 80%.

But the number that actually matters is the small one: only around 8% are moving entire workloads off cloud. That gap between “80% are repatriating something” and “8% are moving whole workloads” is the entire story. This is not an exodus. It’s a rebalancing — organisations keeping variable, spiky, experimental workloads in the cloud while pulling predictable, steady-state ones back onto infrastructure they own or lease.

Two honesty notes I’d insist on before you take any of these figures into a board deck. First, the precise percentages are soft — they circulate across vendor blogs with slightly different values, and many of the loudest voices in this conversation are infrastructure vendors with a commercial interest in the narrative. Treat the direction as well-evidenced and the decimals as decoration. Second, IDC’s own finding cuts the other way too: most organisations that repatriated could have achieved much of the saving by optimising what they had. A structural cost gap and a FinOps failure look identical on an invoice. You need to know which one you have before you move anything.

Why the invoice finally forced the question

The organisations feeling this most are the ones that did lift-and-shift migrations between roughly 2018 and 2022, when “cloud-first” was a strategy you could announce without modelling. Those estates are now mature enough that the compounding line items — egress, cross-region transfer, managed-service markups, storage growth — dominate the bill. Flexera still puts wasted IaaS/PaaS spend at around 29%. Rightsizing and commitments claw some of that back, but some workloads remain structurally more expensive in the cloud after every optimisation pass, because the thing you’re paying for — elasticity — is a thing they never use.

That’s the heuristic I keep coming back to: if a workload is predictable, you are paying a premium for optionality you don’t exercise. Cloud is priced like insurance. Flat, 24/7, well-understood workloads — databases, ERP, VDI, and increasingly production AI inference — rarely make a claim.

AI sharpened this in two ways. Continuous, high-utilisation inference is precisely the profile that runs cheaper on owned hardware, which is why it’s the workload class repatriating first. And the sheer size of AI budgets is forcing CIOs to squeeze everything else to fund them — which means re-reading the rest of the estate’s invoice with fresh hostility.

One structural change made the maths easier: since 2024, the major cloud providers offer free egress for customers exiting, under regulatory pressure from the EU Data Act. The waivers generally require an actual exit within a fixed window, so they don’t help ongoing multi-cloud — but they materially lower the one-time tax on a clean move. When 37signals moved roughly 18 petabytes out of S3, the quarter-million-dollar egress bill was waived.

The case studies cut both ways

The named examples get quoted selectively by both camps, so it’s worth stating what they actually show.

37signals saved around $2M a year exiting AWS, and Dropbox — the original repatriation story — reported roughly $75M saved over two years a decade ago. But look at the pattern: predictable, data-heavy workloads, strong infrastructure engineering cultures, and product economics where infrastructure is a first-order cost. That’s three qualifying conditions most enterprises don’t meet.

GEICO is the more instructive case for large organisations — a decade of cloud migration that reportedly landed at 2.5× expected cost, now unwinding half its workloads onto open-source platforms over several years. The lesson there isn’t “cloud failed”. It’s that a migration strategy which ignored workload economics on the way in is expensive to correct on the way out. The portfolio review you skip at adoption time doesn’t disappear; it accrues interest.

And for every public case study there’s a quieter counterexample: teams that repatriated without the operational maturity to run their own infrastructure and ended up with a worse outcome than the bill they were escaping. Cloud abstracts an enormous amount of operational work. If you can’t replace that abstraction with automation, monitoring, and an on-call rotation you actually staff, you’re not saving money — you’re deferring an outage.

How to run the decision

The mechanics I use are in the Cloud Repatriation insight: score each workload one-to-five across eight weighted dimensions — utilisation predictability, data gravity, TCO gap, latency sensitivity, sovereignty requirements, managed-service coupling, ops maturity, growth trajectory — and let the total sort your estate into three buckets. Strong candidates go to a detailed TCO model and a pilot. The middle band goes hybrid: move the steady-state core, keep the bursty and deeply-coupled components in cloud. Everything else stays put, and the energy goes into FinOps instead.

Three rules make the exercise honest rather than theatrical:

Model the full cost, both directions. A credible comparison is a three-to-five-year fully-loaded model — hardware amortisation, power, facilities, staff, migration cost, parallel running — against projected cloud spend growth, not this month’s bill. The most common error I see is bare hardware cost versus cloud invoice, which flatters repatriation by roughly the size of your ops team.
Be sceptical of the headline savings. Achievable numbers for well-chosen workloads cluster in the 30–60% range. The >90% reductions that make the conference-talk slides are outliers built on exceptionally predictable workloads and unusual engineering leverage. Don’t plan on being the outlier.
Keep the exit open in both directions. Build on portable primitives — Kubernetes, OpenStack, S3-compatible storage — so that repatriation is a position you can unwind, not a new form of lock-in. The mature posture treats movability as the capability, and cloud vs owned as this year’s allocation.

The bottom line

The binary framing — cloud versus on-prem, believers versus apostates — was always a category error, and 2026 is the year the market is pricing that in. Cloud keeps winning where it earns its premium: variable demand, global reach, fast experimentation, training bursts. Owned and colocated infrastructure wins where predictability, bandwidth economics, and control dominate. The organisations getting this right aren’t the ones with the strongest opinions about location. They’re the ones with the best-maintained spreadsheet — and a standing habit of re-running it.

Repatriation isn’t a retreat from cloud. It’s what cloud strategy looks like when it grows up.