What you'll take away
The cloud exit narrative has moved from contrarian thought experiment to mainstream infrastructure conversation. 37signals, Basecamp's parent company, famously repatriated their cloud workloads and reported saving three million dollars annually. A wave of other companies followed with their own repatriation stories. The trade press ran headlines about 'the end of cloud.' Infrastructure Twitter spent six months arguing about it.
Most of the discussion missed the point. Cloud repatriation is not a universal strategy any more than cloud migration was a universal strategy. The companies that successfully reduce costs by repatriating workloads share specific characteristics. The companies that repatriate based on cloud bill sticker shock and don't account for the full cost of running on-premise infrastructure often discover that they've traded a predictable but large cloud bill for an unpredictable and equally large set of capital and operational expenses.
The Conditions Where Cloud Repatriation Makes Economic Sense
High, Predictable, Steady-State Compute
Cloud's economic advantage is elasticity — the ability to pay for variable compute without owning the underlying hardware. If your workload has very little variability — you need approximately the same compute capacity every hour of every day — you are paying the elasticity premium without using the elasticity. A three-year Reserved Instance or Savings Plan reduces the gap, but a dedicated server on a co-location contract for a stable, high-utilisation workload can still be significantly cheaper than cloud compute per hour.
Data Gravity and Egress Costs
Cloud egress pricing — charges for data leaving the cloud provider's network — was designed in an era where most compute was within the cloud. As organisations have accumulated large data estates in cloud storage and multiple consumer applications (some on-premise, some in other clouds) pulling from that data, egress costs can become a significant and growing fraction of the cloud bill. A workload that consumes large volumes of data from a cloud data store and processes it locally has an ongoing egress cost that may justify co-locating the compute with the data — or moving both on-premise.
Compliance and Data Residency
Regulatory requirements that mandate specific data residency, physical control of infrastructure, or audit access to hardware are increasing in several industries and geographies. While the major cloud providers have invested heavily in compliance certifications, some regulatory requirements are genuinely hard to meet in a shared multi-tenant cloud environment. For these workloads, the compliance cost of remaining in cloud may exceed the operational cost of managing dedicated infrastructure.
The 37signals repatriation story is frequently cited but rarely fully understood. Their workloads had very predictable compute requirements, they had strong in-house infrastructure engineering capability, and they moved to dedicated hardware in a co-location facility — not to a traditional on-premise data centre. Most enterprises lack the second condition and confuse the first and third.
Paying for cloud you're not using?
48-hour turnaround. No obligation.
The Costs That Cloud Exit Analyses Routinely Miss
- Hardware refresh cycles: On-premise infrastructure depreciates and requires replacement every 3–5 years. This capital cost often doesn't appear in the first-year comparison against cloud
- Infrastructure engineering headcount: Running your own hardware requires people. Specialists in network engineering, storage, hypervisor management, and hardware troubleshooting who can be repurposed from cloud cost centre work but represent real ongoing salary
- Disaster recovery complexity: Cloud provides cross-region failover as a managed service. On-premise DR requires either duplicate hardware or a colocation contract for a secondary site
- Flexibility premium: Cloud's ability to provision capacity in minutes for unpredictable demand spikes has real business value. Quantify what you'd lose in agility before deciding the flexibility premium isn't worth paying
- Engineering opportunity cost: The engineering time required to manage on-premise infrastructure is time not spent on product development or optimisation
The Workloads Most Likely to Benefit from Repatriation
The workloads where repatriation economics are most favourable: large-scale databases with very consistent access patterns and high storage volumes (where cloud storage and IOPS costs are high); GPU compute for inference serving of models you've already trained (where Reserved/Savings Plan pricing doesn't apply but compute consumption is very predictable); and legacy internal systems with low scalability requirements that exist because business logic is embedded in them, not because they need cloud scale.
The Hybrid Position Most Enterprises Should Be In
The binary cloud-versus-on-premise framing misrepresents how infrastructure decisions actually work in large organisations. Most enterprises should run a portfolio: cloud for variable, spiky, or innovation workloads; co-location or private infrastructure for stable, high-volume, predictable workloads; and a clear decision framework for routing new workloads to the appropriate tier based on their characteristics.
GYSP's Cloud & DevOps Engineering practice helps enterprises conduct cloud exit analysis with full-cost accounting: not just the cloud bill versus the hardware quote, but the total cost of infrastructure ownership including the people, the processes, and the capability trade-offs. The answer is different for every organisation — and sometimes the right answer is to stay in cloud and optimise, rather than to repatriate.
“Cloud exit is not a cost-saving strategy. It's an infrastructure positioning decision. The companies that get it right know exactly what they're optimising for. The companies that get it wrong just know they want a smaller cloud bill.”
— Dhaval Rana, Founder & CEO — GYSP.tech
Frequently Asked Questions
Which workloads benefit most from cloud repatriation?+
Workloads with stable, predictable compute requirements benefit most: batch processing jobs at consistent utilisation, large database workloads with high storage-to-compute ratios, and CPU-bound applications with no burst requirements. Variable, bursty, or globally distributed workloads are poor candidates for cloud exit.
What are the hidden costs of cloud exit that companies underestimate?+
Common underestimates include: hardware procurement lead times (8–20 weeks for enterprise servers), co-location setup and ongoing facility costs, internal operational capability required to manage bare-metal infrastructure, software licensing that no longer includes cloud-native managed services, and migration cost itself — often 30–50% of first-year savings.
How do you calculate whether cloud exit is financially justified?+
Compare 3-year total cost of ownership: cloud (current bill × 3, accounting for growth) vs. repatriated (CapEx amortised over 3 years + co-lo costs + operational headcount + migration cost). A cloud exit is typically justified when the 3-year cloud run rate exceeds repatriated cost by 20%+ AND the workload profile is stable enough to size hardware confidently.
What is the typical timeline for a cloud repatriation project?+
A structured repatriation for 10–20 workloads typically takes 6–12 months: 6–8 weeks for assessment and hardware procurement, 4–8 weeks for co-location setup, 8–16 weeks for phased migration, and 4–6 weeks for production cutover and decommissioning. Projects that skip the assessment phase routinely encounter 2–3× cost overruns.
