2023 and 2024 have seen a wave of high-profile cloud repatriation stories: organizations moving significant workloads from AWS, Azure, and GCP back to owned or collocated infrastructure. The narrative frames this as cloud failure. The reality is more nuanced.
The workloads that leave. The workloads being repatriated share common characteristics: they are steady-state, predictable, and I/O-heavy. Database clusters, data warehouses, and batch processing pipelines that run 24/7 do not benefit from cloud elasticity—they pay for elasticity they never use. When your database cluster has been running at 80% capacity for three years, the premium you pay for on-demand provisioning is pure waste.
The workloads that stay. Conversely, workloads with bursty traffic patterns, geographic distribution requirements, or rapid scaling needs are well-served by cloud. Customer-facing APIs, content delivery, and development environments benefit from the ability to scale up in minutes and down to zero.
Designing for placement. The mature approach is not "cloud first" or "on-prem first"—it is workload placement. Each workload should run where it is most cost-effective and operationally sound. This requires an architecture that abstracts away infrastructure location: containerized deployments, infrastructure-as-code, and monitoring that works across environments.
The procurement context. EU government tenders on TED increasingly specify data residency requirements that make pure-cloud deployments impractical for certain workloads. U.S. federal contracts through SAM.gov reference FedRAMP authorization levels that constrain which cloud services can be used. In both cases, the ability to deploy across hybrid environments—from public cloud to sovereign infrastructure—is not optional; it is a tender requirement.
Organizations that designed for cloud-only find repatriation painful because their architecture assumes cloud-native services. Organizations that designed for placement find it natural because their architecture was already environment-agnostic. The difference is not technical sophistication—it is whether you designed for where you are or for where you might need to be.