Cloud Repatriation: Why Some Companies Are Leaving the Cloud

The Migration That Never Ended

For the better part of a decade, the cloud migration story had a single narrative arc: everything is moving to the cloud, resistance is futile, and on-premises infrastructure is a legacy liability. Amazon Web Services, Microsoft Azure, and Google Cloud Platform grew at extraordinary rates. Enterprise IT strategies were rewritten around “cloud-first” mandates. The question was not whether to migrate, but how fast.

That narrative is not wrong, exactly. Cloud adoption continues to grow in absolute terms, and the hyperscalers continue to post strong revenue growth. But beneath the aggregate numbers, something more nuanced is happening. A meaningful and growing number of organizations — including some that were early and enthusiastic cloud adopters — are moving workloads back to infrastructure they own and operate.

This counter-trend, often called “cloud repatriation,” is not a rejection of cloud computing. It is a maturation of the conversation about where workloads should run, a recognition that the economics of cloud versus owned infrastructure are more complex than the initial migration pitch suggested, and an acknowledgment that for certain workloads, the cloud is simply not the best answer.

The Cost Awakening

The most common catalyst for cloud repatriation is a simple one: the bill.

Cloud computing’s economic promise rests on two pillars. First, it converts capital expenditure (buying servers) to operating expenditure (paying for usage), which simplifies budgeting and removes the need for large upfront investments. Second, it offers elasticity — the ability to scale resources up during demand spikes and down during lulls, paying only for what you use.

These advantages are real, but they come with conditions that many organizations discovered only after years of cloud operation.

Steady-state workloads are expensive in the cloud. The elasticity benefit is most valuable for workloads with highly variable demand. But many enterprise workloads — databases, internal applications, data processing pipelines, AI inference servers — run at relatively consistent utilization levels. For these steady-state workloads, the cloud’s pay-per-use pricing often results in higher total cost than owning equivalent hardware outright. The cloud provider’s margin, overhead, and profit — typically estimated at 30-60% on top of raw infrastructure costs — is paid by the customer every month, indefinitely.

Egress fees accumulate silently. Cloud providers charge for data that leaves their networks — so-called “egress fees.” For organizations that need to move large volumes of data between cloud and on-premises systems, between cloud regions, or to end users, these fees can become a significant cost center that was not anticipated during the migration planning. Egress pricing has been a persistent source of customer frustration and has been cited by multiple organizations as a factor in repatriation decisions.

Cloud cost management is a discipline, not a default. The flexibility of cloud resources means that costs can spiral if not actively managed. Unused instances that remain running, over-provisioned storage, unoptimized database configurations, and the gradual accumulation of cloud services all contribute to what the industry calls “cloud sprawl.” Many organizations found that the operational savings they expected from cloud migration were offset by the ongoing effort required to optimize cloud spending.

The most high-profile case study in cloud repatriation economics came from 37signals, the company behind Basecamp and HEY. The company’s co-founder publicly documented their decision to leave the cloud, reporting that running their own servers would save approximately $7 million over five years compared to continued cloud hosting. While 37signals is a relatively small company, their willingness to publish detailed cost comparisons provided concrete data points that resonated across the industry.

The Data Sovereignty Factor

Cost is the most visible driver of repatriation, but data sovereignty is increasingly the more compelling one — particularly outside the United States.

The European Union’s General Data Protection Regulation (GDPR) and its evolving interpretations have created legal complexity around where data can be stored and processed. The Schrems II decision, which invalidated the EU-US Privacy Shield framework, raised questions about whether European organizations can lawfully store personal data on servers controlled by US-headquartered cloud providers, even if those servers are physically located in Europe. The concern is that US law — particularly the CLOUD Act — could compel US companies to provide access to data stored abroad.

This legal uncertainty has pushed some European organizations to move data-intensive workloads to infrastructure they control directly, where they have unambiguous jurisdiction over the data. Several European countries have launched sovereign cloud initiatives — government-backed cloud infrastructure operated by domestic companies, designed to keep sensitive data under national legal jurisdiction.

The data sovereignty motivation extends beyond Europe. China has long required that data about Chinese citizens remain within Chinese borders. India, Brazil, Indonesia, and other major economies are implementing or considering similar data localization requirements. For multinational organizations, these requirements create a patchwork of compliance obligations that can be easier to manage with owned infrastructure in each jurisdiction than with a cloud provider’s multi-region architecture.

The Performance Argument

For certain workloads, owned infrastructure offers performance characteristics that are difficult or expensive to replicate in the cloud.

Latency-sensitive applications benefit from dedicated hardware that is physically close to the users or systems it serves. While cloud providers offer edge computing options, dedicated on-premises infrastructure eliminates the variable latency introduced by shared networks and multi-tenant environments.

AI training and inference workloads represent a growing category where on-premises hardware can offer better economics. GPU clusters for AI workloads are expensive to rent in the cloud, and the supply constraints on high-end GPUs through 2024 and 2025 made cloud GPU capacity both scarce and costly. Organizations with sustained AI compute needs — those running training jobs or inference servers at consistent utilization — often find that purchasing GPUs outright yields better cost-per-compute than cloud rental, particularly over a three-to-five-year hardware lifecycle.

High-throughput data processing workloads — log analytics, real-time data pipelines, large-scale batch processing — can be substantially cheaper on owned hardware, where storage I/O is not metered and network bandwidth between systems is effectively free. In the cloud, the combination of storage IOPS charges, network transfer fees, and compute costs for these workloads can be punitive.

