The workloads that actually leave the cloud share a profile: steady, high utilisation, and predictable, with demand that rarely varies and data that sits in large stable volumes. For these, you pay the cloud premium for elasticity you never use, so owned or colocated hardware running near constant load can be materially cheaper per unit. The workloads that stay are the opposite: variable, spiky, early in their lifecycle, or dependent on managed services and global reach you would have to rebuild. Repatriation in 2026 is therefore a portfolio decision made workload by workload, not a verdict on the cloud, and it only saves money once you have priced the egress to leave and the operating capability you must recreate.
Get specific about which workloads qualify and what moving them truly costs, and the repatriation question becomes an economic calculation rather than an ideological one.
What profile makes a workload leave?
The clearest signal is utilisation that is both high and flat. A workload that runs near full capacity around the clock, with demand that does not spike or seasonally swing, gets no value from the cloud elasticity it is paying for. On a rented footprint you provision for the steady load and it never goes idle, so the cloud premium is pure overhead. Owned hardware amortised over its life, or colocated capacity, can undercut that footprint meaningfully once you account for full utilisation. Storage heavy workloads tell the same story: large, stable data sets that grow predictably and are accessed steadily are expensive to keep on premium cloud storage and on cloud egress when accessed externally.
Add predictability. A workload you can capacity plan years ahead, because its growth is steady and well understood, fits owned capacity, where you buy ahead of a known curve. A workload whose demand you cannot forecast belongs on infrastructure you can scale in minutes, which is the cloud.
Which workloads should stay regardless?
Keep anything variable, spiky, bursty, or seasonal in the cloud, because elasticity is exactly what you are paying for and it earns its premium when demand moves. Keep early lifecycle workloads in the cloud, where you cannot yet predict scale and the option to grow or fail fast is worth more than a marginal cost saving. And keep workloads that lean on managed services, such as managed databases, serverless platforms, AI infrastructure, and global content delivery, where repatriating means rebuilding capability and carrying operational risk that usually outweighs the hardware saving. The cloud premium buys elasticity, managed operations, and reach; repatriate only where you genuinely consume none of the three.
What must you price before moving anything?
Three costs decide whether repatriation actually saves money. First, egress: moving large data volumes out of a cloud incurs transfer charges that can dwarf months of compute savings, and pricing differs sharply by provider, with OCI egress materially cheaper than the hyperscalers and the others charging more per gigabyte out. Model both the one off egress to leave and any ongoing transfer between estates afterwards. Second, the operating capability you must rebuild: the staff, tooling, monitoring, and resilience the cloud provided as a service now become your responsibility, and that cost is ongoing. Third, the elasticity and reach you forfeit, which has a real value even for a steady workload if its demand profile ever changes. Price all three before the hardware comparison, because they routinely flip an apparently obvious move.
A media company reviewed its estate for repatriation and found only two of roughly thirty production workloads qualified: a steady high utilisation transcoding pipeline and a large stable media archive, both running near constant load with predictable growth. The remaining workloads were spiky, audience driven, or dependent on managed services and stayed in the cloud. Pricing the move showed the archive egress was significant but one off, and colocating the two workloads beat their rented footprint on a multi year view, while the rest were optimised in place through rightsizing and commitment coverage rather than moved. The blended result left the estate materially lighter. Figures are verified against billing data and anonymised.
How should you decide across the portfolio?
Score every significant workload on utilisation steadiness, demand predictability, data gravity, and dependence on managed services, then place each one: optimise in the cloud, keep as is, or evaluate for repatriation. Most workloads optimise in place, a few are genuine repatriation candidates, and almost none justify a wholesale exit. The discipline is to treat repatriation as one option within a cost optimisation program, not a destination, and to apply the same numerate, buyer side rigour to leaving the cloud that you apply to staying.
Frequently asked questions
Which workloads are good repatriation candidates?
Which workloads should stay in the cloud?
Does egress cost make repatriation uneconomic?
Decide repatriation workload by workload, on the numbers
We help engineering and finance leaders score their estate, model the egress and operating cost of leaving, and decide which workloads to repatriate, which to keep, and which to optimise in place, as an independent advisory with zero provider commissions and no stake in the answer. Our guarantee: we reduce your cloud spend or we reimburse our service fee, on a Fixed Fee or no risk Gainshare basis. Read the cross cloud cost optimization guide, see how to handle right placing workloads across clouds, and subscribe to The Cloud Spend Navigator.
Put a defensible number on your cloud spend.
No provider in the room, no published price list. Tell us your footprint and we will scope the savings against your billing data — we reduce your cloud spend or we reimburse our service fee.
The Cloud Spend Navigator: what changed in cloud pricing, commitments, and FinOps — no vendor spin.