EU Sovereign Cloud Migration: A CTO's Guide (2026)

The conversation in European boardrooms changed in late 2025. Between the EU Data Act becoming fully applicable in September, the European Commission publishing its Cloud Sovereignty Framework in October, and a fresh round of US executive orders rattling cross-border data flows, the question of who really controls your infrastructure stopped being theoretical. If you are a CTO at a UK or EU enterprise running on AWS, Azure, or Google Cloud, you have probably already had the meeting where your board, your legal team, or one of your larger clients asked some version of the same question: are we actually European, or do we just have European-shaped data centres?

The honest answer for most organisations is the second one. This guide explains why that distinction matters, what genuine sovereignty looks like, who the credible EU-native providers are in 2026, and how to plan a migration that does not turn into a two-year archaeology project.

Why is an EU region not enough for GDPR compliance?

An EU region is not enough because the law that reaches your data follows the provider's corporate nationality, not the data centre's postcode. The simplest way to see this is the US CLOUD Act. Passed in 2018, it compels any company incorporated in the United States to disclose data on request from US authorities, regardless of where in the world that data is physically stored. AWS Frankfurt, Azure Dublin, Google Cloud Belgium: all of them sit inside this jurisdictional envelope because their parent companies are American. A US court order can be served in Seattle and reach into a data centre in Hesse, and the operator is legally obliged to comply. There is no European data residency configuration that fixes this.

The 2020 Schrems II ruling from the European Court of Justice made this concrete in EU law. The court invalidated the EU-US Privacy Shield on the grounds that US surveillance law is fundamentally incompatible with the protections GDPR guarantees European citizens. Successor frameworks have not closed the gap so much as papered over it, and a series of European data protection authorities have since issued opinions casting doubt on whether US-controlled cloud services can lawfully process certain categories of personal data at all.

Two more recent developments have hardened this position. The EU Data Act became fully applicable in September 2025, granting customers a statutory right to data portability and obliging cloud providers to actively facilitate switching. And in October 2025, the European Commission published its Cloud Sovereignty Framework — a structured scoring system that defines eight sovereignty objectives across five SEAL levels (0 to 4), now being used as the procurement benchmark for the Commission’s own €180M cloud tender. Sovereignty has moved from a values question to a measurable, contractual one.

The test is straightforward. Is your cloud provider’s parent company incorporated in the European Union? If not, the CLOUD Act applies, and no amount of regional configuration changes that. For a deeper walkthrough of why an EU region inside a US hyperscaler does not resolve GDPR exposure, see The CLOUD Act Problem: Why Your AWS EU Region Is Not GDPR-Safe.

What does genuine EU cloud sovereignty look like?

Genuine sovereignty means four things are true at the same time: the provider is legally controlled from inside the EU, only EU staff can touch the infrastructure your data runs on, every byte including backups and telemetry stays inside EU borders, and you could leave without a rewrite. The Cloud Sovereignty Framework is useful precisely because it forces you to check all four at once rather than stopping at the first one that looks fine.

The first is legal. The provider’s parent company must be incorporated in the EU, the contract must be governed exclusively by EU law, and there must be no chain of ownership or control that exposes the provider to foreign jurisdiction. A French subsidiary of a US holding company is not legally sovereign, however French it feels.

The second is operational. Sovereignty fails the moment a non-EU support engineer can SSH into the infrastructure that hosts your data. The serious EU-native providers have moved to EU-staff-only operations for exactly this reason, and the strictest of them — those certified under Germany’s BSI C5 standard — can demonstrate it with audited evidence rather than promises.

The third is data. All data, all metadata, all backups, all logs, and all telemetry must remain physically within EU borders. This sounds obvious until you start tracing where your provider’s monitoring stack actually sends events, or where your IAM directory replicates to. Metadata leakage is the most common failure mode in otherwise-compliant architectures.

The fourth is technical. Sovereignty is meaningless if you cannot leave. That means open standards, no proprietary lock-in to APIs that exist only in one provider’s ecosystem, and an architecture you can audit. The EU Data Act now reinforces this with statutory portability rights, but the engineering work to make portability real is still yours to do.

The Cloud Sovereignty Framework’s eight objectives map closely onto these four dimensions, scored from SEAL 0 (no sovereignty guarantees) through SEAL 4 (full legal, operational, and technical isolation from non-EU influence). Most workloads do not need SEAL 4. Knowing what level you actually need is the first decision in any serious migration.