The Hybrid Reality

The cloud repatriation narrative is often framed as a binary: cloud versus on-premises. The reality is more nuanced. Most organizations engaging in repatriation are not abandoning the cloud entirely. They are adopting hybrid architectures that place workloads on the infrastructure best suited to their characteristics.

The typical pattern involves keeping certain workloads in the cloud while bringing others back.

Cloud-suitable workloads include applications with highly variable demand patterns, development and testing environments that spin up and down frequently, global applications that benefit from the cloud provider’s worldwide footprint, and services that leverage cloud-native capabilities like managed databases, serverless functions, or AI APIs that would be costly to replicate independently.

Repatriation candidates include steady-state production workloads with predictable resource requirements, data-intensive workloads with high storage and network costs, workloads with data sovereignty requirements, and applications where the organization needs fine-grained control over the infrastructure for security, compliance, or performance reasons.

This hybrid approach is pragmatic rather than ideological. It acknowledges that cloud computing offers genuine advantages for certain use cases while recognizing that those advantages do not apply universally.

The Infrastructure Renaissance

Cloud repatriation has contributed to a broader renaissance in on-premises and colocation infrastructure.

The colocation market — where organizations place their own hardware in third-party data centers that provide power, cooling, and network connectivity — has experienced renewed growth. Colocation offers a middle ground between fully owned data centers and cloud computing: the organization controls its hardware and software stack, while the colocation provider handles the physical infrastructure challenges of power, cooling, physical security, and network connectivity.

Hardware vendors have responded to the repatriation trend by developing products specifically designed for hybrid deployments. AWS Outposts, Azure Stack, and Google Distributed Cloud bring cloud-like management interfaces and APIs to on-premises hardware, allowing organizations to use familiar cloud tools and practices while running on infrastructure they control. These products represent the hyperscalers’ acknowledgment that not all workloads belong in the public cloud — and their strategy for maintaining relevance even when customers bring workloads back.

The server market has also benefited. Dell, HPE, Lenovo, and Supermicro have all reported increased demand for enterprise servers, particularly AI-capable configurations with high-end GPUs. Organizations that once expected to run all their infrastructure in the cloud are now purchasing hardware again — but with the operational practices and automation tools they learned from their cloud experience.

What the Hyperscalers Are Not Telling You

Cloud providers have a financial incentive to keep workloads in the cloud, and their messaging reflects this. The standard response to cloud cost concerns is that organizations need to optimize their cloud usage — right-sizing instances, purchasing reserved capacity, adopting spot instances, using cost management tools. This advice is valid but self-serving. It implicitly assumes that the cloud is always the right platform and that any cost issues are a customer optimization problem rather than a structural pricing problem.

The structural reality is that cloud providers operate with significant margins. AWS has consistently reported operating margins in the range of 25-35%. These margins are the premium that customers pay for the convenience, flexibility, and managed services that the cloud provides. For workloads where that convenience is essential, the premium is justified. For workloads where it is not, the premium is simply a tax.

Cloud providers have also made it operationally difficult to leave. Data gravity — the tendency for applications and services to cluster around where data is stored — creates inertia that increases with the volume of data in the cloud. Egress fees impose a direct financial cost on data removal. Proprietary managed services — Lambda, DynamoDB, BigQuery — create dependencies that are costly to replicate on other platforms. These lock-in mechanisms are not accidental; they are features of the business model.

The Decision Framework

For organizations evaluating whether to repatriate workloads, the decision framework is straightforward in principle but complex in execution.

Calculate the true total cost of ownership. Cloud costs should include not just compute and storage but egress, managed service fees, support contracts, and the labor cost of cloud optimization. On-premises costs should include hardware purchase, depreciation, power, cooling, network, physical space, and the operational staff to manage the infrastructure. The comparison should span a three-to-five-year horizon to capture hardware refresh cycles.

Assess the value of cloud-specific capabilities. Some organizations use cloud features that are genuinely difficult to replicate — global content delivery, managed AI services, serverless architectures, elastic scaling for consumer-facing applications. If these capabilities are central to the workload, repatriation may sacrifice more than it saves.

Evaluate the operational capability gap. Running on-premises infrastructure requires skills — hardware management, networking, security, capacity planning — that organizations may have shed during cloud migration. Repatriation without the operational expertise to manage owned infrastructure can result in worse reliability and higher costs than the cloud.

Factor in strategic considerations. Data sovereignty requirements, regulatory compliance, supply chain resilience, and long-term vendor dependency are strategic factors that may outweigh short-term cost comparisons.

The Pendulum Finds Its Center

Cloud repatriation is not the end of cloud computing. The public cloud market will continue to grow, driven by new workloads, new companies that start in the cloud by default, and the genuine advantages that cloud infrastructure offers for appropriate use cases.

But the uncritical “everything to the cloud” era is ending. It is being replaced by a more sophisticated understanding of infrastructure economics — one that treats the cloud as one option in a portfolio rather than the inevitable destination for all workloads.

The organizations that navigate this transition well will be those that make placement decisions based on workload characteristics, cost analysis, and strategic requirements rather than ideological commitment to any single infrastructure model. The cloud was never the answer to every infrastructure question. The maturation of cloud repatriation simply reflects the industry catching up to that reality.