# Cloud Repatriation

Source: John Bradshaw — https://bradshaw.cloud
URL: https://bradshaw.cloud/strategy/cloud-repatriation/
Type: insight
Tags: Cloud, Economics, Strategy, repatriation

> A decision framework for 2026 — the real survey data, a workload scoring matrix, a 3–5 year TCO model, and the risks. Repatriation as portfolio management, not ideology.

## When to repatriate: the decision framework

### Is the workload predictable and high-utilisation?

**Yes → repatriation candidate. No → keep it in cloud.**

Cloud is priced like an insurance product: you pay for elasticity you may not use. Flat, 24/7, predictable workloads (databases, ERP, continuous inference) rarely exercise that option — so you are paying a premium for nothing.

### Is there a material 3–5 year TCO gap?

**No → optimise FinOps first. Yes → model it fully, then pilot.**

IDC found most organisations that repatriated could have stayed in cloud with better upfront cost optimisation. Confirm the problem is structural, not a tuning failure, before you move anything.

### Heavy data gravity or large egress exposure?

**Yes → strong signal. Use the 2024 exit-fee waivers.**

Persistent multi-petabyte datasets and heavy outbound traffic are where cloud economics break down hardest. Factor one-time exit egress into the business case and use the 2024 waiver programmes to move data out cheaply.

### Do you have the ops maturity to run it yourselves?

**No → build capability first, or use managed colocation.**

Cloud abstracts enormous operational work. Repatriating without investing in IaC, monitoring, and on-call produces a worse outcome than staying. The skills gap is partly real and partly vendor marketing — but it is not zero.

## Frequently asked questions

### What is cloud repatriation?

Repatriation is moving a workload out of public cloud onto owned or leased infrastructure — colocation, on-premises, or a hybrid of both. It is a workload-by-workload placement decision, not an ideology, and in practice it is almost never wholesale: the shift is from "everything in the public cloud" to "the right workload in the right place". Treat it as portfolio management and the argument stops being tribal.

### Are enterprises really leaving the cloud?

They are moving some things back, not leaving. Surveys consistently show a large majority of organisations planning to repatriate at least some workloads, while only a small single-digit share are moving entire workloads off cloud — and that gap is the whole story. Reported drivers rank cost first, then performance, then data sovereignty. Treat the direction as well-evidenced and the precise percentages as soft; many of the sources have a commercial interest in the narrative.

### Which workloads are the best repatriation candidates?

Score each workload across eight dimensions and weight them: utilisation predictability, data gravity and egress exposure, and the three-year TCO gap carry the most weight; latency sensitivity, compliance, managed-service coupling and ops maturity carry less; growth trajectory carries least. The pattern that scores highest is flat, predictable, data-heavy, and loosely coupled — databases, ERP, continuous inference. Cloud is priced like an insurance product, and a predictable workload never claims.

### How much can repatriation actually save?

For genuinely suitable workloads, savings cluster in the 30–60% range on a fully loaded three-to-five-year view. Treat anything higher sceptically: the widely cited outliers rest on exceptionally predictable workloads and unusual engineering leverage, and they are a headline rather than a planning baseline. If your model shows more than 60%, the most likely explanation is that something is missing from the cost side.

### What does an honest repatriation TCO model include?

Compute, storage, data transfer and egress, power and cooling, facilities, staff and ops, the value of elasticity you would give up, and one-time migration cost — modelled over three to five years against projected cloud spend, not today's bill. The classic error is comparing bare hardware cost to a cloud invoice, which flatters repatriation by roughly the size of your ops team. On egress, the 2024 exit-fee waivers can remove the one-time tax, but they generally require an actual exit within a fixed window.

### What are the main risks?

Four. Operational complexity — repatriating without investing in automation, monitoring, and on-call produces a worse outcome than staying. Lost elasticity, and the mis-sizing that follows. Sovereignty cutting both ways, because you then own the compliance burden you were renting. And irreversibility — build on portable foundations so the decision stays reversible. There is also a cheaper failure mode worth ruling out first: a structural cost gap and an unoptimised estate look identical on an invoice.

## Interactive companion

**Cloud Repatriation: Workload Scorer** — Score a cloud workload across the eight weighted dimensions — utilisation, egress, TCO gap, latency, sovereignty, coupling, ops maturity, growth — and see whether it should repatriate, go hybrid, or stay in cloud.

Live calculator: https://bradshaw.cloud/strategy/cloud-repatriation/calculator/

## Related

- [Cloud exit readiness](https://bradshaw.cloud/writing/cloud-repatriation-exit-readiness/) — the dependency test before a workload moves.
- [Economic sovereignty](https://bradshaw.cloud/strategy/cloud-sovereignty/) — the lock-in framing that sits underneath the repatriation decision.
- [AI cost curves](https://bradshaw.cloud/strategy/ai-cost-curves/) — why continuous inference is the workload that repatriates first.
- [Build vs Buy](https://bradshaw.cloud/strategy/build-vs-buy/) — the same portfolio logic applied to every technology choice.
- [All strategy insights](https://bradshaw.cloud/strategy/)

_This insight has additional narrative content on the HTML page. Read the full version at https://bradshaw.cloud/strategy/cloud-repatriation/._