The Repatriation Argument

Cloud exit is real, it happens more often than vendors admit, and sometimes it is the right call.

When "going back" is actually going forward

Repatriation — moving a workload from public cloud back to on-premises infrastructure or colocation — sits in an awkward position in industry discourse. Cloud providers have no incentive to discuss it. Analysts who live on vendor relationships tend to frame it as a failure of cloud strategy rather than a legitimate outcome. So the honest picture gets suppressed, and engineers who raise it internally often find themselves defending a position that looks, superficially, like regression.

It is not regression. It is a straightforward question of unit economics and operational fit, and the answer genuinely varies.

The conditions that make repatriation worth serious analysis are not exotic. The clearest trigger is sustained, predictable, high-utilisation compute. On-premises wins when a workload runs at or near full capacity around the clock, because the cloud's core value proposition — elasticity — is delivering nothing. You are paying the on-demand premium, or burning reserved-instance commitments, for a static load that a purchased server would handle for a fraction of the three-year total cost. The crossover point depends on hardware costs, power, and staffing, but the direction of the arithmetic is consistent: somewhere above roughly sixty to seventy percent sustained utilisation, owned infrastructure starts to look competitive, and the gap widens as utilisation climbs further.

The second common trigger is egress. Data-transfer charges are structured to be invisible at design time and painful at scale. A workload that moves large volumes of data to end-users or to other systems outside the provider's network accumulates egress costs that were never modelled in the original business case. When egress alone becomes a material line item — not a rounding error but a figure that changes decisions — repatriation or a colocation move with direct interconnect becomes worth costing properly.

Latency is the third lever, though it is more nuanced. Physics constrains what a distant cloud region can offer regardless of tier or configuration, and some workloads — certain financial systems, manufacturing control planes, real-time data pipelines — have latency budgets that a public cloud region simply cannot meet from a given geography. Colocation in a carrier-neutral facility close to the point of need is sometimes the only path that works.

What the transition actually costs

The case for repatriation is strongest on paper. The execution is harder, and this is where proponents often underestimate.

Hardware procurement is the obvious cost, but it is not the largest hidden one. The larger costs are operational: recruiting or rebuilding the infrastructure team that was allowed to atrophy during the cloud years, re-establishing relationships with hardware vendors and support contracts, and — critically — redesigning the workload for an environment that does not have managed equivalents of every cloud service it depends on. A workload that has grown tentacles into managed databases, object storage APIs, identity services, and provider-specific messaging queues cannot be lifted and shifted back any more cleanly than it could be lifted and shifted into the cloud in the first place.

This is the repatriation trap that mirrors the original lift-and-shift trap: moving the workload without rethinking its dependencies produces a system that is now on-premises hardware but still calling cloud APIs, paying egress on every transaction, and defeating the purpose of the move entirely.

Colocation is frequently the more realistic option. It eliminates hardware disposal and facility management, preserves most of the capital flexibility argument, and positions the workload close enough to cloud networks that a hybrid model — owned compute for the stable base, cloud burst capacity for peaks — remains operationally viable. The overhead is lower than fully on-premises, and the reversibility is higher.

The transition timeline is also consistently underestimated. Hardware lead times, network provisioning, application refactoring, and parallel-run periods to validate parity before cutting over add up. A workload that looks like a six-month project typically takes longer, and the cost of running both environments in parallel during migration is real.

What this means in practice

The execution is harder, and this is where proponents often underestimate.

None of this is an argument against cloud. It is an argument against permanence — against treating a cloud deployment as irreversible and against letting sunk-cost logic prevent a periodic honest reassessment.

The questions worth asking every couple of years are mechanical: what is the actual utilisation profile of this workload, what are we paying in egress, what managed services have we coupled to, and what would it cost — fully costed, including transition — to run this elsewhere? If the cloud answer still wins, fine. If it does not, the fact that a migration happened in one direction does not mean it cannot happen in the other.

Repatriation is not a retreat. It is what rational infrastructure management looks like when the numbers change.