Cloud repatriation
How to tell whether moving workloads off AWS, Azure or Google Cloud will save money, what to count, what to keep in the cloud, and how to move safely.
Updated
The short answer
Cloud repatriation means moving workloads from a public cloud back to servers you own or rent. It tends to pay off for steady, predictable workloads, especially ones that store or send a lot of data. It tends not to pay off for spiky workloads or ones built deeply on a provider's managed services.
It is rarely all or nothing. Most teams should compare one workload at a time.
Good candidates, and what to leave
| Good candidates to move | Usually better left in the cloud | |
|---|---|---|
| Load | Steady and predictable, running around the clock | Spiky or seasonal, or idle for most of the time |
| Data | Large volumes stored, or high outbound traffic | Small datasets with little traffic |
| Architecture | VMs, containers and open-source databases | Heavy use of proprietary managed services |
| Location | Users near a site you can use | Users spread across many regions |
| Team | People who can run servers, or a partner who can | No operations capacity, and no plan to add it |
What to count
Comparing a cloud invoice with a server quote will mislead you. Count all of this over three to five years:
- Today's full cloud cost for that workload, including storage, traffic, support and any commitments you cannot exit.
- Hardware or rental, with enough spare capacity for failures and growth.
- Space, power and connectivity, at your site or a colocation provider.
- People, which is the line most often left out.
- Software, including anything your provider used to bundle, such as monitoring.
- The move itself: engineering time, running both sides in parallel, and data transfer.
What one company reported
37signals, the company behind Basecamp and HEY, is the best-known public example. It reported cutting its yearly cloud bill from $3.2 million to about $1.3 million after moving compute to its own servers, with the rest being Amazon S3. It later bought about $1.5 million of storage hardware to leave S3 as well, and has said the full exit should save more than $10 million over five years.
These are the company's own figures. It also had a very steady workload and engineers who already knew how to run servers, so treat it as proof that this can work, and not as a forecast for your bill.
Data transfer costs are changing in the EU
Egress fees have often been the obstacle. Under the EU Data Act, from 12 January 2027 cloud providers may no longer charge switching charges, which include data egress charges, when a customer switches provider or moves to on-premises infrastructure. Until then they can charge only reduced fees.
The rule covers the act of switching, and ordinary service fees are not switching charges. Exceptions have been proposed for some custom-built services, so confirm how it applies to your contract. Outside the EU, ask your provider directly: AWS, for example, has offered a free egress window for customers who are leaving.
How to move safely
- Pick one workload, and measure what it really costs and uses today.
- Order hardware early, because lead times can be the longest part of the plan.
- Set up networking between the cloud and your servers.
- Rebuild the workload with automation, not by hand.
- Replicate the data, and run both sides in parallel.
- Switch a small share of traffic, then the rest, and keep a route back.
- Shut down the cloud resources only after a full billing cycle, and compare real costs.
Keeping the cloud experience
What teams miss most after leaving is self-service. CloudOps gives servers you own or rent VMs, Kubernetes, private networks, load balancers and S3-compatible storage, from a console, an API and Terraform, and we run the control plane as a service.
It does not replace everything a public cloud offers. CloudOps has no live migration between hosts and no automatic VM restart on another host, you cannot install the control plane yourself, and managed databases are still in preview.
More detail: moving workloads to your own servers with CloudOps.