Cloud Repatriation

What repatriation is — and what it isn't

Cloud repatriation — moving workloads from public cloud back to private cloud, colocation, or on-premises — has become one of the defining infrastructure conversations of 2026. But it is not an anti-cloud backlash, and treating it as one leads you to the wrong decision. The framing I keep coming back to is portfolio management: placing each workload where its economics, performance, and compliance profile are best served. This is a workload-by-workload call, not an ideology.

The data is consistent on this. Only a small minority of organisations pursue a total cloud exit; the overwhelming majority are rebalancing — keeping variable, spiky, experimental workloads in the cloud while moving predictable, steady-state ones to owned infrastructure. The shift is from "everything in the public cloud" to "the right workload in the right place."

Why the 2026 narrative is happening

Several forces converged to turn repatriation from a fringe talking point into a board-level topic.

The invoice finally arrived

Organisations that adopted lift-and-shift cloud-first strategies between roughly 2018 and 2022 are now confronting compounding bills — egress fees, cross-region and cross-AZ transfer charges, premium managed-service markups, storage growth. FinOps and rightsizing help, but only to a point; some workloads stay structurally more expensive in the cloud even after optimisation. Flexera's 2026 data puts wasted IaaS/PaaS spend at around 29% of the total, after several years of slow decline.

The survey evidence (and the scepticism it deserves)

• Barclays CIO Survey (Q4 2024): 83% of CIOs planned to move at least some workloads from public cloud back to private or on-premises — up from 43% in 2020, the highest the survey had recorded. (Some secondary write-ups report 86%; treat the precise number as soft.)
• IDC: roughly 80% of enterprises expect to repatriate some compute or storage within 12 months — but only about 8% are moving entire workloads off cloud. That gap is the whole story: this is selective rebalancing, not exodus.
• Reported drivers (IDC): cost (54%), performance (31%), data sovereignty (27%).

A note I'd insist on: these figures circulate widely across vendor blogs with slightly different numbers, and many of the loudest sources are infrastructure vendors with a commercial interest in the narrative. Treat the direction as well-evidenced and the precise percentages as soft.

The "Cost of Cloud" thesis, and AI economics

The intellectual foundation is Andreessen Horowitz's 2021 essay "The Cost of Cloud, a Trillion Dollar Paradox" by Sarah Wang and Martin Casado — its memorable line, "you're crazy if you don't start in the cloud; you're crazy if you stay on it," and its advice to have a repatriation strategy before you reach scale. Note they did not argue for blanket repatriation; they argued infrastructure spend should be a first-class metric. The thesis has credible critics, too (Corey Quinn among them).

The newer driver is AI. Continuous, high-utilisation inference is exactly the predictable profile that runs cheaper on owned hardware, and the AI budget squeeze is forcing CIOs to optimise everything else. For steady-state inference, the cloud's elasticity premium evaporates.

The egress turning point

In 2024, regulatory pressure (the EU Data Act) forced a structural change: Google Cloud announced free egress for leaving customers in January 2024, and AWS and Azure followed in March. The catch — these waivers generally require you to be exiting (cancelling, completing the move within 60–90 days), so they help one-way repatriation but not ongoing multi-cloud. They still materially lower the cost of a clean exit.

Who has actually repatriated

Named cases anchor the argument — but note the pattern: predictable, data-heavy workloads and strong engineering cultures. They are not evidence that repatriation works for everyone.

When repatriation makes sense — and when cloud still wins

The single most useful heuristic: if your workload is predictable, you are paying a premium for elasticity you don't use. Cloud is priced like an insurance product — you pay for optionality. Steady-state workloads rarely exercise that option.

The scoring matrix

Score each workload 1–5 on each dimension, apply the weighting, and total. Higher = stronger repatriation candidate.

Top third → strong candidate: proceed to detailed TCO and a pilot. Middle third → hybrid: move the steady-state core, keep burst and managed-service-coupled components in cloud. Bottom third → keep in cloud and focus on FinOps instead.

flowchart TD
    A["Workload under review"] --> B{"Predictable, high utilisation?"}
    B -->|No| Z["Stay in cloud / optimise FinOps"]
    B -->|Yes| C{"Material 3-yr TCO gap vs cloud?"}
    C -->|No| Z
    C -->|Yes| D{"Heavy data gravity or egress cost?"}
    D -->|Yes| E{"Ops maturity to run it ourselves?"}
    D -->|No| F{"Compliance or sovereignty driver?"}
    F -->|Yes| E
    F -->|No| G["Hybrid: move core, keep burst in cloud"]
    E -->|No| H["Build capability first or use managed colo"]
    E -->|Yes| I["Repatriate: pilot lowest-risk workload"]

TCO: cloud vs on-prem vs colocation

A credible business case compares three-to-five-year fully-loaded costs — not just the compute line. The most common error I see is comparing a cloud bill against bare hardware cost while ignoring power, staff, and the value of lost elasticity.

Build the model over a 3–5 year horizon, include the one-time migration cost, and — crucially — include the cost of inaction: projected cloud spend growth. Achievable savings for suitable workloads cluster in the 30–60% range; treat the high end sceptically and model your own numbers. 37signals' reported >90% reduction is an outlier driven by an exceptionally predictable, optimised workload — don't use it as a planning baseline.

Risk and compliance

Repatriation trades one risk profile for another. The honest list:

• Operational complexity. Cloud abstracts enormous operational work. Repatriating without investing in automation, monitoring, and on-call produces a worse outcome than staying.
• Loss of elasticity. You provision for peak. Mis-sizing means either wasted CapEx or capacity shortfalls.
• Sovereignty cuts both ways. Regulation (GDPR, sector rules) and the US CLOUD Act push regulated workloads toward owned/local infrastructure — but you then own the compliance burden you were renting.
• Egress as a one-time tax. Factor exit egress into the case; use the 2024 waiver programmes.
• Reversibility. Build on portable, standardised APIs (OpenStack, Kubernetes, S3-compatible storage) so you keep the option to move back. Treating architectural flexibility as a core capability is the mature posture.

The execution path

flowchart LR
    A["1 Portfolio assessment"] --> B["2 TCO model 3-5 yr"]
    B --> C["3 Choose landing platform"]
    C --> D["4 Pilot lowest-risk"]
    D --> E["5 Parallel run and validate"]
    E --> F["6 Incremental migration"]
    F --> G["7 Operate and optimise"]

Start with the highest-savings, lowest-risk workload; 37signals migrated app by app, not all at once. Run both environments before cutover, validate cost and performance, then move the next tranche. Repatriation is the beginning, not the end — continuous capacity planning and density optimisation are what compound the savings.

When to repatriate: the decision framework

The bottom line

The binary "cloud vs on-prem" framing is over. The winning 2026 strategy is deliberate placement: cloud where it earns its premium (variable demand, global edge, rapid experimentation, AI training bursts), and owned or leased infrastructure where predictability, bandwidth economics, data gravity, and control dominate. Repatriation isn't a retreat from cloud — it's the maturation of cloud strategy. Make it a portfolio decision, model the full TCO honestly, pilot before you commit, and keep your exits open in both directions.