Who are the credible EU-native cloud providers in 2026?

Five: OVHcloud, T-Systems' T Cloud Public, STACKIT, IONOS Cloud, and Scaleway. The European cloud market in 2026 is more credible than it was even two years ago, and a CTO no longer has to choose between sovereignty and capability. For a workload-by-workload comparison of the four enterprise-grade options, see OVHcloud vs STACKIT vs T Cloud Public vs Scaleway.

OVHcloud, headquartered in France, is the largest EU-native cloud provider in the world. It runs more than 40 data centres across Europe, offers a full range of IaaS, PaaS, and bare metal services, holds GDPR and ISO 27001 certifications, and is a founding member of Gaia-X. It is the default starting point for a CTO who wants breadth and maturity in a single European vendor. One caveat worth knowing: a 2024 court case involving OVHcloud’s Canadian entity raised questions about cross-jurisdictional reach for the most sensitive workloads, so for SEAL 4 use cases the right configuration matters.

T-Systems, the enterprise arm of Deutsche Telekom, operates T Cloud Public out of Germany and is the provider you choose when regulatory exposure is the dominant constraint. It holds BSI C5 certification — the strictest cloud security standard in Europe and a mandatory requirement for German federal procurement — runs EU-staff-only operations, and is rated a leader in European cloud by both Forrester and ISG. Financial services, healthcare, automotive, and public sector workloads land here for good reason.

STACKIT, backed by the Schwarz Group (the parent of Lidl and Kaufland and Europe’s largest retailer), has been the fastest-growing EU-native cloud provider through 2025 and into 2026. It is BSI C5 certified, offers strong managed services for Kubernetes, databases, and AI model serving, and has built native integrations with ServiceNow and Salesforce that close the enterprise readiness gap many EU providers historically had. For a CTO who wants German jurisdictional protection without the conservatism of legacy telco vendors, STACKIT is the most interesting option in the market.

IONOS Cloud, part of United Internet AG, is the pragmatic choice. It is ISO 27001 certified, has a multi-region EU footprint covering Germany, France, Spain, and the UK, offers solid Kubernetes and IaaS services, and is competitive on price. Financial services teams that need strict EU residency without the premium pricing of the BSI C5 providers tend to find IONOS the easiest landing zone.

Scaleway, owned by the Iliad Group, is the strongest EU option for GPU and AI inference workloads in 2026. The most recent Callista benchmark (February 2026) put its compute value per euro at 4.8x that of AWS, and its developer experience is the best of any EU-native provider — important when you are asking engineers to migrate away from the AWS console. One operational caveat: parts of Scaleway’s own management plane still rely on US-based services, which matters for the strictest sovereignty postures but is irrelevant for most workloads.

Two market signals are worth keeping in mind alongside these providers. The Callista benchmark also showed Hetzner delivering roughly 14.3x the value per compute unit of AWS, which keeps cost pressure on the hyperscalers and reframes the “EU is more expensive” assumption many boards still hold. And in March 2026, OVHcloud’s CEO publicly forecast RAM prices rising 250–300% by year end, driven by AI demand. Capacity planning conversations now have a procurement-timing dimension that did not exist twelve months ago.

Which workloads should you migrate to sovereign cloud first?

First, the workloads that are both urgent and ready: they hold regulated personal data, sit under a client contract that specifies EU residency, or feed AI training and inference, and they can move without a rewrite. Before any of them, the shared services they depend on: identity, secrets, networking, observability, and CI/CD.

Migration is a portfolio exercise. The useful question is not "should we move off AWS?" but "which workloads move first, which wait, and which probably never move?" Three categories are urgent almost everywhere:

Regulated personal data: GDPR special categories, health records, financial transaction data, and any dataset where a data protection authority has already taken an interest in cross-border transfer mechanisms.

Client-contractual workloads: any system where a client contract specifies EU-only residency, or where a client has started asking the questions your board is asking. These pay back fastest, because they turn a contractual risk into a selling point.

AI training and inference data: the EU AI Act has begun to look at where training corpora live and how model weights are derived. Treat this as regulated even if your workload is not yet in scope. Unwinding it later is expensive.

