“Everyone is leaving the cloud.” You’ve seen that headline enough times that it reads like settled fact. The trouble is the stories behind it disagree. Some lean on a survey showing 86% of CIOs plan to move workloads back; others put a full exit at just 8 to 9% of enterprises. Most reporting folds together two different things: a one-off repatriation and a hybrid strategy.
Public cloud is still growing, with Gartner projecting 21.5% growth this year. A minority of workloads are moving back to private cloud, on-premises, colocation and edge, driven by cost rather than ideology, while the market expands. That movement sits inside a wider debate about cloud repatriation and digital sovereignty, which this piece narrows to the numbers and the team consequences.
By the end you’ll separate movement from direction, tell a saving from a headline claim, and see what the shift does to your skills, team structure and hiring.
What is cloud repatriation, and how is it different from hybrid reallocation?
Cloud repatriation is the deliberate move of workloads out of public cloud back to private cloud, on-premises, colocation or edge. It’s a retrospective correction of an earlier cloud-first decision. Hybrid reallocation distributes workloads across environments from day one, as a strategy. Repatriation reverses; reallocation plans.
Reporting routinely blurs the two. “Companies are leaving the cloud” usually folds a one-off exit together with an ongoing hybrid redistribution. As one analysis puts it, repatriation is a correction; reallocation is a strategy.
It’s portfolio management: keep the nine AWS workloads that benefit from elastic capacity and move only the tenth, a steady database with residency constraints.
Flexera found 73% of organisations run hybrid cloud. Repatriation is one placement decision among many. Public cloud is being selectively left. For the wider framing, see our repatriation and digital sovereignty piece.
Why has cloud repatriation moved from a fringe cost-trimming exercise to a mainstream infrastructure decision?
Cost has overtaken security as the top public cloud concern, cited by 31% of IT leaders, the first time cost has topped the list. That moved repatriation out of the cost-cutting corner and onto the executive agenda. The shift is selective: the figures resolve once you separate movement from direction.
Flexera’s State of the Cloud, based on 753 decision-makers, puts repatriation at 21%, rising to 23%, alongside 84% struggling with spend. Broadcom reports 50% of enterprises have already repatriated some workloads and 83% are considering it. The Barclays survey behind the “86% of CIOs” headline measures intent to shift, while IDC lands on 8 to 9% planning a full exit.
Workloads move both ways at once, so any single figure tells part of the picture. The direction is still growth: Gartner’s 21.5% forecast rules out a mass exodus. The definitions are doing the work: Flexera counts partial moves, IDC counts only full exits. For the broader repatriation picture, the distinction between movement and direction is what matters most.
That raises the practical question: is your cloud bill a problem? Often, yes. 97% of IT leaders believe some public cloud spend is wasted, and 52% say the waste exceeds a quarter of the budget. Separate a FinOps problem from a placement problem first. Idle or poorly governed workloads are just as wasteful in your own racks. Teams have reported cutting as much as 70% off cloud bills without moving a single workload.
Where a move is justified, the evidence is peer-scale. 37signals (Basecamp), one well-documented example, cut a $3.2m annual AWS bill to $1.3m by moving to its own Dell servers in colocation, projecting seven-figure savings over five years. Their experience shows what a partial, cost-driven correction looks like in practice, and the licensing and egress economics behind those corrections are covered in our piece on cloud lock-in.
Every correction like that one hands infrastructure ownership back to your team. That is the quiet consequence of repatriation, and it changes skills, structure and hiring.
What happens to engineering skills, team structure and hiring when workloads move back on-premises?
When workloads return on-premises, the internal service provider model comes back with them. Your team has to run public cloud, private cloud and colocation as one governed, self-service platform. Hiring shifts from cloud-only specialists toward platform engineers and SREs who can plan capacity and manage hardware. Cloud-native skills remain for the workloads that stay.
Pre-cloud IT shops ran on ticket queues and week-long lead times. The internal service providers being rebuilt today have a harder job: self-service across cloud, private cloud and edge under different constraints. Gartner projects that by 2026, 80% of large software engineering organisations will run a platform team acting as an internal service provider. The same model scales down: one small platform team can cover an entire mixed estate, so every hire counts.
Cloud-native capabilities don’t disappear, but capacity planning, hardware lifecycle, networking, storage and SRE-style reliability move back inside the team, a resurgence of traditional infrastructure engineering. The structure is a platform engineering team: platform engineers, site reliability engineers, cloud architects and security engineers delivering an internal developer platform with policy-as-code governance and chargeback.
Hiring changes too. You’re recruiting hybrid operators rather than single-cloud specialists, and infrastructure-as-code portability (Terraform, OpenTofu, Pulumi) becomes a hiring signal because it determines how easily a workload moves.
Production AI inference adds a new wrinkle, shifting off public cloud and bringing GPU and edge orchestration into the platform team’s brief. Where that workload should run, and where the economics flip, is the subject of our piece on AI inference placement.
The staffing consequence is the lasting one: whichever environment a workload lands in, someone on your team now owns its capacity, its reliability and its cost.
The story was never “everyone is leaving the cloud.” It’s a series of placement corrections, and the real question now is who runs the infrastructure.
Decide on the numbers. When you read a repatriation claim, ask whether it’s counting movement or direction: workloads that flowed one way once, or a market that is still growing. Fix the discipline problem before you test a placement problem, because idle capacity wastes money in your own racks exactly as it does in the cloud. Where the numbers justify a move, treat it as a correction, one placement decision among many in a hybrid world.
Plan for the operating-model consequence. The internal service provider comes back with every workload you bring home, and with it the capacity, SRE and FinOps skills to run the estate. The question is whether the team is staffed to hold the infrastructure it now owns. That question runs through leaving the hyperscalers, where the repatriation and sovereignty threads meet.
Frequently Asked Questions
Is the “86% of CIOs plan to repatriate” headline accurate?
Not the way it is usually reported. The Barclays survey behind that figure asked CIOs about moving some workloads, not abandoning public cloud, so it captures intent to shift rather than a full exit. When the same question is phrased as complete repatriation, the number collapses to IDC’s 8 to 9%. The metric is real; the headline is a misreading.
Is cloud repatriation only realistic for large enterprises?
No. Repatriation scales down, and mid-size firms often see the clearest case because the cloud bill is large enough to hurt but the workload estate is small enough to move. A 50 to 500 person organisation can run a mixed estate through one platform team. The named example, 37signals, is not a hyperscaler: it cut a $3.2m AWS bill via colocation.
Which workloads are actually good candidates for repatriation?
Predictable, high-throughput, data-heavy workloads are the usual candidates: steady-state databases, storage tiers, analytics and production AI inference that run flat out around the clock. What tends to stay in public cloud is bursty, experimental and tightly coupled to managed services. The test is your own spend and traffic profile, not the headline.
How do I tell whether a scary cloud bill is a FinOps problem or a placement problem?
Start with the discipline question. If the workload is idle, oversized or poorly governed, that is a FinOps problem, and repatriation will just move the waste to your own racks. A placement problem looks different: a steady, well-optimised workload whose egress, licensing and run costs still exceed colocation. Fix the first before testing the second.
What costs beyond the cloud bill should a repatriation business case include?
Build the case on total cost of ownership, not the monthly invoice. Include everything the cloud bill quietly bundled: hardware refresh cycles, data centre or colocation space and power, networking and egress, licensing, plus the people to run it. Staffing is the most commonly understated line, because the platform team you rebuild is a permanent cost, not a one-off migration expense.
Do we have to build our own data centre to repatriate?
No, and most organisations should not. Colocation lets you place your own hardware in someone else’s facility, with power, cooling and physical security handled for you. Private cloud and edge round out the options. For many mid-size teams, colocation is the practical middle path between staying on public cloud and rebuilding a data hall.
What is the difference between private cloud, on-premises, colocation and edge?
They are four destinations for a returning workload. Private cloud is dedicated infrastructure run with cloud-style automation and self-service. On-premises is hardware in your own facility, colocation is your hardware in a shared third-party facility, and edge puts compute near the user or device. The placement decision picks between them workload by workload, and most estates end up using several at once.
Is it true that running your own infrastructure is always cheaper?
No. The costs apply whether or not you use them: hardware, power, space and staff are fixed, while public cloud is largely variable. That is why a steady workload running at high utilisation often favours repatriation, and a spiky or short-lived one usually does not. The answer depends on your profile, not the direction of travel.
How does AI and GPU inference change the repatriation calculation?
It adds a new placement decision. Production inference is predictable and latency-sensitive, which pushes it toward private cloud, colocation or edge, where you control the GPUs and the data path. That makes GPU and edge orchestration part of the platform team’s brief, not an afterthought. Training, which is bursty, often stays in public cloud.
Is cloud repatriation just a cost-cutting exercise?
Cost usually triggers it, but the decision is broader than the bill. Sovereignty, data residency, latency and control over AI workloads all push the same way. That is why repatriation reads as a correction to an earlier placement decision rather than a retreat from cloud. Hold onto that distinction when you read the headlines, because it is what separates movement from direction.
What are the biggest risks of a repatriation project?
The common ones are underestimating staffing, discovering the workload was more cloud-dependent than it looked, and losing elasticity or resilience once you run the hardware yourself. Migration also takes longer than the plan suggests. A staged, workload-by-workload move, with a clear rollback position and an honest timeline, is what keeps those risks contained.
