Infrastructure · Cloud strategy

Cloud Repatriation: Why Workloads Are Moving Back — and When Yours Should

For a decade, “move it to the cloud” was the default answer to almost every infrastructure question. In 2026 that reflex has given way to a more careful one, as organisations look at their cloud bills and ask which workloads genuinely benefit from renting someone else’s hardware and which are simply paying a premium for it. The result is cloud repatriation — and the data shows it is real, large, and selective. This guide covers what is driving it, who has done it, what belongs where, and how to run the decision honestly rather than swinging from one dogma to another.

What is cloud repatriation?

Cloud repatriation, sometimes called reverse cloud migration, is the strategic movement of applications, data, and workloads from public cloud platforms like AWS, Azure, and Google Cloud back to private cloud, on-premises data centres, colocation, or bare-metal infrastructure. The key word is strategic: this is about putting specific workloads where they run best, not rejecting cloud wholesale.

The scale is striking but easy to misread. A Barclays CIO survey found 86 percent of CIOs planning to move at least some workloads off public cloud — the highest figure ever recorded, up from around 43 percent in late 2020 — and IDC reports roughly 80 percent of organisations expecting to repatriate some compute or storage within a year. Yet only about 8 percent are pursuing full cloud exits, and public cloud spending keeps growing past $700 billion a year. Both facts are true at once because the movement is a rebalancing toward hybrid, not a stampede for the exit.

Why are companies repatriating?

Cost is the dominant force, and it is structural rather than incidental. The pay-as-you-go model that makes cloud attractive for unpredictable work becomes expensive for steady work, and the bill is hard to forecast: storage tiers, API charges, cross-region transfer, and especially data egress accumulate in ways procurement rarely anticipates. Surveys consistently find managing cloud spend is the single biggest cloud challenge, with a large share of spend wasted on idle resources. For software companies, the Andreessen Horowitz “Cloud Paradox” analysis put cloud at roughly half of cost of revenue, a direct drag on margins.

Three more drivers sit alongside cost. Performance: multi-tenant cloud brings noisy-neighbour variability that dedicated hardware avoids, which matters for databases, real-time systems, and low-latency work. AI economics: cloud GPUs can run 50 to 70 percent more expensive than owned equivalents, and steadily utilised GPU servers pay back in roughly a year, so AI is pushing teams to optimise everywhere. And compliance: data-residency and sovereignty rules — including the GDPR-versus-CLOUD-Act conflict covered in our CLOUD Act explainer — increasingly make owned, in-country infrastructure the simpler path.

The cost math: why steady workloads got expensive

The economics turn on predictability. Cloud charges a premium for elasticity — the ability to scale up and down on demand — and that premium is excellent value when your load genuinely varies. When your load is steady, you are paying for flexibility you never use. For a database that runs at a constant size, a batch job on a known schedule, or storage that grows linearly, the elasticity proposition evaporates and the lower-cost option becomes owning the hardware: internal analyses cited by repatriating firms put private infrastructure at 40 to 50 percent lower total cost of ownership for steady-state workloads.

Egress fees deserve special attention because they do double damage. They inflate the running bill, and they create “data gravity” — the more data you store, the more expensive it becomes to leave, which is lock-in by another name. Moving a single petabyte out of S3 can cost between $90,000 and $120,000, and egress can account for as much as 90 percent of a large monthly bill. When 37signals left AWS, the provider reportedly waived a quarter-million dollars in egress fees, which tells you both that the penalty is steep and that it is somewhat arbitrary. Any honest cost comparison has to include the price of getting your data back out.

# Steady-state workload, illustrative 3-year total cost of ownership
PUBLIC CLOUD   compute + storage + egress + transfer … rising OpEx
               + annual price increases + idle waste (~27%)
 
OWNED / COLO   hardware (CapEx, amortized) + rack + power + staff
               + one-time migration & egress-to-leave … flat after yr 1
 
# The flip happens when load is PREDICTABLE. Classify before you cost:
steady DB / linear storage / known batch  -> repatriation usually wins
spiky / seasonal / 10000%-for-one-hour     -> cloud elasticity still wins

The case studies: 37signals, Dropbox, GEICO

The trend has documented proof points rather than just survey sentiment. The most cited is 37signals, the company behind Basecamp and HEY, which left AWS in 2022. After an annual cloud bill in the region of $3.2 million, the team invested roughly $600,000 in their own Dell servers — hardware that reportedly paid for itself in under six months — and cut their annual infrastructure spend dramatically, projecting savings of around $7 million or more over five years while running petabytes of data on owned storage. Co-founder David Heinemeier Hansson’s blunt summary was that renting computers is a bad deal for a medium-sized company with steady growth.

The pattern repeats at different scales. Dropbox ran the original repatriation with its “Magic Pocket” project between 2013 and 2016, moving the bulk of its data off AWS to custom colocation and reportedly saving about $75 million over two years while lifting gross margins from the low thirties into the mid-sixties. GEICO offers the cautionary mirror image: after a decade migrating hundreds of applications to the cloud and watching costs climb roughly two and a half times to over $300 million a year, it is now building private cloud infrastructure and targeting major per-core cost reductions. The common thread is scale and steadiness — once workloads are large, predictable, and storage-heavy, owning starts to look very different from renting.

