Cloud Repatriation in 2026: What the Data Shows

You've probably seen the headline version of this by now: some variation of “86% of CIOs are pulling workloads out of the cloud,” often dressed up further into “the great cloud exodus of 2026.” It's the kind of stat that's technically sourced and functionally misleading at the same time — real survey, real number, wrong takeaway. The actual data, once you trace it back, describes something much narrower and much more useful: companies getting more deliberate about which workloads belong where, not a retreat from the cloud.

What the 86% headline doesn't tell you

The number comes from a Barclays CIO Survey (Q4 2024), which asked CIOs whether their organization planned to move any workload from public cloud back to private or on-premises infrastructure. 83–86% said yes, depending on which write-up you read — the highest rate Barclays has recorded. The problem, as industry analyst Larry Walsh pointed out plainly, is that the question doesn't distinguish scale: “if 83% of enterprises decide to move one workload from the public cloud to their local infrastructure, the number remains true.” A company relocating a single logging service and a company exiting the cloud entirely both answer “yes,” and both get counted the same way.

IDC's independent research fills in the gap the headline leaves out. In IDC's “Assessing the Scale of Workload Repatriation,” roughly 80% of respondents expected some repatriation of compute or storage within 12 months — consistent with the Barclays number. But less than 10% reported repatriating an entire workload. The overwhelming majority were moving specific, targeted pieces: a database here, an AI inference pipeline there.

The market is still growing — just not evenly

That last figure is worth sitting with. Gartner forecasts worldwide public cloud end-user spending to reach $723.4 billion in 2025, up from $595.7 billion the year before — a 21.5% increase, in the same period this repatriation narrative was building. Both things are true: enterprises are pulling specific workloads back, and overall cloud spend keeps climbing, because new workloads (a lot of them AI-driven) are being created faster than old ones are being repatriated. Gartner separately predicts that over 40% of leading enterprises will have adopted hybrid computing architectures for mission-critical workflows by 2028, up from around 8% today. Read together, these aren't contradictory — they describe a shift from “cloud by default” to “cloud by workload,” where the placement decision gets made deliberately instead of inherited from whatever the original migration plan assumed.

Where repatriation actually makes sense

When IDC and Barclays asked what's actually driving the decisions behind that ~80%, the answers cluster around three things: cost (cited by 54% of respondents), performance (31%), and data sovereignty or compliance (27%). None of these are new concerns — what's changed is the workload profile. Steady-state, predictable compute (the kind that runs 24/7 at a known volume) is exactly where hyperscaler pricing stops being a good deal, because you're paying an elasticity premium for elasticity you're not using. AI training and inference workloads sharpen this further: they're GPU-intensive and latency-sensitive, which is precisely the profile where dedicated infrastructure starts to pencil out cheaper than renting by the hour.

What it looks like in practice: GEICO's decade-long lesson

GEICO's story is the most concrete public example of this pattern. Starting in 2013, the company spent roughly a decade migrating over 600 applications to the public cloud. By its own account, the bill didn't shrink — it grew 2.5x, driven heavily by storage and data retrieval costs, while reliability suffered from data being spread across multiple vendors. GEICO is now repatriating workloads onto a private cloud built on OpenStack and Kubernetes, consolidating those 600+ legacy systems toward roughly 15–16.

“We have a lot of data — and it turns out that storage in the cloud is one of the most expensive things you can do in the cloud.”

— Rebecca Weekly, VP of Platform and Infrastructure Engineering, GEICO

That's not a story about the cloud failing as a concept — GEICO used it for a decade and it did what it was supposed to do early on. It's a story about a workload profile (large, steady, storage-heavy) outgrowing the pricing model it was placed under, and nobody revisiting that placement for ten years.

So — should you repatriate?

• Break your cloud bill down by workload, not by total spend — the aggregate number hides which specific services are actually expensive.
• Flag steady-state, predictable-volume workloads first; they're the most common repatriation candidates because you're not paying for elasticity you don't use.
• Model the full cost of moving data out, not just compute — egress and exfiltration fees are frequently where the real savings (or the real trap) hide.
• Check data residency and compliance requirements before anything else; for regulated industries, this can override the cost math entirely.
• Treat this as an ongoing workload-placement decision, not a one-time migration — the right answer for a given service can change as its usage pattern matures.

You don't need GEICO's decade or its $300M annual cloud bill to have this problem. The same pattern — a workload that quietly outgrew the pricing model it was placed under — shows up identically at $5,000 a month or $500,000 a month; the zeros change, the mechanism doesn't. If reading this made you want to actually check your own bill rather than the industry's, that's the more practical, ground-level version of this piece: what a cost audit actually finds, workload by workload, at whatever scale your business runs at.

This is exactly the kind of decision that benefits from an outside, workload-by-workload audit rather than a wholesale migration project in either direction. Our Cloud Migration and Systems Integration work is built around that: modeling what a given workload actually costs where it lives now, what it would cost elsewhere, and architecting the hybrid setup in between — rather than treating “cloud” or “on-prem” as an all-or-nothing choice.