Cloud Repatriation: Should You Move Workloads Off the Cloud?

Your cloud bill keeps climbing, a board member forwarded an article about a company that saved millions by buying its own servers, and now someone wants to know if you should do the same. It is a fair question. It is also one that is easy to answer badly.

Cloud repatriation, moving workloads from public cloud back to infrastructure you control, is real. A handful of well-known companies have done it and published their reasoning. But most organizations that consider it end up with a hybrid answer: some workloads move, most stay and the bill drops because the exercise forces better cost discipline.

This guide explains why repatriation happens, which workloads are good candidates and the analysis to do before anyone signs a hardware purchase order.

What cloud repatriation means

Cloud repatriation is the process of moving applications, data or both out of a public cloud such as AWS, Microsoft Azure or Google Cloud and onto infrastructure you own or lease. That can be:

• On-premises data centers you already operate
• Colocation, where you own the servers but rent space, power and network in someone else’s facility
• Private cloud platforms built on your own hardware
• Dedicated or bare-metal hosting, where a provider runs physical servers reserved for you

Repatriation is rarely all or nothing. Most cases involve specific workloads, such as a large database, a storage archive or a steady compute cluster, while the rest stays in the public cloud. If you need a refresher on the basic trade-offs, start with our comparison of cloud vs on-premise and our explainer on public vs private vs hybrid cloud.

Why some companies move workloads back

The reasons tend to fall into 5 groups.

Cost at steady scale. Public cloud pricing favors flexibility. You pay for the ability to scale up and down on demand. If a workload runs at the same size 24 hours a day for years, you may be paying for flexibility you never use. Owned hardware, spread over its useful life, can cost less for that kind of load.

Data transfer charges. Moving data out of a cloud provider’s network usually costs money. Applications that serve large volumes of data to users or partners can see transfer charges become a major part of the bill. Our guide on how cloud pricing works breaks down where these fees come from.

Performance and latency. Some workloads, such as high-frequency trading, real-time manufacturing control or certain AI training jobs, benefit from specialized hardware or from being physically close to users or machines.

Control, compliance and sovereignty. Organizations in regulated industries or with strict data residency needs sometimes want physical control over where data lives and who can access the hardware.

Predictable budgeting. Finance teams often prefer a fixed depreciation schedule to a variable monthly bill that can spike after a configuration mistake.

Key takeaway: Repatriation makes the most sense for workloads that are large, stable and predictable. Spiky, experimental or fast-growing workloads usually still belong in the public cloud.

A well-known example and what it does and doesn’t prove

The most cited example is 37signals, the company behind Basecamp and HEY. In a June 2023 post, its co-founder David Heinemeier Hansson wrote that the company had moved 7 applications off AWS onto its own Dell servers over about 6 months. The company said it spent roughly half a million dollars on hardware, hosted in 2 data centers through a managed colocation provider, and estimated savings of at least $1.5 million per year compared with its 2022 cloud spend of about $3.2 million.

That is a useful data point, but it comes with context:

• 37signals runs mature, stable software products with predictable traffic.
• It already had experienced operations staff who had run their own hardware before.
• The savings figures are company-reported estimates, not audited results.

Your situation may look nothing like that. The lesson is not “the cloud is too expensive.” It is “for steady workloads, do the math.”

Exit costs are falling

One historic barrier to leaving a cloud provider was the cost of moving data out. That has changed.

In January 2024, Google Cloud announced it would waive data transfer fees for customers migrating all their data off its platform, subject to an application process. In March 2024, AWS announced it would provide credits for data transfer out to the internet when customers move all their data off AWS, after a request to AWS Support. AWS’s current terms give eligible customers outside the EU 180 days to complete the move and do not require closing the account. Microsoft announced a similar policy for Azure the same month, with its own notice and timing requirements.

In the European Union, the Data Act (Regulation (EU) 2023/2854) entered into force on January 11, 2024, and has applied since September 12, 2025. It includes rules to make switching between data processing providers easier, and its switching charges must be fully removed from January 12, 2027. US companies with EU operations should check how this affects their contracts. This is not legal advice.

Lower exit costs make repatriation easier, but they also make it easier to switch between clouds. That is worth weighing too, and our guide on how to avoid cloud vendor lock-in covers it.

Which workloads are good candidates

Use this table as a first-pass filter.

The full cost comparison to do first

The biggest repatriation mistake is comparing a cloud invoice with a server quote. A fair comparison over 3 to 5 years includes much more.

On the cloud side, include: - Current compute, storage, database and network charges - Discounts you could get from commitments or savings plans - Savings available from rightsizing, shutting down idle resources and better storage tiers - Managed services you would have to replace

On the owned-infrastructure side, include: - Servers, storage and networking hardware, plus spares - Colocation space, power, cooling and connectivity, or your own facility costs - Hardware refresh every few years - Software licenses, including virtualization, backup and monitoring tools - Staff time for hardware, patching, security and on-call support - Disaster recovery: a second site or a backup provider - Migration costs: engineering time, parallel running and testing

Then add the softer factors: speed of launching new projects, access to managed AI and analytics services, and the risk of running short of capacity during growth.

Many teams discover that optimizing their existing cloud setup closes much of the gap. A FinOps review is a sensible step before any repatriation decision.

How to decide: a step-by-step process

1. Tag and measure. Make sure every resource is tagged by application and team so you know what each workload actually costs.
2. Optimize first. Rightsize instances, remove waste, buy commitments for steady usage and fix storage tiers. Re-measure after 2 or 3 billing cycles.
3. Shortlist candidates. Use the table above to pick 1 to 3 workloads with steady usage, high spend and few managed-service dependencies.
4. Build a 5-year model. Compare optimized cloud cost with the full owned-infrastructure cost, including staff and refresh.
5. Check your skills. Be honest about whether your team can run hardware, networks and physical security, or whether a managed colocation partner is needed.
6. Make it portable. Containerize the workload and define infrastructure as code, so it can run in either place. Our explainer on infrastructure as code helps here.
7. Pilot one workload. Move a single candidate, run it in parallel and compare real costs and reliability for a few months.
8. Request exit credits. If you move data out of a major provider, follow its documented process for waived transfer fees before you start the transfer.

Our cloud migration checklist also works in reverse for planning the move itself.

Repatriation and AI workloads

AI has added a new twist. GPU-heavy training and inference can be expensive in the cloud, and some organizations are weighing dedicated GPU servers. The same rule applies: high, steady utilization favors owning; bursty experiments favor renting. Power and cooling for GPU servers are also more demanding than for ordinary servers, which affects colocation costs. Our look at AI data center energy explains why.

Conclusion

Cloud repatriation is a tool, not a trend to follow. It can cut costs for large, steady workloads, especially when data transfer charges are high and your team can run infrastructure well. For most organizations, the right answer is a hybrid setup where a few workloads move and the rest stay. Optimize first, model the full cost over several years, pilot one workload and keep your systems portable so you can change your mind later.

Sources

• AWS News Blog: Free data transfer out to internet when moving out of AWS — AWS exit credit program, eligibility and 180-day window
• Google Cloud Blog: Eliminating data transfer fees when migrating off Google Cloud — Google Cloud’s January 2024 exit fee waiver
• Microsoft Azure Updates: Free data transfer out to internet when leaving Azure — Azure’s March 2024 exit egress policy
• European Commission: Data Act — entry into force and application dates, cloud switching framework
• EUR-Lex: Regulation (EU) 2023/2854 (Data Act) — switching charge rules and January 12, 2027 deadline
• David Heinemeier Hansson: We have left the cloud — 37signals’ company-reported migration details and savings estimate