After years of one-way traffic into the public cloud, a quiet counter-movement has become impossible to ignore. Businesses are selectively moving certain workloads back out of the cloud and onto their own hardware, a practice now widely called cloud repatriation. This is not a rejection of the cloud, and it is not a fad driven by nostalgia. It is a maturing market doing the sums properly and discovering that, for specific workloads, the original case no longer holds. Here is what is really driving it and how to tell whether any of your workloads fit the pattern.
What repatriation is, and is not
Cloud repatriation simply means taking a workload that currently runs in a public cloud and moving it back to infrastructure you own or rent in a more traditional way, whether that is on-prem hardware or a colocation rack. The key word is selective. Almost nobody is pulling everything back; they are identifying the handful of workloads where the cloud is the wrong home and relocating those, while leaving the rest exactly where it is.
It is also not an admission that going to the cloud was a mistake. For most businesses the cloud was the right first move: it removed barriers, accelerated projects and absorbed a lot of grunt work. Repatriation is what happens next, once a workload's behaviour is well understood and its bills are predictable enough to compare honestly against owning the kit. It is optimisation, not regret.
Why the sums change over time
The dominant driver is cost at steady state. A workload that has settled into a constant, predictable pattern, running the same load around the clock, is the worst possible fit for a rental model, because you pay continuously for capacity you use continuously. When a finance team finally annualises that bill and compares it to the cost of owning equivalent hardware over its life, the gap can be large enough to fund a refresh several times over.
Data egress is the second driver, and the one businesses underestimate most. Moving large volumes of data out of a cloud, to serve users, to analyse elsewhere, or to back up, carries per-gigabyte charges that grow with the business. A data-heavy workload can end up paying a steady tax simply to access its own information. Predictability is the third: owning hardware turns a variable monthly bill into a known, depreciating asset, which finance teams value.
- •Steady, always-on workloads pay continuous rent for capacity used continuously - the worst rental fit
- •Data egress charges quietly tax any workload that moves large volumes out of the cloud
- •Owning hardware converts a variable bill into a predictable, depreciating asset
- •Control, data residency and performance consistency add further weight for some workloads
Which workloads tend to come back
A clear pattern has emerged in which workloads repatriate well. Large, predictable databases and storage-heavy systems are prime candidates, because they combine steady load with high egress. Established line-of-business applications that no longer change shape are good fits too, since their demand is known and stable. So are workloads with strict data-residency or regulatory requirements, where owning the location simplifies compliance.
Equally, some workloads should stay in the cloud and trying to repatriate them would be a mistake. Anything with genuinely spiky or seasonal demand, anything that needs to scale globally at short notice, and anything still evolving quickly all benefit from elasticity you cannot easily replicate on owned hardware. The skill is telling the two groups apart, which is the same fit question behind our cloud versus on-prem piece.
How to decide without guessing
Do not repatriate on instinct; repatriate on evidence. Pull a representative cloud bill and break it down by workload, separating compute, storage and, crucially, egress. For each candidate, model the genuine five-year cost of running it on owned hardware, including the server, power, maintenance and the staff time or managed-service cost to look after it. Compare like with like, and only move the workloads where the gap is real and durable.
Repatriation also has a one-off cost and a migration risk, so factor those in and plan the move properly rather than rushing it. If on-prem turns out to be the right home, spec the hardware to the workload rather than over-buying, which is what our server configuration service is for, and read the deeper own-versus-consume analysis in our Insights hub before you commit. Done well, repatriation is simply good housekeeping.