Cloud Repatriation: When Teams Move Workloads Back

What repatriation actually describes

Repatriation means moving a workload out of a public cloud and onto infrastructure with a different cost model: leased dedicated servers, colocated hardware you own, or an on-premises facility.

The word suggests a reversal of a decision, and that framing has made the topic unusually noisy. In practice, almost nobody leaves entirely. What happens is selective: a handful of workloads with particular characteristics move, and the rest stay where the elasticity and the managed services are worth paying for.

Treating it as a per-workload calculation rather than a strategic reversal is the difference between a project that saves money and one that trades a predictable bill for an unpredictable set of new responsibilities.

Which workloads are genuine candidates

The cloud's pricing advantage comes from elasticity and from services you would struggle to run yourself. Workloads that use neither are the ones worth examining.

The inverse list is equally useful. Spiky workloads, anything leaning on managed services, small estates without operations staff, and systems under active architectural change are poor candidates whatever the invoice says.

Doing the comparison honestly

Most published repatriation savings compare a cloud bill against hardware list prices, which is not a comparison at all. An honest model includes everything the provider was doing on your behalf.

• Hardware, including spares, because a failed disk at three in the morning is now your problem.
• Redundancy you previously got implicitly: a second power feed, a second network path, a second site for recovery.
• Facility costs if you colocate: rack space, power, cross connects, remote hands.
• People. This is usually the largest line and the one most often omitted. Someone has to patch, monitor, replace and respond.
• Software licensing that was bundled into a managed service and now has to be bought or replaced.
• The migration itself, including the egress charge to remove your data and the engineering time to rebuild.
• Refresh cycles, since hardware bought this year is a commitment that has to be replaced in a few years.

Compare over several years rather than monthly, because capital purchases and cloud subscriptions behave differently over time. And compare against an optimised cloud bill, not today's: right-sizing, commitments and storage lifecycle rules often close a surprising share of the gap without any migration at all. The purchasing models are explained in on-demand, reserved and spot pricing.

Where repatriated workloads go

Full on-premises ownership is only one option, and for most organisations it is the least attractive one.

Leased dedicated servers are the most common destination. Providers such as Hetzner and OVHcloud rent physical machines on monthly terms with bandwidth included, which removes the capital purchase and the hardware replacement burden while keeping most of the cost advantage. The trade-offs against cloud instances are set out in dedicated servers versus cloud VMs.

Colocation suits organisations that want to own the hardware but not the building. You buy the machines and rent the space, power and connectivity.

Private cloud on owned hardware, using a virtualisation or container platform, recreates some of the self-service experience internally. It is the most capable option and the most demanding to operate, because you are now running a platform team as well as an application.

A fourth option is often overlooked: moving to a different class of public provider rather than leaving public infrastructure altogether. Value-oriented clouds price bandwidth and steady compute very differently from the hyperscalers while keeping the API-driven provisioning that made the cloud attractive. For many teams chasing a bandwidth or steady-state bill, this captures most of the saving with none of the hardware responsibility.

For the first of these, the account listings for Hetzner and OVHcloud describe what each provides, and the two are compared directly in Hetzner versus OVHcloud.

What you give up

The capabilities that disappear are easy to overlook because the cloud provided them without being asked.

Elasticity goes first. Adding capacity becomes a procurement exercise measured in weeks rather than an API call measured in seconds, which changes how you plan and how you handle unexpected demand.

Managed services go next. Automated database backups with point-in-time recovery, object storage that replicates itself, load balancers that heal, and identity services all become software you install, monitor and upgrade.

Geographic reach goes too. Serving users on another continent meant selecting a region; now it means a second facility or a content delivery arrangement.

And the compliance paperwork changes. The provider's attestations covered the physical and infrastructure layers under the shared responsibility model; that boundary moves, and the obligations it covered become yours. The division is explained in the shared responsibility model in plain English.

A staged approach

Treat repatriation as a migration project with an unusual destination, not as an escape. The sequence that works is deliberately slow.

1. Optimise in place first. Right-size, prune, apply lifecycle rules and commitments, and re-measure. Some estates stop here.
2. Pick one workload with the clearest economics and the lowest coupling to managed services.
3. Build the destination and run it in parallel, serving a share of real traffic, for long enough to learn what breaks.
4. Measure the true operational load, including incidents and the hours spent on them, before committing to more.
5. Move the next workload only if the first one improved both the cost and your confidence.

Expect the result to be a hybrid estate rather than a clean exit, which brings its own connectivity and identity work, described in hybrid cloud explained. Budget for the outbound transfer charge as part of the business case, using the guidance in egress costs.

Key takeaways

• Repatriation is a per-workload calculation, not a strategic reversal; almost nobody leaves entirely.
• Steady load, heavy bandwidth, large cold storage and sustained GPU use are the characteristics that point away from the cloud.
• An honest comparison includes spares, redundancy, facilities, licensing, migration and, above all, people.
• Compare against an optimised cloud bill, because right-sizing and commitments often close much of the gap.
• Leased dedicated servers are the most common destination and avoid both capital purchase and hardware replacement.
• Move one workload, run it in parallel, measure the real operational load, and only then decide about the next.

For hardware and bandwidth references, see the Hetzner dedicated server documentation and the OVHcloud bare metal product pages.