What to repatriate — and what to keep in the cloud

Repatriation is a workload decision, not an all-or-nothing one, and the classification is fairly clear. The strong candidates to move back are steady-state and predictable workloads: databases that do not autoscale, batch jobs on known schedules, storage that grows linearly, anything with high consistent I/O or strict low-latency needs, GPU workloads running above roughly 60 to 70 percent utilisation, and data bound by residency or sovereignty rules. For these, owned infrastructure is usually both cheaper and faster.

Just as important is what should stay. Variable and bursty workloads — consumer apps with unpredictable traffic, seasonal e-commerce, early-stage products still finding their shape — are exactly what cloud elasticity is for, and paying the premium makes sense there. Globally distributed front ends benefit from cloud reach, and fast-moving teams gain real velocity from managed Kubernetes, CI/CD, and infrastructure-as-code. As the saying goes, if your traffic spikes ten-thousand-fold for one hour a year, the cloud is still the right home for it.

Compliance and sovereignty as a driver

Cost gets the headlines, but regulation is increasingly the reason a repatriation decision becomes non-negotiable. A large share of IT leaders — well over half in recent surveys — now report needing to run infrastructure within a single country, driven by tightening data-protection laws and the recognition that data residency in a US-controlled cloud does not equal legal control over the data. The clash between GDPR and the US CLOUD Act is the sharpest example: data held by a US-owned provider can be reached by US legal process regardless of where it physically sits, a problem that owned, locally controlled infrastructure sidesteps entirely.

The practical difference is that you can negotiate with a vendor but not with a regulator. Compliance frameworks increasingly demand documented, auditable control over where data lives and who can access it — promises in a vendor contract are not the same as architectural certainty. The regulatory direction is only tightening: the EU Data Act, in force since September 2025, explicitly targets unlawful foreign-government access to data held in the bloc, and analysts expect the great majority of large enterprises to adopt formal digital-sovereignty strategies within a few years. For organisations in healthcare, finance, government, or any sector with residency mandates, repatriating sensitive workloads to infrastructure they own and control turns a recurring compliance headache into a settled and audit-ready fact — one that is clearly defensible to a regulator on its own terms — which is often worth more than the cost savings on its own.

How do you actually repatriate?

A real repatriation is a structured project, and it starts with cataloguing. Inventory your cloud workloads and classify each one by compute pattern (steady versus variable), data gravity (volume and egress cost to move), regulatory requirements, dependency on cloud-specific managed services, and whether your team can operate it outside the cloud. That inventory tells you which workloads are candidates and which should stay, before any money is spent.

From there, build a genuine total-cost-of-ownership model over three to five years — hardware or colocation, staffing, power, cooling, network, and the one-time cost of migration including egress — and compare it against projected cloud spend with expected price rises. Then choose a destination: dedicated bare metal for raw cost and performance, colocation for control without running a building, or a private cloud such as upstream Kubernetes on bare metal, where the application layer stays unchanged and only the infrastructure shifts — a pattern our Kubernetes on bare metal guide covers. Sequence the migration to move low-risk, high-savings workloads first, and build the operational tooling before you need it.

The honest costs of moving back

Repatriation is not a weekend migration, and pretending otherwise is how it goes wrong. The cloud abstracts away an enormous amount of operational work, so bringing workloads home means rebuilding capabilities you may have lost: you need people who understand Linux, networking, and server management, and you need automation, monitoring, and on-call processes. Teams that repatriate without reinvesting in operations frequently end up worse off than they were in the cloud, having traded a high bill for high fragility.

There are financial frictions too. Repatriation shifts spending from flexible pay-as-you-go toward capital expenditure or fixed leases, which changes your cash-flow profile, and the egress fees that make staying expensive also make leaving expensive — you pay to get your own data out. None of this argues against repatriation; it argues for doing the arithmetic with clear eyes. The organisations that win are not the all-cloud or all-on-prem zealots but the ones that can calculate total cost of ownership accurately and act on it. Our bare-metal versus cloud guide works through that comparison in detail.

Is repatriation right for you?

The honest answer is that it depends entirely on your workloads, and the decision should fall out of the classification rather than a preference. If you run large, steady, data-heavy, or regulated workloads and have or can build the operational capability, repatriation will very likely save money and improve control. If your workloads are variable, global, early-stage, or genuinely elastic, the cloud is probably still the right home, and moving them back would trade flexibility for fragility to chase savings that are not there.

Most organisations land in the middle, which is why hybrid has become the default — keep what the cloud does well in the cloud, and bring home what you are simply renting at a premium. For the steady workloads that belong on owned infrastructure, a Canadian bare-metal option such as our dedicated servers in Toronto offers predictable pricing and in-country control, and the Canadian hosting market and green hosting guides cover the wider landscape. Run the numbers over three to five years, classify honestly, and let each workload earn its place.