Cloud repatriation: when moving back on-premise actually makes sense in 2026
It's not ideology — it's arithmetic. Here are the technical and economic criteria for deciding whether moving workloads off the cloud is worth it in 2026.
Published on May 4, 2026 · 7 min read
The number that changes the conversation
In 2024, Dhruv Malhotra, VP Engineering at a mid-market European SaaS company, publicly shared his AWS bill: $2.1 million per year for workloads running on r6i.4xlarge instances at an average 68% utilization. After a partial migration to owned bare-metal in a colocation facility, operational spending dropped to $740,000. Not because the cloud is broken. Because in that specific context, it was the wrong tool.
The phenomenon has a name: cloud repatriation. It's not a nostalgic return to the on-premise model of the 2000s. It's an architectural decision that, in 2026, a growing number of organizations are making with hard data.
Why cloud stopped being automatically cheaper
The "cloud = cheaper" narrative held when companies were migrating from underutilized, poorly managed datacenters with CAPEX inflated by hardware sized for peak demand. Today, mature organizations often have workloads with the opposite profile:
- Stable, predictable utilization: no benefit from elasticity, which you still pay for as overhead in list prices.
- High compute-to-storage ratio: OLAP databases, rendering, ML inference. Memory-optimized instance pricing on major clouds grew 12–18% between 2022 and 2025.
- High egress: moving data out of AWS, GCP, or Azure costs money. A Kafka cluster with 50 TB/month of cross-region throughput can generate $4,000–$8,000/month in egress alone.
Cloud still makes sense where you need real elasticity, delegated management of complex services, or distributed geographic presence without your own infrastructure. But "makes sense" isn't the same as "always".
Workloads that are candidates for repatriation
Not everything moves back. The decision applies to specific categories.
1. Databases with stable access patterns
PostgreSQL or MySQL at 10,000 queries/second, constant load, on a db.r6g.4xlarge RDS instance costs roughly $8,000/month on a 1-year reserved basis. A bare-metal server with 256 GB RAM and NVMe in a quality colo runs $1,200–$2,000/month all-in. Breakeven in under four months.
The hidden cost is operations: backup, failover, patching. But if you have an in-house DBA, or a partner delivering that service on a white-label basis, the operational gap is bridgeable.
2. Fixed-volume ML inference
Serving a 7B-parameter model in production on an AWS g5.xlarge (A10G GPU) costs roughly $1.20/hour. At full utilization (730 hours/month), that's $876/month per GPU. Two GPUs in your own colo server: a one-time investment of roughly $20,000, amortized in 24 months. From month 25 onward, marginal cost is near zero.
If your load is burst-heavy — inference only during peak hours — cloud remains superior.
3. High-capacity storage with frequent access
S3 Standard costs $0.023/GB/month. At 500 TB, that's $11,500/month, before egress and request fees. Ceph on owned hardware in colo can reach $0.003–$0.005/GB/month all-in. At 500 TB, potential savings: $9,000–$10,000/month.
Hybrid architecture is the real destination
No serious organization is returning to the datacenter-only model of 2005. Selective repatriation leads to a hybrid architecture where:
- On-premise/colo: stable compute, high-capacity hot storage, owned GPU inference.
- Cloud: burst capacity, disaster recovery, managed services (managed Kafka, search, CDN), edge computing.
A concrete pattern:
[User traffic]
|
[Cloud CDN] → [Cloud load balancer] → [Cloud API layer]
|
[On-premise backend via VPN/Direct Connect]
|
[On-prem DB] + [On-prem object storage]
|
[Cold backup on S3 Glacier]VPN or Direct Connect adds latency — typically 1–3 ms between a European colo and the nearest cloud region. For most application backends, this is not an issue. For real-time systems requiring sub-10ms end-to-end, measure before you decide.
A four-question decision framework
Before starting any repatriation project, answer these questions with real data:
1. What is your actual average utilization? If cloud instances are below 50% utilization, you have a sizing problem before you have a placement problem.
2. Does your workload have unpredictable spikes? If yes, quantify the gap between baseline and peak. If the peak is 3x baseline for 200 hours/year, cloud only makes sense for the delta — the baseline can move on-premise.
3. Do you have, or can you access, the infrastructure skills to run it? The hidden cost of repatriation is people. A senior infrastructure engineer costs €70,000–€90,000/year. If you don't have one, include that in the TCO — or outsource the management.
4. What is your planning horizon? Repatriation requires upfront CAPEX: hardware, rack, cabling, colo contract. If your runway is under 18 months or your product strategy is uncertain, cloud flexibility has real value.
What not to do
Three common mistakes seen in repatriation projects:
- Migrating without measuring: moving everything because it "costs too much" without workload-by-workload analysis produces disappointing results and often makes things worse.
- Replicating the cloud on-premise: buying bare-metal and then running Kubernetes with a heavy abstraction layer eliminates most of the compute savings.
- Ignoring connectivity: a colo with 1 Gbps shared uplink is insufficient for I/O-intensive workloads. Specify connectivity requirements in the contract.
Operational takeaway
Repatriation makes sense when: utilization is stable above 60%, planning horizon exceeds 24 months, workloads are compute/storage-intensive, and infrastructure skills are available — in-house or via outsourcing. In every other case, optimize cloud spending first: Reserved Instances, Savings Plans, rightsizing.
The question isn't where your code runs. It's 36-month TCO, calculated honestly.
---
Evviva Group helps technology companies design and operate hybrid architectures on a white-label basis. If you're considering a TCO analysis for a repatriation project, get in touch.