The public cloud was supposed to be the indisputable future of IT. Yet a growing wave of reverse migration shows the story is not quite so simple. More and more companies are moving workloads out of the cloud and back to on-premises hardware.

Flexera’s 2025 State of the Cloud report found organizations had already repatriated about 21% of their cloud workloads. Yet overall public cloud spending continued to grow because new workloads moving in outpaced those moving out.

IDC found a similar pattern: A full 81% of organizations expected some compute repatriation and 83% some storage repatriation, but only about 7% planned to repatriate an entire workload. Uptime Institute likewise concluded that repatriation is real but often overstated, with higher-than-expected cloud costs the leading reason applications move out of the public cloud.

The trend is becoming especially visible around AI, where growing AI security and governance concerns are accelerating the shift.

Let’s discuss the most common reasons behind that shift — and why, for the right workload, moving back on-premises is not a retreat, but a deliberate architectural choice.

The Dark Side of Cloud Costs

Zero upfront investment in cloud infrastructure looks attractive, especially with a pay-as-you-go model. But is it always as cost-effective as it seems?

Costs can grow across multiple areas: compute, storage, bandwidth, managed services, and data transfer. Egress fees, in particular, can become an unpleasant surprise for companies working with large volumes of data.

But that is not the whole story. Organizations often use reserved capacity or longer-term commitments to ensure predictable access to resources. If actual usage falls below those commitments, they may end up paying for capacity they do not fully use.

Companies seeking greater long-term cost predictability are shifting back toward CapEx by buying and owning infrastructure instead of relying on open-ended OpEx. It trades flexibility for control: no surprise price increases, no per-request billing, and no reserved capacity guesswork. That tradeoff does not make sense for every workload. Bursty, short-lived, or highly variable workloads can still benefit from paying only for what they use. But for steady, predictable, always-on services, the economics can increasingly favor owning the hardware.

That is exactly what caught up with Basecamp/37signals. In 2022, the company spent $3.2 million on AWS — nearly a million of that just on S3 storage for 8 petabytes of files, replicated across regions for resilience. CTO David Heinemeier Hansson calculated that roughly half a million dollars in new Dell hardware would be enough to bring the company’s core applications home, projecting $7 million in savings over five years—without adding a single person to the ops team.

Performance Problems

How confident are you that cloud infrastructure will deliver consistent performance?

Shared cloud infrastructure is efficient, but some resources are still shared. Under heavy load, this can introduce performance variability, especially for workloads that depend on consistent I/O, compute, memory, or network throughput. AWS itself notes that shared resources can produce greater performance variance.

The noisy neighbor effect is one example. When one tenant or workload consumes a disproportionate share of a shared resource, others can experience degraded performance. Cloud platforms use isolation, scheduling, throttling, and resource guarantees to limit this effect, but it remains a consideration in shared environments.

Geography matters as well. The farther applications, data, and users are from the selected cloud region, the more network latency can affect response times. Cloud providers therefore recommend placing resources close to users and dependent services when latency matters.

Cybersecurity Risks

Public clouds are multi-tenant environments, which means customers share underlying infrastructure while relying on strong logical isolation between workloads. That model is well established, but isolation failures, misconfigurations, excessive permissions, and exposed services can still create serious security risks. Catching these issues before attackers do increasingly depends on AI for asset intelligence. Most security teams still rely on fragmented, tool-by-tool visibility, and AI today is shrinking the window between a flaw surfacing and someone exploiting it.

Another concern is software supply chain compromise. Attackers may target third-party dependencies, CI/CD systems, container images, or managed services to gain access further downstream. SCA tools and software supply chain security tools help flag vulnerable or tampered dependencies, and DevSecOps tools bring those checks into CI/CD pipelines. But tooling does not settle who is responsible for what: in cloud environments, the shared responsibility model can make ownership less obvious if organizations do not clearly define which security controls belong to the provider and which remain the customer’s responsibility.

Encryption control is another gap. Cloud providers often manage keys through centralized systems, and customers sometimes cannot layer in deeper protections like dedicated hardware security modules (HSMs) on top.

For organizations where security is non-negotiable, the response has been a shift toward zero-trust architectures, on-premises storage for the most sensitive data, and security tooling they control directly — rather than tooling and key management inherited from a provider’s shared infrastructure.

Vendor Lock-In

Cloud vendor lock-in can start gradually and become difficult to unwind over time. Proprietary APIs and managed services are convenient, but the deeper they become embedded in an application architecture, the harder migration can become without refactoring code or redesigning integrations. Managed databases, for example, may rely on provider-specific features, replication models, or operational tooling that do not map cleanly to alternatives.

