Cloud Repatriation: Moving Workloads Back On-Premise

For most of the last fifteen years, the direction of travel in IT was obvious and one-way: everything moves to the public cloud. Lift, shift, modernise, repeat. So it surprises people to learn that a meaningful number of organisations are now moving workloads in the opposite direction — back from hyperscalers into private infrastructure they own or have operated on their behalf. This is cloud repatriation, and it is not a rejection of the cloud operating model. It is a maturing of it.

Repatriation rarely means abandoning public cloud entirely. More often it means right-placing workloads: keeping the ones that genuinely benefit from elasticity in the public cloud, and bringing home the ones that have become predictable, expensive, or sensitive. This article looks at why organisations repatriate, how to build the business case, and how to do the move without the pain that sent people to the cloud in the first place.

Why the pendulum is swinging back

The original promise of public cloud was compelling: no capital expenditure, infinite elasticity, pay only for what you use. For unpredictable, spiky, or early-stage workloads, that promise still holds. The trouble is that a great many production workloads are not unpredictable at all. They run at a steady, well-understood baseline twenty-four hours a day — and for those, the rental model is the most expensive way to consume compute.

The realisation tends to arrive gradually and then suddenly. A cloud bill creeps upward year after year, egress fees pile up, and one day finance asks why a stable, predictable application costs several times what equivalent owned hardware would cost over its life. That question is the starting gun for most repatriation projects.

The cost triggers worth watching

Cost is the dominant driver, so it pays to know which line items most often tip the balance.

Steady-state compute

If a workload runs at roughly constant utilisation, you are paying a premium for elasticity you never use. Owned or dedicated infrastructure amortised over three to five years is frequently far cheaper per unit of compute for that profile.

Data egress and transfer

Egress fees are the quiet budget killer. Data-heavy applications — analytics, media, backups, anything that moves large volumes out of the provider — accumulate transfer charges that can rival the compute bill itself, and they scale with success rather than tapering off.

Storage at scale

Long-lived, growing datasets on premium managed storage tiers become expensive in a way that is easy to miss month to month but stark over a year. Distributed storage like Ceph on owned hardware changes that arithmetic considerably.

Beyond cost: the other drivers

Money is the headline, but it is rarely the only reason. Data sovereignty has become a major motivator, especially in Europe: keeping regulated or sensitive data under domestic legal control, free from extraterritorial reach, is increasingly a board-level requirement under the DSGVO and sector rules like DORA and NIS2.

Performance and latency matter too. Workloads that need to sit close to on-premise systems, factory equipment, or specific networks often perform better and more predictably on local infrastructure. And then there is control: organisations burned by sudden pricing changes or feature deprecations want their critical systems on a foundation whose terms they govern. The Broadcom-VMware episode sharpened that instinct across the whole industry.

Building the business case

A credible repatriation case rests on honest total cost of ownership, not a back-of-envelope comparison. Capture the full picture on both sides.

On the cloud side, gather a full year of actual spend — compute, storage, egress, managed services, support — not the list price of instances. On the private side, account for hardware amortised over its real lifespan, datacentre or colocation costs, networking, software, and the often-underestimated cost of operational staff or a managed-service partner. The honest comparison usually shows that repatriation wins decisively for steady-state workloads and loses for genuinely elastic ones — which is exactly why the answer is a portfolio, not a wholesale move in either direction.

Do not forget the migration cost itself, and the time value of the savings: a project that pays back in twelve to eighteen months is very different from one that takes four years.

A decision checklist

Before committing, run each candidate workload through a few questions. Is its utilisation steady and predictable, or genuinely spiky? Is it data-heavy enough that egress dominates the bill? Does it carry sovereignty or compliance sensitivity? How tightly is it coupled to provider-specific managed services that would need replacing? And does your organisation have, or can it obtain, the operational capability to run it well once repatriated? Workloads that answer steady, data-heavy, sensitive, loosely coupled, and yes are prime repatriation candidates. Ones that answer the opposite should probably stay.

How to repatriate without the pain

The fear that keeps organisations from repatriating is the memory of how hard the original migration was. The key is to treat repatriation as a disciplined programme rather than a heroic weekend.

Start by mapping dependencies thoroughly — the hidden ones, the managed database that three other services quietly rely on, are what derail projects. Choose a non-critical workload to move first and prove the pattern end to end. Wherever possible, target an open, standards-based destination so you are not simply trading one lock-in for another: a private cloud built on OpenStack, KVM, and Ceph gives you cloud-style APIs and self-service without proprietary entanglement. Re-platform provider-specific services onto open equivalents — managed Postgres becomes Postgres you run, proprietary queues become standard ones — and validate performance and backups before cutting over production. Then move in waves, learning as you go.

The role of a managed private cloud

The single biggest objection to repatriation is operational: who runs the infrastructure once it comes home? Not every organisation wants to rebuild a platform engineering team to operate a private cloud, and that hesitation is reasonable. This is where a managed sovereign platform changes the calculus.

clouditiv exists for exactly this scenario. We deliver a sovereign, OpenStack-based private cloud as a managed platform — OpenStack 2025.2 on Ubuntu 24.04 LTS, with KVM, Ceph storage, and OVN networking, a full private cloud provisioned automatically in under an hour, operated against a 99.9% uptime SLA, with data that stays in Germany. The strong demand around VMware-to-OpenStack migration after the Broadcom licensing fallout overlaps heavily with repatriation: in both cases organisations want predictable cost, real control, and a destination they are not locked into. Repatriating onto a managed private cloud lets you reclaim the economics and the sovereignty without taking on the full operational burden yourself.

Repatriation as portfolio management

The most useful way to think about repatriation is not as a reversal of cloud strategy but as the next stage of it. The early years were about getting everything into the cloud quickly; the mature phase is about putting each workload where it actually belongs. Elastic and experimental workloads thrive on hyperscalers. Steady, data-heavy, and sovereignty-sensitive ones increasingly belong on private infrastructure you control. Done with a clear-eyed TCO analysis and a disciplined migration plan, repatriation is not a retreat — it is simply good portfolio management, and for a growing number of European organisations it is the move that finally brings the cloud bill, and the data, back under control.