← Journal
7 September 20263 min read

Everyone is repatriating and almost nobody is leaving

86% of CIOs plan to repatriate something, about 20% of workloads have moved back, and cloud spending still grew over 20%. Those are not contradictory once you stop treating it as one decision.

Cloud repatriation is having a loud year, and the headline statistic is being misread almost everywhere it appears.

The figures worth holding onto are these: 86% of CIOs plan to repatriate at least some workloads, and around 20% of workloads have already been pulled back from public cloud — while global public cloud spending still grew over 20% year on year.

"Most enterprises are leaving the cloud" and "most enterprises moved something out of the cloud" are very different claims. Only the second is supported, and it describes portfolio management rather than a reversal. Spending going up and workloads coming back are happening at the same time, which only sounds contradictory if you think of this as a single decision rather than a per-workload one.

Three measures of cloud repatriation in 2026Eighty-six per cent of CIOs plan some repatriation, about twenty per cent of workloads have moved back, and public cloud spending still grew about twenty per cent.86%of CIOs plan to repatriateat least some workloads~20%of workloads alreadypulled back+20%year-on-year growth inpublic cloud spending
Three different measures, so three tiles rather than one chart. Barclays CIO Survey; Flexera, 2025

The economics that drive it

The mechanism is not complicated once you see it.

Cloud pricing is optimised for variability. You pay a premium per unit in exchange for the ability to stop paying when you stop using. For workloads that are genuinely spiky — launch traffic, seasonal peaks, batch jobs, anything early-stage — that premium is excellent value, because the alternative is provisioning for peak and paying for idle.

For workloads that run at a steady, predictable level for years, you are paying an option premium on an option you never exercise.

Egress is where this becomes vivid. Standard internet egress on the major providers runs roughly $0.087 to $0.12 per GB, with inter-region transfer around $0.02 and cross-availability-zone around $0.01. Those numbers look small until you multiply by a data-intensive workload: a customer with 50TB of active data doing regular restores can face $4,000–5,000 a month in egress alone.

The strategic point about egress is that it prices movement, not use. It is cheap to put data in and expensive to take it out, which means the cost of changing your mind rises with every month you stay. That is not a conspiracy — it reflects real bandwidth costs — but it is worth recognising as an architectural fact rather than a line item.

The costs that do not appear in the comparison

Repatriation analyses are usually built by comparing an instance bill to a hardware quote, and that comparison is close to meaningless.

What is missing is the operations. Someone racks it, patches it, monitors it, replaces the failed disk at 3am, plans capacity twelve months ahead, and carries the pager. In a large organisation those people already exist and the marginal cost is genuinely low. In a ten-person company they do not, and "we saved $3,000 a month" alongside "one engineer now spends a third of their time on infrastructure" is a bad trade described as a good one.

The second missing cost is optionality. On-premises capacity is a bet on a demand forecast. If you are wrong upward you have a hard ceiling; wrong downward and you own idle metal. The cloud premium is partly the price of not having to forecast.

The decision that actually generalises

The useful frame is per workload, not per company.

Predictable baseline load, steady for a year or more, with data that does not need to move much — good repatriation candidate. Storage-heavy, egress-heavy workloads are the clearest wins, because that is where cloud pricing is least favourable.

Spiky, uncertain, or early-stage workloads should stay where elasticity is cheap. So should anything where you would rather buy the operational burden than staff it.

Most organisations land on both, which is why the surveys show near-universal intent to repatriate something alongside continued growth in overall cloud spend. The mature answer is a portfolio, and "all in on cloud" and "get off the cloud" are both positions that avoid doing the analysis.

For smaller teams

If you are a small team reading the repatriation coverage and feeling like you are overpaying, two things are worth checking before you buy servers.

First, find out what you are actually spending it on. In most small deployments the bill is dominated by a couple of oversized instances, forgotten storage, and egress from a chatty architecture — all fixable without moving anything.

Second, remember that the comparison that matters is not cloud versus metal. It is cloud versus metal plus the engineering attention you will spend on it. For a small senior team, attention is the scarcest resource on the balance sheet, and it does not appear on either quote.

cloudinfrastructurecostarchitecture

Building something like this?

We are a product studio in Kathmandu. Tell us what you are building and an engineer will reply.