
What Cloud Repatriation Reveals About Modern Cloud Migration Strategy
In October 2022, David Heinemeier Hansson (DHH) announced that 37signals was leaving the cloud. The decision quickly became a case study in cloud migration strategy, raising a question many enterprises are now asking: does every workload belong in the public cloud?
By May 2025, The Register reported that 37signals was migrating its last workload off AWS S3 and planning to delete the account entirely. The projected savings were large enough that the tech industry noticed, and then mostly dismissed them. Critics argued that 37signals was too specific to generalise: a mid-sized SaaS company with stable, predictable workloads.
Yet that objection misses the broader point.
Most enterprises have at least some workloads that look remarkably similar. Maybe not at the company level, but buried in the workload mix: a reporting job that runs nightly, a database that handles predictable query volume, or an internal application that got migrated because the mandate said everything goes to the cloud.
None of these needed an elastic cloud migration strategy. They needed infrastructure that ran reliably at a known cost. They effectively paid for cloud flexibility that they rarely needed to use.
The bill that took eight years to arrive
Most large enterprises running on the public cloud in 2026 migrated their workloads between 2017 and 2022. The pitch was compelling, and the mandate came from the top: cloud-first, then cloud-only for new projects. What got less scrutiny was whether “cloud-first” meant the same thing for a database that has run the same query patterns for six years as it did for a startup that might triple its user base overnight.
It doesn’t. Flexera’s 2025 The State of the Cloud report found roughly one-fifth of workloads originally moved to the public cloud have already come back, 21% repatriated. IDC’s Cloud Pulse survey found that 59% of organisations anticipated cloud budget overruns to continue into 2024. Eighty-four percent of organisations named cloud spend as their single biggest infrastructure challenge, according to Flexera’s 2025 report. These organisations were not necessarily making incorrect decisions. They applied a rational framework to the wrong category of workload, and the invoices took long enough to accumulate that by the time the pattern was obvious, the migration was already complete.
The workloads that were lift-and-shifted rather than redesigned for the cloud are the expensive ones. They’re paying for elasticity on infrastructure that doesn’t flex. GEICO is one documented example: it rebuilt repatriated workloads on a private cloud running OpenStack and Kubernetes after discovering the architecture mismatch.
Lift-and-shift migrations often introduce architectural debt. Some organisations are addressing it through re-architecture, while others continue to absorb the associated operational costs.
What the repatriation numbers actually mean
The Barclays CIO Survey found 83% of enterprises planned to move workloads from the public cloud back to private or on-premises solutions, up from just 43% in 2021, the highest rate ever recorded. That number gets cited as an anti-cloud signal. It isn’t, quite.
Only 8% of organisations plan a full cloud exit. IDC reports that 67% of enterprises have already repatriated some workloads, with 87% planning to do so within two years. The operative word is “some.” Stable databases and regulated data are coming back. AI training workloads with GPU requirements are coming back. New applications with uncertain traffic, globally distributed services, and rapid prototyping cycles are staying. The cloud migration strategy question most enterprises are now working through is more specific than “are we in the cloud?” It’s which parts of what they built over the last eight years should have gone there in the first place.
Gartner projects that 40% of enterprises will run hybrid compute architectures for mission-critical work by the end of 2026, up from 8% in prior years. Hybrid architectures were once viewed as a transitional phase. Increasingly, organisations are treating them as a long-term operating model.
The sovereignty problem nobody budgeted for
Repatriation press releases tend to cite cost. The internal conversations that preceded them often didn’t start there. Regulatory compliance has become an increasingly important consideration in cloud migration strategy decisions.
IDC research VP Natalya Yezhkova put the structural issue plainly: “CIOs should be reassessing whether the public cloud is delivering value because the needs of workloads change, regulations around workloads change, and offerings change, whether in price or in functionality.” The regulatory piece has shifted substantially since 2022. GDPR enforcement has teeth it didn’t have during the original migration wave. The EU AI Act imposes data residency requirements on the processing of AI models. Sector-specific rules in healthcare and financial services have made “where is this data physically stored” an audit question, not just a preference.
Microsoft launched Sovereign Cloud capabilities in February 2026 for AI models running fully disconnected from public cloud infrastructure. The introduction of such offerings reflects growing enterprise demand for greater control over workload placement, data residency, and regulatory compliance. The cloud migration strategy that made sense in 2019 didn’t account for regulatory environments that would emerge between 2023 and 2026. Most five-year cloud strategies don’t.
Distilled
DHH argued that renting infrastructure only makes sense when you need flexibility. The broader enterprise market is increasingly reaching a similar conclusion. As cloud costs rise and regulatory requirements become more complex, organisations are reassessing whether every workload belongs in the public cloud.
What’s changing in 2026 is not a retreat from the cloud. It is a retreat from the assumption that every workload belongs there. Stable, predictable, and regulated workloads are increasingly being evaluated for private or hybrid environments, while the cloud remains the preferred platform for scalability, experimentation, and rapid deployment.
The real question is no longer whether to use the cloud, but which workloads belong there, and which never did.