Urgency alone is not enough to schedule a workload. An urgent workload with three hyperscaler-only services wired into it is not ready, and putting it in wave one is how wave one slips. Non-sensitive development and test environments, ephemeral CI, and CDN or edge workloads can stay on the hyperscaler through the whole programme. The goal is to reduce legal and contractual exposure, not to perform sovereignty as ideology.

We cover the scoring method in how to assess which workloads are ready for sovereign cloud migration and the full method for sorting workloads into waves, with a worked plan, in which workloads to migrate to sovereign cloud first.

What is a realistic timeline for a sovereign cloud migration, and what disruption should you expect?

Six to eighteen months for a mid-sized enterprise. Less than six almost always means the hard parts were descoped. More than eighteen usually means nobody committed to a target architecture and the migration is happening in a fog. The disruption the business feels is mostly not downtime; it is slower feature delivery from the teams whose systems are in flight, a period of paying two providers at once, and change freezes around cutovers.

Months one and two are audit and selection: inventory the workloads, classify them by data sensitivity and contractual exposure, map dependencies (always more painful than expected), and pick one or two EU providers for the workload mix. Most mature migrations end up on two providers, often a BSI C5 vendor for regulated workloads and a developer-friendly one like Scaleway or STACKIT for the rest.

Months three to nine are the landing zone and the first waves. Shared services land first, then a harmless pilot, then the urgent-and-ready workloads. By the end of this phase you have production traffic on EU infrastructure and a clear view of where the friction with the new provider lives.

Months ten to eighteen are the harder half: regulated and critical workloads, rehearsed cutovers for anything stateful, and the systematic switch-off of hyperscaler dependencies. Multi-cloud during this phase is legitimate. Multi-cloud as the destination is not; dual operational overhead is expensive and erodes the sovereignty benefit you set out to achieve.

The month-by-month version, with the four kinds of disruption costed and the reasons timelines slip, is in sovereign cloud migration timeline: what is realistic and what disruption to expect.

What does it take to migrate to a sovereign cloud platform?

Seven things, and most programmes that fail are missing one of them: a scored workload inventory built from billing data rather than the CMDB; a wave plan that puts shared services first; a landing zone on the EU provider with identity, secrets, networking, observability, and CI/CD in place before anything customer-facing moves; engineering capacity explicitly carved out per team per wave; a rehearsal of every stateful cutover on production-sized data; a finance model for the months of paying two providers; and a date on which the hyperscaler gets switched off.

Budget is mostly engineering time rather than hosting cost. Several EU providers are cheaper to run than the hyperscalers on raw compute, and the expensive part of the migration is the re-architecture of anything built on proprietary managed services, plus the velocity your product teams lose while their systems are in flight.

Each of these has its own article: readiness assessment, prioritisation and wave planning, and timeline and disruption.

What should you ask an EU cloud provider before signing?

Ask nine questions, in writing, and judge the answers as much by how quickly and specifically they come back as by their content. A marketing deck will not tell you any of this.

Is your parent company incorporated in the EU, and can you provide the chain of ownership in writing?

Are you subject to any non-EU law, including the US CLOUD Act, through any subsidiary, partner, or contractor?

Where are your operations and support staff physically located, and are any of them outside the EU?

Can any non-EU personnel — employees, contractors, or third-party support — access my data or the infrastructure it runs on, under any circumstance?

Where are backups, metadata, logs, and telemetry stored, and how do you prove that they never leave the EU?

What is your current BSI C5, ISO 27001, and GDPR certification status, and where do you stand against the EC Cloud Sovereignty Framework SEAL levels?

How do you support data portability and provider switching under the EU Data Act, and what does an exit actually look like in practice?

What is your supply chain exposure to non-EU vendors — hardware, software, managed services, observability tooling?

Have you ever received a foreign government data request, and what is your written policy if you do?

A serious provider will answer these in writing without hesitation. A provider that hedges, redirects to a sales engineer, or asks why you are asking is telling you something important.

How Looming Tech can help

Looming Tech helps UK and EU enterprises plan and execute sovereign cloud migrations end to end — workload assessment, provider selection, migration delivery, and post-migration compliance support. Our sovereign cloud practice spans OVHcloud, STACKIT, Scaleway, and T Cloud Public, and we work alongside your existing engineering team rather than around it. If you are evaluating your options, or your clients have started asking the questions in this guide, we are happy to have a no-commitment conversation about where you are and what a credible path forward looks like.

Talk to our team →