Cloud repatriation: which workloads to bring back first (and which to leave in the cloud)

July 14, 2026 · 3 min read · SOVALYX Technologies

Moving workloads back from public cloud to dedicated infrastructure is no longer contrarian: it is a deliberate financial trade-off, popularised by public cases such as 37signals (Basecamp). The right question is not "should we leave the cloud?" but "which workloads should we repatriate, in what order — and which should stay exactly where they are".

Why repatriation is here to stay

Public cloud was sold on elasticity: pay for what you use, absorb the peaks, start fast. All of that remains true. But a large share of enterprise workloads is not elastic at all: databases running around the clock, internal applications with stable load, storage that only ever grows. For these predictable workloads, usage-based billing means permanently paying for a flexibility you never use.

Add to that data egress fees, price increases and the maturity of FinOps practices, which finally make the real cost per application visible. The 37signals case, documented publicly by the company itself, showed that a competent operations team could move major workloads out of public cloud and achieve lasting savings. Sovereignty plays a role too: keeping control over where your data lives is becoming a contractual criterion, not just a preference.

The sorting framework: four criteria

1. Load stability: a flat, predictable load is the ideal candidate; a spiky load genuinely benefits from public cloud elasticity.
2. True total cost: compute, storage, egress, licences, managed services and monitoring. Compare it with the full cost of dedicated infrastructure, operations included — not just the price of the server.
3. Criticality and continuity: what RTO, what RPO? The cost of one hour of downtime for the application determines the level of redundancy required, wherever it is hosted.
4. Data sensitivity: personal, regulated or strategic data? Residency and access control requirements can mandate — or rule out — certain hosting choices.

The first candidates for repatriation

• Databases with constant load: sized once, they run without surprises on dedicated hardware.
• Large storage with steady growth: archives, backups, media — often where the cost gap is widest, egress included.
• Stable internal applications: ERP, line-of-business tools, intranets whose load barely changes month to month.
• "Lift and shift" virtual machines that were never re-architected: they use no cloud-native services and pay full price.
• Continuous AI inference: a constant GPU volume pays off better on dedicated hardware than billed per request.

What is better left in the public cloud

Repatriation is not an ideology. Better left in the public cloud: workloads with strong seasonality or unpredictable spikes, deeply integrated managed services whose rewrite would cost more than the expected savings, applications serving a global audience that require multiple points of presence, and prototypes whose real load is still unknown.

Another condition that is often forgotten: repatriating means taking back operational responsibility — continuous monitoring, backups, disaster recovery, on-call coverage. Without it, you are trading an invoice for a risk. That is precisely the point of a private cloud operated under SLA, the model SOVALYX applies in Mauritius: the savings of dedicated infrastructure without giving up operational guarantees. Before deciding, also run through the four questions of the cloud outage test: they cut both ways.

Summary table: repatriate or leave?

Start with an honest per-application cost inventory, repatriate one stable, non-critical workload first to prove the method, then extend. Successful repatriation is gradual — never an overnight move.

🧰 The companion tool: Public cloud or private: what do your numbers say over 3 years? — free · 2 minutes.

Reviewed and optimised by AI.