Sovereignty needs an exit, not just an address

In European boardrooms and ministries, “digital sovereignty” usually means one thing: move our workloads from a US hyperscaler to a European provider. EU company, EU data centres, EU law. Done.

That’s a necessary step. But on its own, it’s changing landlords. A European provider is where sovereignty starts. Being able to leave that provider for another European one is what completes it.

A European provider is one acquisition away from not being European

In November 2025, the American IT company Kyndryl announced it would buy Solvinity, the Amsterdam-based provider that hosts DigiD, the login millions of Dutch people use for their taxes, healthcare and local council. The platform behind it would have come within reach of the US CLOUD Act.

In May 2026 the Dutch government blocked the deal on national security grounds, and in August Kyndryl gave up. But it took a five-month investigation and a state secretary stepping in. And Solvinity’s own owner, a British private-equity firm, is still contesting the ban: the “sovereign” provider’s shareholders wanted to sell.

Most organisations won’t get that protection. If your European provider is sold, merged or goes bankrupt, nobody will veto it on your behalf.

My definition

You are sovereign when you run on European providers and can move between them, on your own schedule, without rewriting your applications and without anyone’s permission.

Both halves matter. A European provider keeps you under European law today. Being able to move keeps it that way tomorrow. A sale, a price increase or a bankruptcy then stops being a crisis and becomes a routine migration. A Dutch provider you can’t leave is still lock-in, just closer to home.

Portability comes from standards, not from passports

You can’t migrate quickly if your applications depend on one provider’s proprietary services. That’s why I argue for only using managed open source: applications that talk PostgreSQL, S3, AMQP and Kubernetes run on any provider that offers those. As Bert Hubert’s cloud ladder shows, every rung you climb into proprietary services brings you closer to “a lifelong partner”. Nationality decides which law applies. The interfaces you build on decide whether you can leave.

But “use open source” is advice, not a guarantee. A customer can’t easily check whether provider X’s managed Kubernetes really behaves like provider Y’s, or whether their Postgres can actually be replicated out. That’s where a standard helps. The Dutch public sector already has one example: Haven certifies Kubernetes clusters with an automated checker, so an application built once runs on any compliant cluster. I’d like to apply that idea to the whole environment an application needs.

“Didn’t Gaia-X already try this?”

It tried something that sounded similar. Bert Hubert called it an expensive distraction back in 2024, and the reasons are clear by now:

It stopped at the first half. Its labels focused on where a provider is based and which law applies, not on whether you can leave.
It standardised paperwork, not services. Ontologies, trust frameworks and signed claims about compliance: in Bert’s words, “two steps removed from being useful”. It never defined what a database, a bucket or a cluster must actually do.
It was top-down, with the hyperscalers at the table. Years of consensus-building between parties with very different interests, and very little running software.
It had no buyer. Nobody was required to use the result, so nobody did.

Why this can work

It tests behaviour, not claims. Does it pass the CNCF Kubernetes conformance tests? Can I logically replicate my Postgres to another provider? Does my S3 client work unmodified? Most of these tests exist already. No self-assessments, no stack of PDFs.
The final test is an actual move. The stamp requires a yearly exit drill: migrate a reference workload to another compliant provider and measure how long it takes. Paper can’t fake that.
It’s written by European providers, customers and engineers. Not by the companies it’s meant to make us less dependent on.
It starts with a buyer. If governments and regulated sectors require the stamp in tenders, providers have a reason to get it.

A first draft of the requirements

Jurisdiction

Headquartered and controlled in the EU, operating from EU data centres.
A change of control triggers the exit clauses, at no cost to the customer.

Platform

CNCF-conformant Kubernetes, at most two minor versions behind upstream, with standard storage, load balancing and Gateway API.
Managed PostgreSQL on upstream versions, with logical replication to a destination outside the provider.
S3-compatible object storage, and a message broker on an open protocol such as AMQP or Kafka.
OIDC login with your own identity provider, and encryption keys you can hold outside the provider.
Everything provisionable through an open API with an OpenTofu provider. No console-only features.

Exit

All data exportable in open formats, with exit egress costs capped in the contract.
A contractual obligation to assist with exit.
A successful yearly migration drill to another compliant European provider.

Run the checker, run the drill, get the stamp, publish the result.

Why providers should want this

A compliant provider can say: if your application runs on any compliant European platform, it runs on ours. Being easy to leave is what makes them easy to choose, and providers compete on price, service and reliability instead of on how hard it is to get out.

It also gives Bert’s idea of European Cloud Modules, shared open-source building blocks that many providers can run, a clear target: the building blocks customers will check for.

What it doesn’t solve

An exit only helps if there’s somewhere to go: Europe needs several providers that offer good managed databases, queues and identity, not just virtual machines. And it doesn’t cover SaaS such as email and office suites. Those need a different answer.

Let’s build it

Don’t stop at asking where your provider is based. Also ask how fast you could leave it for another European one. I’d rather have a small, testable standard that ten providers actually pass than a grand framework that nobody can run. If you work at a provider, a government body, or a company that cares about this, I’d love to talk. You can find me on LinkedIn.