| Myth | Reality |
|---|---|
| Repatriation means “leaving the cloud entirely” | Uptime Institute data shows most repatriating firms keep 50-60% of workloads in public cloud; they move specific steady-state services, not everything |
| It’s always cheaper to own hardware | Ownership only wins for predictable, long-lived, high-utilization workloads; bursty or short-lived workloads usually still favor cloud |
| Compute is the main cost driver behind repatriation | Egress fees, storage growth, and idle reserved capacity are the more common triggers cited in Barclays’ CIO surveys |
| Repatriation is quick — just copy the VMs back | 37signals’ project ran from October 2022 into 2025; hardware procurement, data migration, and re-architecture take 18-36 months |
| Only large enterprises repatriate | Mid-market SaaS companies with 10-50TB of steady storage report some of the highest percentage savings, because their bills are dominated by storage and egress, not burst compute |
What Cloud Repatriation Actually Means
Cloud repatriation is the process of moving a workload — an application, a database, a storage tier, or an entire service — from a public cloud provider back to infrastructure the organization controls directly: a company-owned data center, a leased colocation cage, or a private cloud built on owned hardware. It is not the opposite of cloud adoption and it rarely means an organization is “leaving the cloud.” In nearly every documented case, repatriation is selective. A company keeps its bursty, globally distributed, or experimental workloads in public cloud and pulls back only the workloads that have become large, predictable, and expensive to run at cloud list prices.
The distinction matters because the trade press headline — “company ditches the cloud” — almost never matches the underlying architecture decision. 37signals, the company behind Basecamp and HEY, is the most cited recent example, and even its own engineering blog describes the move as buying owned hardware for steady-state compute and storage while continuing to use managed cloud services where they make sense. The pattern shows up across the broader cloud computing market’s 2026 direction: less “cloud-only by default,” more workload-by-workload placement decisions driven by unit economics.
The Data: How Many Companies Are Actually Repatriating
Survey data on repatriation intent is easy to find and easy to misread. The widely quoted Barclays CIO Survey found that 83% of enterprise IT leaders in 2024 said they planned to shift at least some workloads from public cloud to on-premises or private infrastructure, up from 43% in 2021, and a subsequent Q4 2024 round put the figure at 86%. Those numbers describe intent, not completed migrations, and they say nothing about what share of total workloads is involved.
Uptime Institute’s operator surveys give a better read on actual movement. Their research found that 33% of organizations have moved at least one production application from public cloud back to owned data centers or colocation. Uptime also tracks the broader workload-placement trend: the share of enterprise IT workloads hosted in corporate data centers fell from 58% in 2020 to 48% in 2023, with survey respondents forecasting roughly 43% by 2025 — a slower decline than the “everything moves to cloud” narrative from a decade ago implied, and one that partially reverses in specific accounts through repatriation. Uptime’s own analysts have pushed back on the loudest repatriation headlines, noting that “cloud repatriation is overstated” as an industry-wide trend even while acknowledging it is real and growing at the account level.
Context on the underlying cost pressure comes from Andreessen Horowitz’s widely debated 2021 analysis, “The Cost of Cloud, a Trillion Dollar Paradox,” which found that public companies’ cloud infrastructure spend averaged roughly 50% of cost of revenue, with some running as high as 75-81% of COR. The a16z model assumed a 50% cloud-spend reduction from repatriation and projected roughly $100B in recovered market value across the software sector it sampled. Critics — including cloud cost specialists at CloudZero and others — correctly note the model ignores the operational cost of running hardware, but the underlying observation (cloud spend scales with revenue in a way owned infrastructure does not) is the reason the debate keeps recurring. For a sense of how cloud spend has scaled across the industry, see cloud-based software adoption data for 2025.
Figure 1: The Cloud vs. Owned-Infrastructure Cost Curve
A line chart with two curves plotted against workload utilization over 36 months. The public-cloud curve starts near zero and rises linearly with usage — pay-as-you-go, no upfront cost, cost scales directly with consumption including egress and IOPS charges. The owned-infrastructure curve starts high (capital outlay for servers, storage arrays, network gear, and colocation setup fees) and stays nearly flat as utilization increases, because the hardware is already paid for. The two curves cross at a “breakeven utilization point,” typically between month 14 and month 22 for steady, high-utilization workloads in the case studies reviewed for this article. Workloads that never reach sustained high utilization never cross that line, so cloud remains cheaper for them indefinitely.
Illustrative breakeven model based on patterns reported in the 37signals and Broadcom case studies; actual breakeven timing depends on hardware amortization schedule, colocation contract terms, and workload utilization.
Real Case Studies With Real Numbers
Public, verifiable repatriation figures are rarer than the headlines suggest, because most companies do not publish detailed before/after cost breakdowns. The handful that have gone on record give a useful range of outcomes.
| Company | What moved | Reported financial outcome | Timeframe |
|---|---|---|---|
| 37signals (Basecamp / HEY) | Compute servers off AWS; ~18 petabytes of storage moved to owned Pure Storage arrays | Cloud bill cut from $3.2M/yr to $1.3M/yr; ~$10M total savings projected over 5 years, revised up from an initial $7M estimate | Oct 2022 – ongoing through 2025 |
| Dropbox | ~90% of customer file storage moved off AWS S3 to custom-built “Magic Pocket” infrastructure | ~$75M in cumulative infrastructure savings over two years, ahead of its 2018 IPO | 2013 – 2016 build-out, savings realized through 2017 |
| Broadcom (internal infrastructure) | Steady-state database and platform workloads off public-cloud DBaaS | Internal analysis found 40-50% lower TCO for steady-state workloads on modern private cloud; over $10M saved on the workloads moved | Multi-year internal program |
The common thread across all three is workload profile, not company size. Each case involves data or compute that is large in volume, grows predictably, and runs at consistently high utilization — exactly the profile where the cost curve in Figure 1 favors ownership. None of the three moved their variable, bursty, or geographically distributed workloads; 37signals, for example, has said it continues to use managed cloud services for email delivery and other elastic needs even as it exits AWS for core compute and storage.
The TCO Methodology: How to Compare Cloud vs. On-Premises Honestly
Most repatriation business cases fail — or get built on numbers that do not survive a second look — because they compare cloud list price against a rough hardware quote and stop there. A defensible total cost of ownership comparison has to price every component on both sides using the same time horizon and the same utilization assumptions.
- Step 1 — Baseline the real cloud billPull 12 months of actual billing data, not list price. Separate compute, storage, egress, load balancing, managed-service premiums, and support tier fees. Egress is the line item most TCO models under-count.
- Step 2 — Price the owned-infrastructure equivalentQuote server and storage hardware at the utilization level you actually run (not peak), amortized over a realistic refresh cycle — 4-5 years for compute, 5-7 for storage arrays. Include colocation power, cooling, cross-connects, and cage fees if you’re not building your own facility.
- Step 3 — Add the operations labor deltaOwned infrastructure needs people who patch firmware, replace failed drives, manage capacity, and staff on-call rotations for hardware incidents — work the cloud provider currently absorbs. Price this at fully loaded headcount cost, not “existing staff will absorb it.”
- Step 4 — Model the migration and dual-run costEvery repatriation case study that published a timeline (37signals, Dropbox) ran cloud and owned infrastructure in parallel for months during cutover. Budget for double-paying during that window, plus the engineering time to re-architect for a non-elastic environment.
- Step 5 — Compare at the same discount rate over the same horizonRun both totals over a 3-5 year window using your organization’s actual cost of capital, then compare against the breakeven curve in Figure 1. If utilization is volatile month to month, the cloud side usually still wins even when the raw hardware math looks favorable.
- Step 6 — Stress-test against a growth and a shrink scenarioRe-run the model at 50% higher and 50% lower demand. Owned infrastructure that looks cheap at forecast volume can become the most expensive option if demand drops and the hardware sits underutilized, or the most constrained option if demand spikes past capacity.
Figure 2: Fully Loaded Cost Components, Cloud vs. Owned Infrastructure
A stacked bar comparison with two bars. The “public cloud” bar breaks into compute (35%), storage (20%), data egress (15%), managed-service premium (15%), and support/SLA tier (15%). The “owned infrastructure” bar breaks into hardware amortization (40%), colocation/power/cooling (20%), network and cross-connects (10%), operations labor (25%), and spare-capacity buffer (5%). The point of the figure is that egress and managed-service premiums on the cloud side are mirrored by labor and spare-capacity costs on the owned side — both are frequently omitted from quick comparisons, and both typically run 15-25% of the total.
Cost category weightings are illustrative, built from the component breakdowns discussed in published repatriation TCO analyses; actual proportions vary by workload type and region.
When Repatriation Actually Makes Financial Sense
The case studies and the cost-curve math point to a consistent set of conditions. Repatriation tends to pay off when a workload has stable, predictable resource consumption that does not swing more than 20-30% month to month — the opposite of the elastic, bursty profile cloud pricing is built to reward. High and growing storage volume is the single strongest signal in the public case studies: Dropbox and 37signals both cite storage and its associated egress and retrieval fees as the largest driver, because storage costs compound linearly while cloud storage pricing rarely drops fast enough to offset growth. Long expected service life (the workload will still exist in 3-5 years) is required to clear the amortization period in Figure 1; workloads on a 12-18 month roadmap essentially never clear it. Compliance or data-residency requirements that already mandate a private or dedicated environment change the comparison entirely, since the alternative isn’t “stay in public cloud” but “pay a premium for compliant public cloud” — see how securing regulated data in the cloud already adds cost on the public-cloud side of that ledger. And an organization needs existing operational capacity — a team that already runs infrastructure, or the budget to hire one — because the labor line item in Figure 2 is where the least experienced TCO models go wrong.
When It’s a False Economy
The same evidence base shows where repatriation destroys value instead of creating it. Variable or seasonal workloads — retail traffic spikes, batch jobs that run once a month, anything with a peak-to-trough ratio above 3:1 — lose the entire benefit of elastic pricing the moment they move to fixed-capacity hardware; you either overprovision for the peak (paying for idle capacity most of the month) or underprovision and drop requests at the peak. Short-lived projects, anything with an 18-24 month horizon or shorter, never reach the breakeven point in Figure 1 before the project ends or the hardware needs replacing. Global or multi-region reach is expensive to replicate outside major cloud providers’ points of presence; a company serving users across three continents will spend more building and maintaining that footprint on owned infrastructure than the egress fees it’s trying to avoid. Thin operations teams are the most common hidden failure mode: companies that model the hardware cost accurately but assume existing staff will absorb firmware patching, disk failures, and on-call rotations for physical infrastructure routinely see the labor line item balloon 6-12 months after cutover. And workloads that are still evolving architecturally — active feature development, frequent scaling changes — lose the operational flexibility that made cloud attractive in the first place, an especially acute problem for smaller teams; see how small businesses evaluate cloud tooling tradeoffs for the scale at which owned infrastructure stops making sense.
Common Mistakes in Repatriation Business Cases
- Comparing cloud list price to a hardware quote at peak spec. Real bills after committed-use discounts and reserved instances are often 30-50% below list price; comparing against list price manufactures a bigger “savings” number than actually exists.
- Ignoring the labor line item entirely. “Our team will handle it” is not a cost of zero — it’s a cost that shows up as burnout, deferred maintenance, or a hiring request 6 months later.
- Treating the migration cost as a rounding error. 37signals ran a multi-year, multi-phase project; budgeting a repatriation as a weekend cutover consistently understates cost and risk.
- Modeling only the current utilization level, not the growth or shrink scenario. A TCO model built at today’s traffic can flip from favorable to unfavorable within a year if demand moves in either direction.
- Skipping the egress and data-transfer audit. Egress fees are the most commonly under-counted cloud cost in the case studies reviewed for this article, and they don’t show up until the data actually needs to move.
In Practice: How Experienced Teams Approach This Decision
Teams that get repatriation right rarely frame it as a binary “cloud or on-prem” decision. Instead, they tier workloads: elastic and customer-facing traffic stays in public cloud where autoscaling and global reach earn their premium; steady-state storage, batch processing, and internal platforms with flat utilization move to owned or colocated hardware. They negotiate cloud discounts as a byproduct of the analysis even when they don’t repatriate — several public case studies describe getting improved committed-use pricing from their cloud provider simply because a credible repatriation business case existed and was shared during contract renewal. They build the TCO model with the same rigor described in the methodology above, re-run it annually, and treat the crossover point in Figure 1 as a trigger for review rather than a one-time decision. And they invest in the operational tooling — monitoring, automated provisioning, infrastructure-as-code — that makes owned infrastructure behave enough like a cloud consumption model to avoid the operational-fragility failure mode that undermines the labor-cost assumptions in most naive models. Cost governance practices from cloud-native operations, including the tagging and unit-economics discipline described in FinOps cost-management approaches, transfer directly to running owned infrastructure with the same financial discipline.
Workload Suitability at a Glance
Not every workload type responds the same way to this analysis. Database workloads are a useful test case: teams weighing managed cloud database options like RDS, DynamoDB, and Cloud SQL against self-hosted database clusters are really running a smaller-scale version of the same TCO comparison covered above — managed-service premium versus operations labor, elasticity versus predictable steady-state load.
| Workload characteristic | Repatriation fit | Why |
|---|---|---|
| Steady-state batch processing | Strong | Predictable, high utilization, clears breakeven point quickly |
| Large, growing object storage | Strong | Storage and egress costs compound; largest documented case-study savings |
| Customer-facing web traffic with seasonal spikes | Weak | Peak-to-trough ratio makes fixed capacity expensive or risky |
| Early-stage product still finding scale | Weak | Utilization and architecture too volatile to model a stable TCO |
| Regulated data with residency mandates | Strong | Compliance already forces a dedicated environment; compare against premium-tier cloud, not standard tier |
| Global, multi-region user base | Weak | Replicating cloud providers’ points of presence is costly to build independently |
- Cloud repatriation
- Moving a specific workload from public cloud infrastructure back to on-premises hardware or a colocation facility.
- Total cost of ownership (TCO)
- The full cost of a workload over its service life, including hardware, facilities, labor, migration, and opportunity costs — not just the sticker price.
- Colocation
- Leasing rack space, power, and cooling in a third-party data center while owning and managing the servers and network gear yourself.
- Egress fees
- Charges a cloud provider applies when data leaves its network, often the largest under-counted cost in repatriation analyses.
- Committed-use / reserved instance discount
- A cloud pricing tier that lowers rates in exchange for a multi-year usage commitment, typically 30-50% below on-demand list price.
- Breakeven utilization point
- The point at which cumulative owned-infrastructure cost drops below cumulative cloud cost for an equivalent workload, typically 14-22 months for steady, high-utilization workloads.
- Workload tiering
- Classifying workloads by utilization pattern and criticality to decide, service by service, whether cloud or owned infrastructure is the better economic fit.
- FinOps
- The operating discipline of tracking, allocating, and optimizing cloud (or infrastructure) spend against business value, typically through cross-functional cost governance.
Key Takeaways
- Cloud repatriation is almost always partial and workload-specific, not a full cloud exit — Uptime Institute data shows most repatriating firms keep the majority of workloads in public cloud.
- Documented cases (37signals, Dropbox, Broadcom) show 30-75% cost reductions, but every case involves steady-state, high-utilization, long-lived workloads.
- Egress fees and storage growth are cited more often than raw compute as the trigger for repatriation business cases.
- A defensible TCO comparison must price operations labor, migration/dual-run costs, and a growth-and-shrink stress test — not just hardware versus list price.
- Breakeven typically lands between 14 and 22 months of sustained high utilization; workloads with shorter horizons rarely justify the move.
- Variable, seasonal, or globally distributed workloads are the most common false-economy candidates for repatriation.
- Even where repatriation isn’t executed, building the business case often yields better negotiated cloud pricing on its own.
FAQs
What is cloud repatriation?
Cloud repatriation is moving a workload from public cloud infrastructure back to on-premises servers or a colocation facility. It is almost always selective — organizations move specific steady-state workloads while keeping elastic or globally distributed workloads in public cloud.
Is cloud repatriation actually happening at scale, or is it mostly hype?
It is real but more limited than headline survey numbers suggest. Uptime Institute found 33% of organizations have moved at least one production application back on-premises, while Barclays’ CIO surveys measuring intent (83-86%) describe plans to move “some” workloads, not a mass exodus.
How much can a company actually save by repatriating?
Documented cases range widely: 37signals cut its annual cloud bill from $3.2M to $1.3M plus further storage savings, Dropbox saved roughly $75M over two years, and Broadcom’s internal analysis found 40-50% lower TCO on steady-state workloads. Savings depend heavily on workload profile.
What workload characteristics make repatriation financially worthwhile?
Steady, predictable utilization, a service life of 3+ years, large and growing storage volumes, and existing in-house operations capacity are the strongest signals. Compliance mandates that already require a dedicated environment also favor repatriation.
When does repatriation become a false economy?
When workloads are bursty or seasonal, short-lived (under 18-24 months), globally distributed, or when the organization lacks the operations staff to run physical infrastructure reliably. In these cases the hidden labor and idle-capacity costs typically erase the projected savings.
What is the biggest mistake in repatriation cost models?
Comparing cloud list price to a bare hardware quote while ignoring operations labor, migration/dual-run costs, and egress fees. Real repatriation business cases need to price every component on both sides using the same time horizon and utilization assumptions.
Does repatriation mean abandoning the public cloud entirely?
Rarely. Every major public case study, including 37signals, continues to use managed cloud services for specific elastic or specialized needs while moving steady-state compute and storage to owned infrastructure. The result is typically a deliberate hybrid model, not a full exit.
How long does a cloud repatriation project take?
Public timelines run from 18 months to several years. 37signals’ project began in October 2022 and extended into 2025 across multiple phases (compute, then storage). Budgeting for a multi-quarter, multi-phase migration with a parallel dual-run period is realistic; a weekend cutover is not.
References
- Andreessen Horowitz, “The Cost of Cloud, a Trillion Dollar Paradox” — a16z.com
- The Register, “37signals on-prem migration to save millions, abandon AWS” — theregister.com
- IT Pro, “This software company says ditching the cloud was worth $10 million in savings” — itpro.com
- Uptime Intelligence, “Cloud repatriation is overstated” — intelligence.uptimeinstitute.com
- Uptime Institute, Annual Outage Analysis and workload placement research — uptimeinstitute.com
