Sovereign cloud · Part 4

How to decide, one workload at a time.

You don't need one answer for the whole organisation. Decide workload by workload, ask the same questions each time, and design so you can change your mind later.

Talk it through →See it in a playbook

The approach

Decide workload by workload

A workload is one system, or one group of systems, together with its data. Treating each one separately avoids paying for sovereignty where you don't need it, and missing it where you do.

List your workloads, the data each one holds, and who owns each.
Classify the data: personal, special category (such as health data), commercially sensitive, or government classified.
Note the rules and contracts that apply: regulators, customers, and government terms.
Agree your organisation's risk appetite for jurisdiction, concentration and supplier failure. That's a judgement for the board, not a technical question.
Place each workload on the spectrum in Part 3, and write down why.
Review the choices when something changes: new rules, new products, or a shift in your risk appetite.

Checklist

Questions to ask for each workload

Copy them into your next planning meeting

What data does it hold, and how is it classified? Does it include personal data, special category data, or anything above OFFICIAL?
Which regulators and rules apply? For example the FCA and PRA, the ICO and UK GDPR, NHS data guidance, or government and defence security requirements.
Do any contracts require UK hosting, UK-based support, or security-cleared staff?
If personal data leaves the UK, including through remote support access, what's the legal route for the transfer, and has the risk been assessed?
Who holds the encryption keys? Could the provider read the data if it were compelled to?
Who can operate and access the service, from where, and how is that logged?
How long could this service be down before real harm is done, and does the design meet that?
What's the exit plan? How long would it take, and what would it cost, to move this workload?
Does it need a particular AI model or managed service that only exists on certain platforms?
Do we have, or can we hire, the skills to run it on the chosen platform?
What's the full cost over five years, including people, data transfer charges, running two platforms during migration, and exit?
For public sector buyers, which procurement route applies? G-Cloud 15, for example, is the first G-Cloud framework run under the Procurement Act 2023.

Keeping options open

Patterns that keep you portable

Portability has a cost. Using only the features every platform shares can mean giving up useful managed services. The aim is to be deliberate: use platform-specific services where they earn their place, and know what it would take to leave.

Containers and Kubernetes

Package applications in containers and run them on Kubernetes, the open-source system for running containers. The hyperscalers and most smaller providers offer managed Kubernetes, so the same application can move with less rework.

Infrastructure as code

Define networks, servers and permissions in code, with tools such as Terraform or OpenTofu. You can rebuild an environment elsewhere from the same definitions, changing only what differs between platforms.

Open data formats

Keep data in open formats, such as Parquet and Apache Iceberg for analytics, and widely supported databases such as PostgreSQL. Moving data then becomes a copy, not a conversion.

Open-weight models behind one interface

Put AI models behind a single internal interface, so you can switch between a frontier model and an open-weight model for each use case. Many platforms offer OpenAI-compatible interfaces, which helps.

Keys you control

Use customer-managed or externally held encryption keys, so you decide who can read the data, whichever platform it's on.

A written, tested exit plan

Record how you'd move each critical workload, how long it would take and what it would cost, and test parts of it. The PRA already expects exit plans for material outsourcing, covering both planned and stressed exits.

Common outcomes

Where organisations often end up

None of these is the right answer in general. Each is the right answer for some organisations.

Everything on a UK public cloud region, with customer-managed keys, good resilience design and a tested exit plan.
Mostly public cloud, with a few sensitive workloads on a sovereign offering, private cloud or on-premises.
A European or UK provider as the main platform, with a hyperscaler used for specific services, such as a frontier AI model, where the risk is acceptable.
Mostly private cloud or on-premises, as is common in defence, national security and parts of healthcare, with public cloud for public-facing services.

How I work

Lead or support, whichever way you go

I can lead the architecture. That means running the workload assessment with your team, setting out the options and trade-offs in plain terms for your board, designing the target architecture, and taking it through build and migration.

Or I can support your architect, whether they're in-house or from a partner. I take on the platform, security, AI or migration pieces, review designs, and add senior hands-on capacity. Your architect stays in charge.

I've worked on AWS, Azure, Google Cloud, on-premises and hybrid estates. I have no platform to sell and no view on which country or provider you should choose. Where the work needs more hands, I bring in people I trust, or work inside your partner's team.

The rest of the guide

Keep reading.

Sovereign cloud, explained

What people mean by sovereign cloud, why it's in the news, and what it could mean for your organisation. A neutral guide that doesn't argue for or against any option.

Why it matters, and why it may not

The main arguments for sovereign cloud, each set next to its strongest counterpoint. Neither column is the right one. Which carries more weight depends on your situation.

Your options

Sovereignty isn't a yes or no. It's a spectrum, and each option gives you more control in some areas and less in others. Here's what each gives you, and what it doesn't.

FAQ

Questions people ask

Something not covered here? Ask me directly →

Where should we start?

With a list of your workloads and a classification of the data in each. Most of the decision follows from knowing what data each system holds, and which rules and contracts apply to it.

Should we move everything at once?

Rarely. Moving workloads in order of risk and readiness, starting with a pilot, lets your team learn the new platform before the critical systems move.

Can we change our minds later?

Yes, if you plan for it. The portability patterns above lower the cost of moving. Without them, moving later is still possible, but slower and more expensive.

Will you tell us if we don't need sovereign cloud?

Yes. If a standard UK public cloud region with good controls meets your needs, I'll say so. If a workload needs more control, I'll say that too, and explain why.

Sources, checked 9 November 2026

Whichever way you go, it has to work.

There's no single right answer. It depends on your data, your regulators, your risk appetite and your budget. I'll help you weigh it up, then lead or support the delivery of whichever you choose.

Book a call →How I work alongside your team

Sam NaseemBirmingham, UK · UK & Europe

Available now