Key takeaways
- Repatriation is usually selective. Surveys show most enterprises plan to move some workloads back, but only a small minority plan a full exit.
- The best candidates are steady, storage-heavy, egress-heavy or latency-sensitive workloads. Bursty, early-stage and globally distributed workloads usually belong in the cloud.
- Published savings cases are real but specific: Dropbox and 37signals are large, stable, storage-intensive businesses. Your result depends on your own TCO model.
- In our illustrative mid-size SaaS model below, run-rate savings reach about 47%, payback takes roughly two years, and five-year savings are about 28%. With a heavier operations team or a smaller cloud bill, the case weakens or disappears.
- In the EU, DORA exit-strategy rules and the Data Act’s ban on switching charges (from 12 January 2027) make exit readiness a governance topic, not only a cost topic.
What cloud repatriation is (and isn’t)
Cloud repatriation means moving selected workloads, data or applications from a public cloud provider to private infrastructure — colocation, bare metal, a private cloud or an on-premises data centre — while usually keeping other workloads in the public cloud.
It is not a verdict that the cloud failed. For early-stage products, uncertain demand and global distribution, public cloud remains hard to beat. Repatriation becomes relevant later, when some workloads have settled into predictable patterns and the premium paid for elasticity is no longer buying anything.
We find it more useful to think in terms of workload placement: each system runs where its cost, performance and compliance profile fit best, and that placement is reviewed as the business matures.
How widespread is it? What the surveys actually say
The headline figure most often quoted comes from Barclays’ CIO survey: in the first half of 2024, 83% of enterprise CIOs said they planned to move at least some workloads back from public cloud, up from 43% in late 2020 (EE Times Europe). A later edition of the survey put the figure at 86% (Cyfuture summary).
Two caveats matter. First, “plan to move at least one workload” is a low bar — it says nothing about what share of spend moves. Second, IDC research cited across the industry suggests only around 8–9% of companies plan a full-scale repatriation (CNIC Solutions summary). The realistic picture is partial moves and hybrid estates, not a mass exodus.
Why the economics shift as workloads mature
Public cloud pricing bundles three things: the infrastructure itself, the provider’s operations, and the option to scale up or down at will. Early on, that option is valuable. Once a workload runs at a steady baseline 24/7, you keep paying for flexibility you no longer use.
Andreessen Horowitz’s widely cited analysis, The Cost of Cloud, a Trillion Dollar Paradox (2021), put numbers on this for public software companies. The authors estimated that committed cloud spend averaged roughly half of cost of revenue across the companies they studied, and reported one billion-dollar private company whose cloud spend reached 81% of cost of revenue. Based on expert interviews, they used a working assumption that repatriation runs equivalent workloads at one-third to one-half of the cloud cost (a16z).
That analysis is an estimate built on interviews and filings, not a controlled study, and it focused on large software companies. It is a useful frame for why margins matter, not a forecast for any individual company.
The cost drivers to measure in your own bill
This is the Cloud Paradox:
the infrastructure that accelerates early growth becomes a structural tax on mature businesses.
Venture capital and public market analysts have quantified the impact. Across large software companies, cloud spend has been shown to suppress gross margins by 15–25 percentage points. Because valuation is a function of gross profit, this does not merely reduce cash flow—it destroys equity value.
At scale, cloud costs are no longer an operational detail. They become a board-level concern.
From Agility to Efficiency: A Two-Stage Infrastructure Model
The emerging consensus among infrastructure leaders is not “cloud versus on-prem,” but phase-appropriate infrastructure.
Stage 1: The Agility Phase
In the early lifecycle of a product or platform, uncertainty dominates.
- Demand is volatile
- Architecture is still evolving
- Speed matters more than efficiency
Public cloud excels here. Elasticity, managed services, and global reach justify the premium. Paying for flexibility makes sense because flexibility is actively used.
Stage 2: The Efficiency Phase
As products mature, priorities change.
- Workloads enter steady state
- Usage becomes predictable
- Margins and cost per transaction matter
At this stage, elasticity becomes overhead. Enterprises continue paying for burst capacity they no longer need, for abstraction layers they cannot tune, and for network paths they do not control.
Infrastructure Maturity means recognizing when a workload has crossed from Stage 1 to Stage 2—and moving it accordingly.
Deconstructing the Cloud Tax
The “cloud tax” is not a single line item. It is the cumulative effect of multiple structural costs that only become visible at scale.
1. Data Egress and Network Friction
Ingress is cheap. Egress is not.
For data-intensive workloads, network charges routinely account for 20–40% of total cloud spend. Cross-region replication, analytics pipelines, AI training data, and customer exports all trigger fees that are difficult to forecast and harder to optimize.
This creates economic lock-in: data can enter easily, but leaving is expensive.
2. Virtualization Overhead
Public cloud relies on deep abstraction. That abstraction introduces measurable performance loss—typically 5–15% per workload, which must be compensated for with additional compute.
For high-throughput databases, AI inference, real-time analytics, and latency-sensitive systems, this overhead translates directly into higher cost per request and inconsistent performance.
3. Cost Volatility
Usage-based pricing creates financial unpredictability. Infrastructure becomes a variable expense tied not just to growth, but to architectural decisions, user behavior, and even API design.
For CFOs and boards, this volatility complicates forecasting, valuation, and long-term planning.
Rather than relying on generic percentages, these are the line items we examine first in a repatriation assessment:
- Data egress and transfer
Internet egress, cross-region replication, cross-AZ traffic and NAT processing are billed per GB. At AWS list prices, internet egress starts at about $0.09/GB in most regions. For data-heavy products, this line can grow faster than compute. - Steady-state compute
Instances running at a stable baseline around the clock are the clearest candidates, especially after Savings Plans or Reserved Instances are already applied. - Storage growth. Object and block storage that grows continuously but is rarely deleted.
- Performance-sensitive systems
Databases, real-time analytics and inference services where you may be over-provisioning to compensate for noisy neighbours or abstraction overhead. The size of that overhead varies by workload, so we benchmark it rather than assume it. - Cost volatility. How much monthly spend deviates from forecast, and how hard that makes budgeting and margin planning.
If you haven’t yet optimised the cloud bill itself — rightsizing, commitments, storage tiers, VPC endpoints — do that first. Many “repatriation” cases turn out to be optimisation cases.
See our guide to cloud cost optimization traps.
Real-world cases, with their context
Dropbox
Dropbox’s 2018 S-1 filing describes an “Infrastructure Optimization” programme that moved most user data from a third-party provider to its own custom infrastructure in leased colocation facilities. In 2016, payments to the third-party provider fell by $92.5M, offset by a $53.0M increase in depreciation, facilities and support costs — a net decrease of $39.5M. A further $35.1M reduction followed in 2017, for about $74.6M over two years (Dropbox S-1, SEC; GeekWire).
Context: Dropbox operates at very large storage scale and kept using AWS for a portion of its storage and for some regions.
37signals (Basecamp, HEY)
37signals reported a 2022 cloud bill of about $3.2M. In early 2023 it projected spending roughly $840,000 a year on owned hardware (amortised over five years) and colocation, versus about $2.3M in comparable cloud costs, and estimated $7M saved over five years (DatacenterDynamics).
In October 2024 the company said its annual cloud bill had dropped to about $1.3M (remaining S3 storage), that the ~$700K of new servers had been recouped from savings during 2023, and raised its five-year estimate to more than $10M once storage moves too (DatacenterDynamics).
Context: these are company-reported figures, and observers note they exclude some costs, such as future hardware refreshes and part of the operations overhead. 37signals also already had operations staff and existing data centre space.
What both cases share: large, stable, storage-heavy workloads, existing in-house infrastructure skills, and a hybrid end state rather than zero cloud.
How we built the numbers: methodology
The worked example below is illustrative. It is a composite of the cost structures we typically see in mid-size SaaS assessments, not a single client’s data. These are the assumptions behind it:
- Scope
One production platform: steady compute, ~500 TB of block and object storage, ~150 TB/month of internet egress, managed databases and load balancers. - Cloud baseline
Current monthly bill after existing Savings Plans and storage-tier optimisation, so we compare against an already-optimised cloud, not list price. - Time horizon
3 and 5 years. Hardware is depreciated over 5 years; no refresh falls inside the window. - Upfront costs
Server and storage hardware, plus a one-off migration budget covering engineering time, dual-running both environments during cut-over, and data transfer. - Ongoing private costs
Colocation rack space and power, internet transit, hardware support contracts (8% of hardware cost per year), operations staffing (fully loaded), software licences, and a residual cloud footprint for DR, burst capacity and edge delivery. - Excluded
Price changes over the period, financing costs, tax effects, and the opportunity cost of engineering time not spent on product.
When we run this for a client, every input comes from their billing exports, utilisation metrics and vendor quotes, and we document each assumption so finance can challenge it.
Worked example: 5-year TCO for a mid-size SaaS platform
Current public cloud spend (monthly, after commitments)
| Line item | Monthly | Annual |
|---|---|---|
| Compute (after Savings Plans) | $46,000 | $552,000 |
| Block + object storage (~500 TB) | $14,000 | $168,000 |
| Internet egress (~150 TB) | $11,000 | $132,000 |
| Managed databases, load balancers, misc. | $9,000 | $108,000 |
| Total | $80,000 | $960,000 |
Repatriated / hybrid alternative
| Item | Cost |
|---|---|
| Hardware (servers, storage, network) — one-off | $650,000 |
| Migration, dual-running and data transfer — one-off | $250,000 |
| Colocation, 4 racks incl. power — per year | $120,000 |
| Internet transit — per year | $36,000 |
| Hardware support (8% of hardware) — per year | $52,000 |
| Operations staffing (1.5 FTE, fully loaded) — per year | $165,000 |
| Software licences — per year | $40,000 |
| Residual cloud (DR, burst, CDN/edge) — per year | $96,000 |
| Ongoing total — per year | $509,000 |
Results
| Metric | Value |
|---|---|
| Run-rate saving per year | $451,000 (≈47% of the cloud bill) |
| Upfront investment | $900,000 |
| Simple payback | ≈24 months |
| 3-year cumulative cost: cloud vs. hybrid | $2.88M vs. $2.43M → saving ≈$453K (≈16%) |
| 5-year cumulative cost: cloud vs. hybrid | $4.80M vs. $3.45M → saving ≈$1.36M (≈28%) |
Note how different the three numbers look. The run-rate saving (47%) is the figure people like to quote. The 3-year saving (16%) is what a CFO sees once the upfront investment is included. Both are true; only one belongs in a board deck without a footnote.
Sensitivity: what breaks the case
| Scenario | Effect |
|---|---|
| Operations team needs 3 FTE instead of 1.5 | Payback stretches to ≈38 months; 5-year saving falls to ≈$530K (≈11%) |
| Cloud bill is $30K/month instead of $80K (smaller footprint, ~$450K upfront, 1 FTE) | 5-year result turns negative: roughly –$105K |
| Workload becomes bursty (needs 2× peak capacity on-prem) | Hardware and colocation costs rise sharply; usually stay in cloud |
The two variables that move results most are operations staffing and the size and stability of the cloud bill. If you can’t staff the private environment (or buy managed colocation and remote hands), the savings evaporate.
When repatriation is the wrong move
Repatriation is a poor fit — or premature — in these situations:
- Your cloud bill is modest
Below a few hundred thousand dollars a year, fixed costs (staff, contracts, minimum rack commitments) tend to eat the savings, as the sensitivity table shows. - Demand is spiky or unpredictable
Seasonal retail, event-driven platforms and new products benefit from paying only for peaks. - You rely heavily on managed or proprietary services
Rebuilding the equivalent of a managed data warehouse, serverless stack or ML platform can cost more than it saves. - You lack infrastructure operations skills and don’t want to build or buy them.
- You need global reach or low-latency edge delivery in many regions.
- You haven’t optimised the cloud yet
Rightsizing, commitments and storage tiering often recover a meaningful share of spend for far less effort. - The architecture is about to change
Committing to five years of hardware just before a major re-platforming locks in the wrong capacity. - The business case depends on hard-to-forecast growth
If capacity needs could double or halve within two years, flexibility is worth paying for.
In these cases, the right move is usually cloud cost optimisation, better commitment planning, or keeping an exit plan on paper rather than executing it.
AI workloads: a case to model, not to assume
GPU-heavy AI training and inference have renewed interest in dedicated infrastructure. The reasoning: long-running training jobs keep expensive accelerators busy for weeks, large datasets are costly to move repeatedly, and teams want predictable capacity.
The economics are highly specific, though. Compare on-demand, reserved and spot GPU pricing from hyperscalers, specialised GPU cloud providers and colocation options against your actual utilisation. Dedicated GPU clusters pay off when they stay busy; idle accelerators are among the most expensive assets a company can own. For more on planning this, see building AI-ready infrastructure.
Regulation: exit readiness in the EU
Two EU regulations make exit planning a concrete obligation rather than a nice-to-have:
- DORA (Digital Operational Resilience Act). Applicable to EU financial entities since 17 January 2025, DORA Article 28(8) requires documented exit strategies for ICT services that support critical or important functions, and these should be tested and reviewed (Swfte overview; FAST LTA).
- EU Data Act. Its cloud-switching rules allow only cost-based switching charges until 12 January 2027; from that date, switching charges — including data egress fees tied to a switch — are prohibited. The ban covers switching providers or moving to on-premises, not ordinary day-to-day egress (Lindahl)
Major hyperscalers already waived egress fees for customers making a full exit in 2024. Lower exit costs don’t make repatriation automatically worthwhile, but they remove one barrier and make a credible exit plan easier to document.
Read more: Digital Sovereignty of Europe: Choosing the EU Cloud Provider.
Why it is more feasible now
A decade ago, leaving the cloud often meant giving up operational convenience. That gap has narrowed:
- Kubernetes and infrastructure-as-code (Terraform, Ansible) behave consistently across cloud and bare metal.
- Modern deployment tooling supports zero-downtime releases outside hyperscalers.
- Open storage and networking standards preserve portability.
- Colocation providers offer remote hands and managed facilities, so you don’t need to run your own building.
The operational gap is smaller, but not zero. Someone still has to own hardware lifecycle, capacity planning, security patching and incident response.
Regulation and infrastructure sovereignty
Cost and performance are no longer the only drivers.
By 2026, documented exit capability is becoming a regulatory requirement across multiple jurisdictions. Financial services, healthcare, critical infrastructure, and government-adjacent organizations must now prove they can disengage from cloud providers without service disruption.
This shifts repatriation from an optimization choice to a compliance obligation.
Infrastructure that cannot be exited is no longer considered resilient.
Read more: Digital Sovereignty of Europe: Choosing the EU Cloud Provider
Why Cloud Repatriation is feasible now
A decade ago, leaving the cloud meant sacrificing operational convenience. That is no longer true.
- Modern deployment tools enable zero-downtime releases on bare metal with minimal operational overhead
- Kubernetes behaves consistently across environments
- Open storage and networking standards preserve portability
- Colocation providers offer managed facilities without hyperscaler markups
The operational gap between public cloud and private infrastructure has narrowed dramatically. What remains is a cost and control gap—and that gap favors maturity.
Building a cloud exit strategy: a maturity framework
Successful cloud repatriation is selective, not absolute.
- Audit and classify workloads
Identify steady-state systems paying for unused elasticity. - Model long-term economics
Compare 3–5 year total cost of ownership, including margin impact—not just infrastructure invoices. - Assess operational readiness
Determine whether to own operations fully or pair private hardware with managed facilities. - Ensure portability
Standardize data formats, deployment pipelines, and orchestration layers. - Rehearse the exit
Treat exit readiness as an operational capability, not a contingency document.
The hybrid maturity era
The future is not cloud-only or on-prem-only. It is hybrid by design.
- Public cloud remains the best tool for experimentation, global distribution, and burst workloads
- Private infrastructure anchors predictable compute, core data, and margin-sensitive systems
Enterprises that succeed by 2026 will be those that treat infrastructure placement as a strategic lever—not a default setting.
Repatriation is not a step backward.
It is the moment an organization proves it understands its own economics.
Strategic priorities for 2025–2026
- Identify workloads that have outgrown elasticity
- Reassess AI infrastructure economics early
- Embed exit readiness into governance
- Standardize on portable tooling
- Elevate infrastructure cost to a valuation metric
The cloud was never the destination. It was the on-ramp.
Infrastructure Maturity is knowing when to change lanes.
The hybrid end state
In most of the engagements we see, the result is hybrid by design. Public cloud handles experimentation, burst capacity and global distribution. Private infrastructure carries predictable compute, core data and margin-sensitive systems. The placement is reviewed as workloads change — some may move back to the cloud later, and that should be easy too.
Repatriation isn’t a step backwards. Done well, it shows an organisation understands its own unit economics well enough to put each workload where it belongs.
Want a fact-based view of your own numbers?
Gart’s IT audit maps your workloads, models 3- and 5-year TCO from your actual billing data, and shows which systems — if any — are worth moving.
See how we can help to overcome your challenges
