Cloud Repatriation: When Moving Workloads Back Actually Makes Sense
The workloads where the maths favours moving
Repatriation makes financial sense for steady, predictable, compute or storage heavy workloads that run at high utilisation around the clock — large databases, media processing, long-running analytics, high-volume egress. The cloud's core value is elasticity, and if your utilisation curve is flat you are paying an elasticity premium you never use. Conversely, bursty workloads, anything seasonal, and small services benefit enormously from on-demand capacity and should stay.
Count the costs people leave out
Hardware is the easy part. The full comparison includes data centre space and power, redundancy across sites, hardware refresh over a five-year cycle, spares, network capacity and transit, licensing, and — the big one — the people who operate it around the clock. A realistic staffing model for a resilient owned platform is several engineers with real depth, and they are neither cheap nor easy to hire. Comparisons that show dramatic savings often quietly assume existing staff absorb the work.
Egress and data gravity shape the decision
Data transfer out of major clouds is priced in a way that becomes significant at scale, and it is one of the strongest drivers of repatriation for content-heavy businesses. It also works in the other direction: once petabytes live in a cloud provider's storage, moving them out has a real one-off cost that must be amortised in the business case. Model the transition cost explicitly, including the parallel-running period, rather than comparing steady states only.
Hybrid is the realistic destination
Very few organisations should go all the way in either direction. The common sensible pattern is a stable core — databases, base compute load, storage — on owned or colocated hardware, with the public cloud used for burst capacity, disaster recovery, global edge delivery and managed services that would be painful to run yourself. Design for that from the start with containerised workloads and infrastructure as code, and the placement decision becomes an ongoing optimisation rather than a one-way door.
The multi-cloud version of this conversation
Multi-cloud is often pitched as leverage against pricing and as resilience. In practice it delivers less of both than expected while doubling the operational surface, unless you deliberately keep to portable primitives and accept giving up the higher-level managed services that make each provider productive. Genuine reasons exist — regulatory requirements for provider diversity, acquisitions, specific regional availability — but 'avoiding lock-in' on its own usually costs more than the lock-in would have.
How to decide with evidence
Take your three largest cost centres and model each one honestly under both options over five years, including staffing and migration. Include a sensitivity analysis on growth: what if traffic triples, what if it halves. Most companies doing this exercise find one or two workloads where moving is clearly worth it, and a majority where it is not. That is a good outcome, and it is a far better basis for a decision than a case study about a company with a very different shape.
Have a project that needs this kind of thinking?
Let's talk through what you're building — free consultation, no commitment.
Get in Touch