Something has changed in the way UK boardrooms talk about cloud. For most of the last decade the direction of travel was one way: public cloud first, everything else by exception. In 2026 I am seeing that assumption questioned in rooms where it would have been close to heresy two years ago, and not by people trying to save money. The organisations moving workloads back to private or sovereign infrastructure are doing it because of where their data sits, who can reach it, and which legal system governs it.
This is the quiet part of a shift the industry has started calling cloud repatriation. It is real, it is accelerating, and it is badly served by the way it tends to be described. Repatriation is not a retreat from the cloud. It is a correction to the idea that one deployment model suits every workload. Industry research this year suggests the overwhelming majority of UK organisations plan to move at least some workloads back over the next two years, yet almost none of them are leaving the cloud entirely. What is happening is more considered than a reversal: leaders are deciding, workload by workload, where each one actually belongs.
What is actually driving it
Cost is the reason people expect me to give, and it is real for steady, predictable workloads where hyperscale pricing and egress fees stop making sense at scale. But cost is rarely what starts the conversation. Three other pressures do.
The first is regulation. The rules governing financial services, healthcare and the public sector are tightening around data locality and operational resilience, and the questions auditors ask now are far more specific than they were. It is no longer enough to say your data is somewhere in the cloud. You are expected to know the country, the jurisdiction and the recovery position.
The second is jurisdiction, and this is the one that keeps senior people awake. If your provider is headquartered under a foreign legal regime, that regime can, in certain circumstances, compel access to your data regardless of where it is physically stored. For a UK organisation handling regulated or sensitive information, that is a governance question rather than a technical one, and it does not go away because the servers happen to sit in a London region.
The third is resilience, which the past couple of years have pushed up every agenda. High-profile breaches at well-known UK businesses have made boards ask an uncomfortable question: if something goes wrong, do we actually know where our data lives, who can touch it, and how quickly we recover? A surprising number of organisations cannot answer all three with confidence. The focus is shifting away from prevention alone and towards the speed and certainty of recovery.
Where it makes sense, and where it does not
I want to be balanced here, because the honest answer is that repatriation is the wrong move for plenty of workloads. Elastic, bursty, globally distributed applications, and anything that genuinely benefits from hyperscale scale and reach, usually belong exactly where they are. The public cloud is extraordinary at what it was built for, and moving those workloads home to prove a point is expensive and pointless.
The workloads that repatriate well tend to share a profile. They are steady rather than spiky, so you are not paying for elasticity you never use. They are data-heavy, where egress charges quietly compound. And they are regulated or sensitive, where control and locality carry real weight. Databases of record, core line-of-business systems and long-term regulated data are the obvious candidates.
For most organisations the destination is not on-premise or hyperscale as a binary choice. It is hybrid. The right question is not whether to use cloud, but which environment earns a given workload, and the maturity is in being able to answer that with evidence rather than reflex.
Assess resilience and sovereignty together, not separately
The most common mistake I see is treating data sovereignty and operational resilience as two projects owned by two teams. Compliance worries about where the data sits. Infrastructure worries about uptime and recovery. They rarely sit in the same meeting.
They are the same question. If you cannot say with confidence where your data resides, who has the legal and technical ability to access it, and how fast you can restore it after an incident, then you do not fully have either sovereignty or resilience. You have assumptions. The organisations getting this right assess the two together, as a single view of where a workload runs, who governs it, and what happens on the worst day. That one framing does more to sharpen a cloud strategy than any individual migration.
A practical readiness view for leaders considering the move
If you are weighing this up, a few things separate the moves that succeed from the ones that create new problems.
Start by classifying, not migrating. Map your workloads and your data before you touch anything: which are regulated, which are sensitive, which are steady, which are truly elastic. Most organisations discover their estate is more mixed than they assumed, and that only a portion genuinely needs to move.
Understand the exit before you plan the entrance. Egress costs and architectural lock-in are the reasons repatriation projects stall or overrun. Know what leaving actually involves before you commit to a timeline.
Be honest about skills. Running sovereign or private infrastructure well requires networking, virtualisation, security and backup expertise that is in short supply. When you step away from a hyperscaler’s automated tooling, someone has to own the monitoring, patching and recovery that used to come bundled in. That does not make the move wrong. It means the operating model has to be planned as carefully as the technology, whether that capability sits in-house or with a partner.
And resist the instinct to lift and shift in reverse. The workloads worth moving are worth re-architecting for the environment they are moving to. A thoughtless migration home is no better than the thoughtless migration out that many organisations are now unwinding.
Cloud repatriation is not a movement to join or a trend to follow. It is a set of individual decisions, made workload by workload, about control, cost and risk. The organisations that will look sensible in three years are not the ones that moved everything, or nothing. They are the ones that stopped defaulting, and started deciding.
Matt Burden
Matt Burden is the Founder and Managing Director of BlackBox Hosting, a UK-incorporated provider of managed, private and sovereign cloud services, operating from two Tier 3+ data centres in London under UK law only. He works with organisations across financial services, healthcare and the public sector on data sovereignty, resilience and cloud strategy.