Moving data can also be expensive and technically complex. Data transfer charges may apply, while platform differences can require format conversion, integrity testing, and database migration work.

Organizations that want greater portability often turn to open source technologies, containers, Kubernetes, or abstraction layers to reduce dependence on a single provider. These approaches do not eliminate lock-in, but they can make future migration easier.

Dropbox is a useful example. The company had relied heavily on Amazon S3 for file content, but in 2013 it began building its own storage platform, Magic Pocket. The migration accelerated in 2015, and by October of that year Dropbox was serving more than 90% of user data from its own infrastructure. The company said the move gave it greater control over performance and unit economics, while AWS continued to play a role in its broader hybrid architecture.

Downtime and Resilience

Cloud provider guarantees can look reassuring, but actual application availability depends on much more than the provider SLA. Reliability also depends on architecture, configuration, redundancy, and how the application itself handles failures. Microsoft describes cloud reliability as a shared responsibility: the provider supplies resilient infrastructure and services, while customers still need to design workloads for their own availability targets.

Cloud environments provide autoscaling, load balancing, replication, and other resilience mechanisms, but their effectiveness depends on how you configure them. A workload deployed across multiple zones can tolerate failures better than one concentrated in a single zone, and regional outages may require a separate disaster recovery strategy.

Application architecture matters as well. Stateful systems can require more complex recovery because data consistency, replication, and failover have to be handled correctly, while stateless applications are generally easier to restart or replace.

For organizations that require highly predictable recovery behavior, private cloud, dedicated infrastructure, or hybrid environments can provide greater control over failover and recovery procedures. But local infrastructure is not automatically more resilient. The advantage comes from having more direct control over how you design redundancy, recovery, and operations.

Where Cloud Adoption Outpaces Team Skills

Cloud technology is powerful, but mastering it is harder than most rollout plans admit. When a team lacks the right skills, or the appetite to keep learning after the first few painful lessons, repatriation stops looking like a retreat and starts looking like the obvious next step. Here is where teams actually get stuck:

Every provider has its own APIs, consoles, and management logic. Juggling several at once multiplies the chances of confusion and mistakes.

Access control, encryption, and monitoring all demand real depth. Add compliance on top, and “good enough” stops being an option.

Cloud migration only saves money if you have the resources to manage it properly: continuous monitoring, scaling configuration, instance management. Skip that investment, and the bill will remind you.

The cloud does not tune itself. Getting network, storage, and server configuration right takes real expertise, and getting it wrong shows up fast, in performance complaints from actual users.

Infrastructure evolves faster than most teams’ skills can keep up. Continuous retraining, even in a microlearning format, is not just hard for smaller teams. It competes directly with the work those teams are already struggling to keep up with, and it costs the organization too.

That gap is exactly why many organizations choose repatriation. Running systems your team already knows is simpler, and it saves money, time, and a lot of on-call stress.

When Legacy Applications Refuse to Cooperate

Cloud migration can become difficult when legacy or highly customized applications were never designed for distributed infrastructure.

Classic monolithic applications may depend on local state, fixed networking, specific operating systems, or tightly coupled components. Moving them to the cloud can require significant refactoring rather than a simple lift-and-shift.

Custom software can create similar problems. Some applications depend on specialized hardware, proprietary databases, licensing models, or low-latency connections that are difficult or expensive to reproduce in a public cloud environment.

Performance can also become less predictable when an application was designed around dedicated hardware or very specific storage and network characteristics.

For these workloads, keeping them on-premises or moving them back can provide greater control and reduce migration complexity. But repatriation makes sense only when the existing environment can deliver the required reliability, security, and operational support.

Cloud Repatriation Is a Placement Decision

When a company moves workloads back on-premises, it is easy to read that as a step backward. Look at it differently. The company adopted cloud because it fit the business at the time. The strategy has since evolved, and repatriation is simply the next logical move, not a reversal.

This is not a mistake. It is adaptation. If a workload has gotten too expensive to run on public cloud, why not move it somewhere with predictable costs? If performance is not meeting expectations, why not take full control of the resources underneath it? If security raises more questions than it answers, why not minimize that risk with infrastructure you own?

None of this means walking away from the cloud. It means being honest about which workloads actually belong there. The steady, predictable, tightly regulated ones often do not need elasticity; they need control. The bursty, fast-moving, globally distributed ones still do, and that is exactly where public cloud keeps winning. Companies are realizing that following the trend and serving the actual business are not always the same thing. Repatriation is not a rejection of the technology. It is a push toward efficiency, control, and using each part of the infrastructure for what it is actually good at.