Migration · Cloud repatriation
Cloud repatriation
Repatriation moves workloads out of public cloud into colocation. It pays when load is steady, heavy and predictable — the profile where you are renting elasticity you never use. Break-even is typically 12 to 24 months once hardware, colocation, migration labour and the operations headcount you now carry are all in the model. The workloads that fail this test are the bursty ones, and they should stay where they are.
Signal check
Repatriation is a workload-by-workload decision, not an estate-wide one. Score each candidate against both columns: a workload that lands mostly on the left is worth modelling, and one that lands mostly on the right will cost more outside cloud no matter how the spreadsheet is arranged.
| Repatriate | Keep in cloud |
|---|---|
| Steady utilisation above ~60% around the clock | Bursty, seasonal or event-driven load |
| Large, predictable egress volumes | Traffic dominated by unpredictable spikes |
| Data gravity — the dataset is large and mostly static | Data that must sit next to managed cloud services |
| Compliance or sovereignty pushing toward a known location | A genuinely global user base needing many regions |
| Sustained GPU training load billed by the hour | Experimental work with idle weeks between runs |
| An existing infrastructure team with capacity | A team already at its limit, with no platform on-call |
Modelling the break-even
The comparison that decides it is annual cloud spend for the workload against annual owned cost, with every line of the second column filled in honestly. Four lines are routinely missing from repatriation business cases, and each of them is large.
| Line | Often forgotten because |
|---|---|
| Platform operations headcount | Cloud bundles it into the bill, so it never appeared as a line item before. Patching, capacity, firmware, hardware failure and out-of-hours response all become yours. |
| Egress to get the data out | A one-off, but for a large dataset it can reach six figures — and it is charged by the provider you are leaving. |
| Hardware refresh cycle | Year-one capex looks decisive until you amortise over a realistic four to five years and add the refresh that follows. |
| Headroom you must now buy upfront | Cloud let you size for today. Owned infrastructure has to be sized for the peak you expect, and that spare capacity is paid for from day one. |
The colocation TCO calculator models the colocation side, and the colocation vs cloud TCO guide works through the full comparison with worked numbers.
How the migration differs
The six-phase method holds, but three phases change shape. Discovery is harder: cloud estates drift, and the resources in the console are rarely the architecture anyone documented — tag coverage is usually the first thing to fix. There is no logistics phase, and in its place sits hardware procurement, which carries lead times of its own. And the cutover is a traffic shift rather than a truck, which means rollback is genuinely cheap for once: leave the cloud environment running until validation is signed off, and reverting is a DNS change rather than a weekend.
One thing that does not change is the network build. Circuits into the colocation facility, and connectivity back to whatever stays in cloud, run on the same 60–120 day carrier lead times as any other migration. Order them the week the contract is signed.
Where to land it
- Price index — what the target market costs per kW per month, published openly
- Facility catalog — 202 facilities with power, density and operator
- Certification directory — filter by the compliance your workload carries
- Latency matrix — round-trip to the regions where whatever stays in cloud lives
- GPU price tracker — if the workload being repatriated is training or inference
Frequently asked
What is cloud repatriation?
Moving workloads out of public cloud back onto infrastructure you own or lease — typically colocation, occasionally an on-premises room. It is rarely all-or-nothing: the common pattern is repatriating a steady, predictable, high-volume workload while leaving bursty and edge-of-the-business services in cloud.
When does repatriation actually save money?
When utilisation is high and steady, egress is heavy, and the workload is large enough that a colocation footprint is efficiently filled. Owned infrastructure is cheap per unit and expensive per idle hour; cloud is the opposite. A workload sitting at 70%+ around the clock is the classic candidate, and one that runs for four hours a day is not.
What is the break-even period?
Typically 12 to 24 months once hardware capex, colocation, migration labour and the operations headcount you now carry are all counted. Anything shorter usually means the model omitted staffing or the cost of running the platform yourself; anything longer means the workload probably belongs in cloud.
What should stay in public cloud?
Bursty and seasonal workloads, anything genuinely global that would otherwise need multiple sites, early-stage products whose shape is still changing, disaster recovery capacity you want to pay for only when it runs, and managed services you would have to rebuild and then staff. Repatriation is a cost decision about steady load, not a philosophical position on cloud.
What is the biggest hidden cost of repatriation?
People. Cloud bundles platform operations into the bill; colocation does not. Patching, capacity planning, hardware failure, firmware, monitoring and out-of-hours response all become your headcount. Repatriation models that beat cloud on paper and lose in practice almost always failed to price this line.
How is repatriation different from a normal data center migration?
There is no physical move — nothing gets loaded onto a truck. In exchange you take on hardware procurement lead times, a capacity sizing decision that cloud used to make elastically for you, and data egress charges that can run into six figures for a large estate. The phase structure is the same; discovery is harder, because cloud estates drift and the inventory in the console is rarely the inventory in the architecture diagram.
Modelling a repatriation?
Tell us the workload profile and the markets you are considering. We will come back with facilities that fit on power and compliance, plus benchmark rates so the owned side of your model uses real numbers rather than list prices.