Bring It Home, Carefully: A UK Team's Field Guide to Cloud Repatriation

Every few years the industry rediscovers an idea and treats it like a revelation. This time it's bringing workloads back out of the public cloud. Expect the conference circuit to call it 'repatriation' and the vendor decks to call it 'sovereign infrastructure'. Your finance director will call it 'the thing that saves us money'. They are all partly right, which is the problem.

Here's the position I'd take into any UK boardroom in 2026: repatriation is a legitimate tool, badly oversold as a strategy. Most organisations should move something. Almost none should move everything. And the difference between a good decision and an expensive one usually comes down to whether you were honest about your operational capability before you signed the purchase order.

First, a reality check on the R-word

'On-premises' in 2026 rarely means a server under someone's desk. It means colocation in a proper facility, a private cloud platform, an edge box, or a smaller sovereign provider with UK-owned infrastructure. Some of it is genuinely cheaper. Some of it is just a different flavour of the same bill, minus the elasticity and plus a five-year depreciation curve.

The question is never 'cloud or not cloud'. It's 'which workloads suit which delivery model, given our people, our regulators and our appetite for hardware refresh cycles'.

The three questions that actually decide it

One: is this a compliance driver or a cost driver? These are completely different arguments and they get muddled constantly. If a regulator, a client contract or an internal risk appetite genuinely requires certain data to sit in specific infrastructure you control, that's a driver you can't argue with - and cost becomes secondary. If the driver is purely the bill, you need a much sharper business case, because the bill you're comparing against is usually the bill before anyone did any optimisation.

Two: what does the workload actually look like? Steady, predictable, long-running and data-heavy? That shape often does well on owned or reserved infrastructure. Spiky, seasonal, experimental or short-lived? That's where public cloud earns its keep and where moving home gets you a very expensive idle rack.

Three: who's going to run it? Not who'll run it in the slide deck. Who's on call on a Saturday in February when a firmware update takes out a storage array? If the honest answer is 'we'll hire for that', add the salary, the recruitment time and the six-month knowledge ramp to your business case. It's remarkable how often that addition flips the decision.

A rough scorecard you can use

Score each workload from one to five on four axes, then total:

• Predictability - how stable is demand, month to month?
• Data gravity - how much data, and how much of it moves?
• Regulatory pull - how strong is the case for controlling where it lives?
• Operational appetite - do we have the skills and the willingness to run it?

High scores on all four: strong repatriation candidate. Low on predictability and operational appetite: leave it where it is, and stop arguing about it.

Warning signs you're doing it for the wrong reasons

• The bill you're comparing against is unoptimised. If nobody has done rightsizing, tag hygiene or commitment planning, you're not comparing cloud to on-prem. You're comparing waste to a spreadsheet.
• The business case assumes zero staff cost. Hardware is the easy number to find. People are the number that sinks projects.
• Nobody has mentioned exit costs. Egress, migration effort, retraining, contract termination. These belong in the model, not the appendix.
• The driver is a grudge. Senior people who had a bad experience with a cloud migration five years ago are not, on their own, a reason to reverse it.
• There's no plan for peak. The whole point of owned infrastructure is that you buy for the worst day. Someone needs to look the finance director in the eye and explain why that capacity sits idle forty weeks a year.

Workloads that should almost always stay in the public cloud

• Anything customer-facing and spiky. Website front ends, ticketing, campaign landing pages. Traffic doesn't read your capacity plan.
• Analytics and experimentation. Data science teams change their minds weekly. Elasticity is the feature.
• Disaster recovery. Paying for a second data centre that never gets used is the least popular line item in any budget. A warm standby in a region you don't normally touch is cheaper and more honest.
• Anything you can't staff. If the skills gap is real, don't build a monument to it.
• New products and pilots. Prove the thing works before you buy metal for it.

Workloads that often do fine back on your own kit

• Long-running batch processing and overnight reconciliation.
• Large, stable document and media archives with modest access patterns.
• Legacy line-of-business systems that were never designed for cloud-native patterns and have been repackaged at great expense ever since.
• Internal developer platforms where you already have the skills and the demand is boringly predictable.

The middle path nobody markets properly

The most interesting UK option isn't a binary. It's deciding, deliberately, what 'sovereign enough' means for you, then buying that. For a lot of organisations that's a UK region from a mainstream provider plus contractual commitments on data location and access. For others it's a smaller UK-owned provider, or colocation with your own control plane on top. For a few it genuinely is racks in a facility you can drive to.

The engineering discipline that makes any of this work is exit-readiness: containerised where sensible, data in open formats, no accidental dependence on one provider's proprietary glue, and a documented plan for moving a workload in weeks rather than years. That discipline is worth having regardless of which way you're heading.

The bit people forget

The public cloud didn't win because it was cheap. It won because it was someone else's problem at 3am.

Repatriation means taking that problem back. Sometimes that's exactly right, and you'll save real money and sleep better about where your data sits. Often it's a trade you haven't fully costed. Decide with your eyes open, put the people cost in the model, and move one workload before you move twenty.

Bring it home - but bring a spreadsheet, not a slogan.