# What is Cloud Repatriation? Why AI Workloads are Moving On-Premises

> What cloud repatriation is, why AI workloads are moving on-premises, a hypothetical GPU break-even, a real case, and when staying in the cloud is better.

Source: https://hyperlake.cloud/blog/what-is-cloud-repatriation-why-ai-workloads-move-on-premises-2026
By Hyperlake Team · Hyperlake

Cloud repatriation means moving workloads, data or both out of a public cloud and into a private cloud, a colocation facility or your own data centre. With AI, teams usually have one of three reasons: steady GPU usage that makes owned hardware cheaper than rented capacity, data that has to stay under their own control, or latency to data that already lives on site. It's a placement decision made workload by workload. It isn't a verdict against the public cloud.

We make HyperLake, a sovereign AI operating platform that runs in the customer's own cloud account on AWS and Google Cloud today, with private cloud and on-premises deployments coming soon. We have a stake in the answer, so the product gets one section, and it says where it doesn't apply.

![A cloud icon with an arrow back to on-premises server racks, above three reasons: cost, control and latency.](https://hyperlake.cloud/blog/img/production/68d626b4a50da8b2b38178ffa1143e293f38ffb2-1200x840.png?w=1600&fit=max&auto=format)

## What does cloud repatriation mean?

Repatriation (sometimes called a cloud exit or reverse migration) means a workload that ran on a public cloud now runs somewhere you control: a private cloud, hardware in a rented rack, or your own facility. It's often partial. Plenty of organisations bring back a few workloads, a steady inference service or a large dataset, say, and leave everything else where it is.

It gets mixed up with three other things:

- Never migrating. Repatriation starts from a workload that's already in the cloud.
- Multi-cloud. Moving between two public clouds is a migration, not a repatriation.
- Hybrid. That's the end state where some workloads run in each place. Most repatriation lands there, not at "all on-premises".

## How common is cloud repatriation?

The published figures are survey results, mostly from vendors, and they measure different things: completed moves, plans, or "any workload, ever". Read them as signals, not as a market size.

- Cloudera, August 2026. In a survey of 1,500 enterprise architects, cloud infrastructure leads and data architects across nine countries, which Cloudera commissioned and Wakefield Research ran, 66% said their organisation had moved AI workloads from public cloud back to private cloud or on-premises infrastructure in the previous 12 months. The same survey found hybrid (31%) and public cloud (30%) leading for AI inference, with on-premises at 8%. The article says Cloudera's follow-up blog rejects reading the 66% as evidence that public cloud is failing. Source: [Virtualization Review's report](https://virtualizationreview.com/articles/2026/08/12/cloudera-survey-66-percent-repatriated-ai-workloads-from-public-cloud.aspx). Cloudera sells a data platform spanning cloud and on-premises, which may colour the framing.
- Flexera, 2025. Of 759 respondents to its State of the Cloud survey, 21% said they had moved workloads and data back from the cloud, citing cost, security and reliability. Source: [InformationWeek](https://informationweek.com/cloud-computing/ask-the-experts-cios-say-they-wouldn-t-pull-workloads-back-from-the-cloud).

Both can be true at once. A big share of large enterprises move something back, while the share of total workloads that moves stays small. The Register's October 2024 coverage of 37signals puts the share of companies actively repatriating public cloud workloads "in the single digit percentage sphere". That's an unsourced estimate, not a measurement, and it predates the surveys above.

## Why are AI workloads moving on-premises?

AI shifts both the economics and the risk profile of the cloud, in four ways. None of them applies to every workload.

### Cost: steady GPU use is the key variable

Rented GPUs are priced for flexibility. If a GPU is busy most of the day, you're paying that flexibility premium all year. If it's busy a few hours a week, renting nearly always wins. In the Cloudera survey, 84% of respondents said AI workloads had increased infrastructure costs, yet only 25% listed cost reduction among their reasons for changing data architecture. Cost counts, but security and compliance (42%) ranked higher on that list.

Here's a hypothetical break-even calculation. The numbers are invented to show the method, so swap in your own quotes.

| Item | Hypothetical value |
| --- | --- |
| Rented GPU, on-demand | $4.00 per GPU-hour |
| Owned GPU, all-in over 4 years (hardware, power, hosting, staff time) | $60,000 |
| Owned cost per year | $60,000 / 4 = $15,000 |
| Break-even hours per year | $15,000 / $4.00 = 3,750 hours |
| Hours in a year | 24 x 365 = 8,760 |
| Break-even utilisation | 3,750 / 8,760 = about 43% |

On those made-up numbers, a GPU that's busy more than about 43% of the time is cheaper to own than to rent on demand, and one that's busy less is cheaper to rent. Real comparisons also have to account for committed-use cloud discounts, hardware refresh, idle capacity you buy for peak demand, and the staff to run it all. Our [LLM API vs self-hosted cost calculator](https://hyperlake.cloud/tools/llm-api-vs-self-hosted-cost-calculator) takes your own inputs, and [Is Self-Hosting an LLM Worth It vs an API?](https://hyperlake.cloud/answers/is-self-hosting-an-llm-worth-it) covers the wider trade-off.

### Control: data that cannot leave

Regulated data, contractual limits on where data may sit, and a simple preference for holding the keys all push some AI workloads toward environments you control. In the Cloudera survey, data security, governance and compliance was the most-cited reason for changing data architecture, at 42%. For the difference between where data sits and who can compel access to it, see [Data Residency vs. Data Sovereignty for Enterprise AI](https://hyperlake.cloud/blog/data-residency-vs-data-sovereignty) and [What Is Sovereign AI? Definition and Layers](https://hyperlake.cloud/answers/what-is-sovereign-ai).

### Latency and data gravity

Training and inference often sit next to data that already lives on site: factory sensor data, imaging archives, an existing warehouse. Shipping a large dataset to a cloud region and sending results back adds delay and transfer charges. Cloudera's respondents cited performance, latency and real-time or edge AI at 35% each.

### Predictability and lock-in

Usage-based bills can swing with every experiment and every spike in agent traffic. A fixed hardware commitment swaps that variability for capacity risk. [AI Cost Observability](https://hyperlake.cloud/blog/ai-cost-observability-seeing-your-spend-before-the-bill-arrives) covers measuring what you actually spend, and [Vendor Lock-In Prevention in AI Infrastructure](https://hyperlake.cloud/blog/vendor-lock-in-prevention-in-ai) covers portability.

## What does a real repatriation look like?

The best-documented public case is 37signals, the company behind Basecamp and HEY. As The Register reported in October 2024, the company moved seven applications from AWS to its own Dell hardware in summer 2024 and said its cloud bill fell to about $1.3 million, almost $2 million a year lower than before. It said the roughly $700,000 hardware purchase was recouped from savings during the second half of 2023 as cloud contract commitments expired, and that staffing stayed the same. Its remaining spend was all S3 storage of almost 10 PB, under a four-year contract, which it planned to replace with its own storage.

Read it carefully. The figures are the company's own. Its chief technology officer concedes that cloud and on-premises comparisons are never fully apples-to-apples. It's one software company, and the reporting doesn't describe AI workloads. So take it as an illustration of the method, not a forecast for yours. Source: [The Register](https://www.theregister.com/2024/10/21/37signals_aws_savings).

## When should you not repatriate?

The same InformationWeek piece quotes two CIOs who wouldn't pull workloads back. One, at a credit union, sees the cloud as central to innovation and AI integration and points to scalability and faster deployment. The other argues that a properly configured cloud is no less secure than on-premises, and that poor sizing can cause latency and overage charges. That's two practitioners' opinions, not data, but it lines up with common sense about when to stay put:

- Bursty or experimental work. Short training runs, proofs of concept and spiky demand suit rented capacity.
- Small teams without operations skills. Owned hardware needs people for patching, failures and capacity planning.
- Workloads that depend on managed services you can't easily replace.
- Uncertain demand. Buying hardware for demand that never shows up is the expensive mistake.

Rule out fixable cloud waste first: oversized instances, idle endpoints, unplanned scaling. [FinOps for AI](https://hyperlake.cloud/blog/finops-for-ai-how-to-govern-what-youre-actually-spending) covers how to find it. We'd honestly start there before anyone prices a rack.

## What should you check before moving?

1. Inventory by workload, not by account. List each workload with its utilisation, data size and data-residency needs.
1. Work out a break-even like the one above, with your own prices and the staff cost included.
1. Price the exit. Leaving a cloud can mean data transfer charges. AWS says it offers free data transfer out to the internet for customers moving all their data off AWS, but only by request to AWS Support and after review; credits are issued for the migrated data and eligible customers outside the EU have 180 days to finish (see [AWS's announcement](https://aws.amazon.com/blogs/aws/free-data-transfer-out-to-internet-when-moving-out-of-aws/), last updated October 8, 2026). Check the current terms of whichever provider you use, plus any contract commitments.
1. Decide the target: on-premises, colocation or private cloud. See [On-Premises AI: Self-Hosted and Hybrid Deployment](https://hyperlake.cloud/blog/on-premises-ai) and, for build-versus-rent sizing, [How Many GPUs Do I Need to Serve an LLM?](https://hyperlake.cloud/answers/how-many-gpus-to-serve-an-llm).
1. Move one workload first, usually a steady inference service, and measure before you move more.

If what you really want is to leave a specific data warehouse, that's a different question; see [Snowflake alternatives that run on-premises in 2026](https://hyperlake.cloud/blog/snowflake-alternatives-that-run-on-premises-in-2026).

## Where does HyperLake fit?

HyperLake isn't a cloud provider and doesn't sell hardware. According to HyperLake's product description, it lets teams assemble, deploy and govern the data, models, applications and tools behind AI in their own environment or a client's, so customers keep their data, models and keys in infrastructure they control. Today it runs in the customer's own cloud account on AWS and Google Cloud. Private cloud and on-premises deployments are coming soon, and it uses Kubernetes so services stay portable and manageable across environments. That matters if you want to place workloads by the criteria above and revisit the placement later. Portability doesn't remove the cost of moving data or running hardware, though.

It won't make the decision for you. And if all your workloads are bursty or small, repatriation, and with it a platform for running your own environment, may not be worth it.

## Frequently asked questions

### What is cloud repatriation in simple terms?

It's moving a workload or its data from a public cloud back to infrastructure you control, whether that's a private cloud, a colocation rack or your own data centre.

### Is cloud repatriation the same as leaving the cloud entirely?

No. Most organisations repatriate selected workloads and keep the rest in public cloud, so they end up with a hybrid mix. As the report describes it, Cloudera's follow-up blog makes the same point about the 66% figure.

### Why is repatriation happening now with AI?

Because AI workloads can be large, steady and sensitive. Steady GPU use can favour ownership, and sensitive or regulated data can favour control, but the case has to be made workload by workload.

### Is it cheaper to run AI on-premises than in the cloud?

Sometimes. It mostly comes down to how busy the hardware is and what staff and refresh cost you. The hypothetical above breaks even at about 43% utilisation, and yours will differ.

### What are the risks of repatriation?

The main ones are capacity risk if demand changes, the staff time to run hardware, exit and transfer charges, and losing managed services. Moving one workload first limits your exposure.

### Does repatriation mean on-premises only?

Not at all. The destination can be a private cloud or colocation, and hybrid, with each workload wherever it fits best, is the usual result.

## Related reading

- [On-Premises AI: Self-Hosted and Hybrid Deployment](https://hyperlake.cloud/blog/on-premises-ai)
- [Local AI vs Cloud AI: Why Hybrid AI Works Best](https://hyperlake.cloud/blog/local-ai-vs-cloud-ai-why-the-smart-setup-is-hybrid-daniel-jindoo)
- [Is Self-Hosting an LLM Worth It vs an API?](https://hyperlake.cloud/answers/is-self-hosting-an-llm-worth-it)