Sovereign cloud migration: the 7 tests to run before you trust it (lessons from the Dutch tax authority)
The Dutch tax authority stopped moving its office work to Microsoft 365 and stayed on-premises with open source. Here are the seven tests - legal control, metadata residency, key custody, a timed exit drill, latency, service parity and day-2 operability - that European companies should run before trusting any sovereign cloud migration, with pass criteria and the evidence to keep.
The Dutch tax authority (Belastingdienst) dropped its Microsoft 365 public-cloud rollout and chose on-premises plus open source on 5 October 2026, after an independent review found vendor lock-in, rising concentration risk and no workable exit strategy. The trigger was control and reversibility, not price.
Run seven tests before trusting any sovereign cloud migration: (1) legal control of the operating entity, (2) data and metadata residency, (3) encryption key custody, (4) a timed exit drill, (5) latency and interconnect, (6) managed-service parity, (7) day-2 operability by your own team. Each test must produce an artifact an auditor can read.
Sovereignty is a spectrum with five tiers: an EU region of a US hyperscaler, a hyperscaler sovereign offering, an EU-operated joint venture, an EU-owned provider, and self-hosted Kubernetes. Pick the tier per workload, not per company. Hybrid is a legitimate end state.
An EU region answers where the data sits, not who can be compelled to hand it over. The EDPB and EDPS told the European Parliament in July 2019 that CLOUD Act transfers cannot be considered lawful unless backed by an international agreement.
The exit drill is the only test you cannot fake. DORA Article 28(8) already requires exit plans that are "documented and sufficiently tested", and NIS2 Article 21 makes supply-chain risk an explicit obligation, so the drill is a compliance artifact.
Most sovereign migrations pass the legal review, then stall on developer experience. Portability (OCI containers, standard Kubernetes, Postgres, S3-compatible storage, Terraform or OpenTofu) plus self-service tooling keeps both the exit and the velocity cheap.
What actually happened with the Dutch tax authority and Microsoft 365?
The Belastingdienst, together with Dutch Customs and the Benefits agency, formally abandoned its move of office work (Outlook, Teams, OneDrive) to Microsoft 365 in the public cloud in October 2026 and chose "an on-premises solution in combination with open source" instead. The decision followed a July 2026 pause and an independent review that found lock-in, concentration risk and no workable exit, so it was about control and reversibility rather than licence cost.
I have read the parliamentary letters end to end, because this story gets retold badly. Here is what the primary sources confirm:
October 2025, the original decision. The State Secretary for Finance told parliament the authority would proceed with M365, limited to office automation "such as Teams, OneDrive and Outlook". Core tax systems stay in the authority's own datacentre in Apeldoorn. The stated reasons: no suitable European alternative, and no datacentre space or power for a hybrid on-premises setup in the foreseeable future (Kamerstuk 31 066 nr. 1512, 2 October 2025).
June 2026, the review. The Adviescollege ICT-toetsing (AcICT), the government's independent ICT review board, found the rollout had reached about 5,000 of roughly 47,500 staff. Its first recommendation was to roll back M365 in the public cloud. It cited vendor lock-in, growing concentration risk, a backup that "falls seriously short", and concluded that "a workable exit strategy is missing" (AcICT advice, 24 June 2026, my translation).
October 2026, the decision. Mail and calendar move on-premises first in 2027, with European open-source tools for personal storage and collaboration following in 2027 and 2028. The letter credits expanded datacentre capacity and the AcICT advice "not to rely on one solution from one vendor" (Tweede Kamer letter, 5 October 2026; corroborated by AG Connect and Tweakers).
The Netherlands did not ban Microsoft. The authority plans to reuse existing licences where possible, and the letter openly admits some archiving features in the M365 package have no on-premises equivalent.
The privacy backdrop is older. Dutch government DPIAs by Privacy Company found eight high risks in Office ProPlus in 2018, mostly around diagnostic data flowing to the US (2019 summary). By the 2022 Teams, OneDrive and SharePoint DPIA, the remaining high risk was sensitive data not encrypted with the customer's own key, because of possible US government access (Privacy Company, February 2022). Both findings map directly to tests 2 and 3 below.
It is part of a pattern across Europe:
Schleswig-Holstein started moving about 30,000 state employees to LibreOffice, Linux, Nextcloud and Open-Xchange in 2024 (state government, April 2024), and reported nearly 44,000 mailboxes migrated by December 2025 (press release).
Denmark's Ministry of Digital Affairs launched a broad pilot of Collabora, built on LibreOffice, in June 2025 (digmin.dk).
France requires SecNumCloud-qualified, extraterritorial-law-immune hosting for sensitive state data under its cloud doctrine (numerique.gouv.fr).
Germany funds openDesk through the federally owned ZenDiS.
Why should a private company care? Because the same questions now land in your procurement questionnaires. NIS2 Article 21(2)(d) makes supply-chain security a legal obligation for in-scope entities (Directive (EU) 2022/2555), and DORA Article 28(8) requires financial entities to keep exit plans that are "comprehensive, documented and ... sufficiently tested" since 17 January 2025 (Regulation (EU) 2022/2554).
The real lesson is cost. The Belastingdienst reversed course with 5,000 people already migrated. Test before you commit. The seven tests below each come with a pass criterion and an artifact.
What does 'sovereign cloud' actually mean, and which options exist in Europe in 2026?
"Sovereign cloud" covers at least five distinct tiers, from an EU region of a US hyperscaler (data location only) to self-hosted Kubernetes (full control, full operational burden). The useful question is which tier a specific workload needs, and what that tier costs you in managed-service depth and operational load.
Tier 1, EU region of AWS, Google Cloud or Azure. Data sits in the EU, the parent stays under US jurisdiction. Deepest catalogue, lowest sovereignty assurance.
Tier 2, hyperscaler sovereign offerings. The AWS European Sovereign Cloud went GA on 15 January 2026 in Brandenburg, Germany, with more than 90 services, a new parent company and German subsidiaries "led by EU citizens", and a planned investment of more than €7.8 billion (Amazon, January 2026). Microsoft announced its Sovereign Public Cloud and Sovereign Private Cloud in June 2025, including Data Guardian, which routes remote access through EU-resident staff, and external key management (Microsoft, June 2025). Google offers Data Boundary, Dedicated and Distributed Cloud tiers (Google Cloud).
Tier 3, EU-operated joint ventures on a US stack. S3NS, a Thales subsidiary running Google Cloud technology, obtained SecNumCloud qualification for PREMI3NS in December 2025 (S3NS). Bleu, founded by Capgemini and Orange on Microsoft technology, lists SecNumCloud qualification as in progress on its own site (Bleu). Delos Cloud is an SAP subsidiary running on Azure technology for the German public sector (SAP, September 2025). Strong for public sector, narrower catalogues. Check which services are actually GA.
Tier 4, EU-owned providers. OVHcloud, Scaleway, IONOS, Hetzner, STACKIT (Schwarz Group), Exoscale (A1 Digital) and Aruba. Managed Kubernetes and Postgres are standard, higher-level managed services are thinner.
Tier 5, self-hosted or on-premises Kubernetes plus open source. Maximum control, maximum day-2 burden. This is the tier the Belastingdienst picked for office work.
The legal layer underneath matters more than the marketing:
CLOUD Act. The EDPB and EDPS wrote that "unless a US CLOUD Act warrant is recognised or made enforceable on the basis of an international agreement, the lawfulness of such transfers of personal data cannot be ascertained" (EDPB-EDPS, 10 July 2019).
Schrems II and the Data Privacy Framework. The CJEU struck down Privacy Shield in 2020 (C-311/18). The General Court upheld its successor, the EU-US Data Privacy Framework, in September 2025 (T-553/23), and an appeal (C-703/25 P) was lodged on 31 October 2025 (OJ notice). As of November 2026 that appeal is pending, so the framework stands but is contested.
EUCS. The EU cloud certification scheme dropped its sovereignty requirement in its March 2024 draft and still has not been adopted (EUISS, November 2025). The Commission said in January 2026 that work is expected to resume (Commission Q&A). There is no EU-wide label you can rely on yet.
Market reality: Amazon, Microsoft and Google held 70% of the European cloud market in 2024, with European providers steady at around 15% (Synergy Research Group, July 2025).
Tier
Example providers
Who controls the operating entity
Data and metadata residency
Managed-service depth
Typical exit difficulty
Best-fit workload
What it does NOT protect against
1. EU region of a US hyperscaler
AWS, Azure, Google Cloud EU regions
US parent company
Primary data in EU; telemetry and support flows vary by service
Deepest
High if you use proprietary services
Most commercial SaaS and internal apps
US legal compulsion of the parent
2. Hyperscaler sovereign offering
AWS European Sovereign Cloud, Microsoft Sovereign Cloud, Google Cloud Dedicated
EU-incorporated entity owned by a US group
EU, operated by EU-resident staff
Deep, subset of the full catalogue
High, same proprietary APIs
Regulated workloads that need hyperscaler services
Dependence on the US parent's roadmap and technology
On-prem or colocation with OpenShift, Rancher or upstream
You
Wherever you put it
Whatever you run yourself
Lowest legally, highest operationally
Most sensitive data classes
Your own team's capacity to operate it
Which seven tests should you run before trusting a sovereign cloud migration?
Seven tests separate a sovereign cloud claim from a sovereign cloud fact: legal control, data and metadata residency, key custody, a timed exit drill, latency and interconnect, managed-service parity, and day-2 operability. Each one must end with an artifact an auditor can read, such as a contract clause, a data-flow map, a revocation log or a timed restore report, rather than a vendor statement.
Test 1: legal control of the operating entity
What to measure: who owns the entity operating your workload, which law governs the staff with production access, and whether a non-EU parent can be compelled to produce data under the CLOUD Act or FISA Section 702.
Pass criterion: a named EU entity with no non-EU compellable access path, written into the contract.
Evidence artifact: the signed contract clause plus a list of who holds production credentials and where they are employed.
Who runs it: legal counsel with the CISO. Two to four weeks.
Test 2: data and metadata residency
What to measure: every flow that is not the primary database: telemetry, diagnostic data, logs, support tickets, backups, identity and directory data, and AI or copilot features. The Dutch DPIAs flagged diagnostic data as the first high risk.
Pass criterion: a documented data-flow map with zero unexplained egress.
Evidence artifact: the map plus a network capture or a provider data-flow attestation.
Who runs it: security engineering with the DPO. Two to three weeks.
Test 3: encryption key custody
What to measure: whether you use provider-managed keys, BYOK, HYOK or an external key manager you operate, and whether the provider can decrypt without you.
Pass criterion: a revocation drill that demonstrably makes the data unreadable to the provider.
Evidence artifact: the revocation log with timestamps, and the failed read attempts after revocation.
Who runs it: security engineering. One week, on a non-production copy first.
Test 4: timed reversibility drill
What to measure: wall-clock time to restore one production-like application and its data into a second target from backups and infrastructure as code.
Pass criterion: your documented RTO and RPO are met.
Evidence artifact: the timed restore report with the egress invoice attached.
Who runs it: the on-call team that would do it in a real incident. One to two days of execution, plus preparation.
Test 5: latency and interconnect
What to measure: p50 and p95 latency from real user locations, peering and private interconnect options, and cross-provider bandwidth pricing.
Pass criterion: p95 stays inside the budget your current SLOs already assume.
Evidence artifact: the raw measurement dataset, kept for re-testing.
Who runs it: SRE or network engineering. One week.
Test 6: managed-service parity
What to measure: every managed dependency (Postgres, object storage, queues, GPUs, IAM, observability, serverless, CDN) mapped to the target's equivalent, version lag and SLA.
Pass criterion: a mapped equivalent, or an explicitly accepted gap with an owner, for every line.
Evidence artifact: the dependency matrix with a named owner per gap.
Who runs it: the platform or architecture team. One to two weeks.
Test 7: day-2 operability
What to measure: whether your team can run the target (cluster upgrades, CVE patching, on-call, RBAC, environment provisioning, cost control) without hiring a new platform team.
Pass criterion: the four DORA key metrics within 10% of the pre-migration baseline 90 days after the move.
Evidence artifact: a before and after metrics dashboard.
Who runs it: engineering leadership. Baseline before the move, review at day 90.
In my conversations with more than 200 CTOs, the tests teams skip are almost always 2, 3 and 7. Metadata residency is tedious, key revocation is scary to run, and day-2 operability only hurts after the project is declared done.
Named EU entity, no non-EU compellable path, in contract
Signed clause and credential holder list
Legal and CISO
2-4 weeks
At each contract renewal
2. Data and metadata residency
Telemetry, logs, support, backups, identity, AI features
Zero unexplained egress
Data-flow map and network capture
Security and DPO
2-3 weeks
Yearly and after new features
3. Key custody
Who can decrypt, revocation behaviour
Revocation makes data unreadable to provider
Timestamped revocation log
Security engineering
1 week
Yearly
4. Reversibility drill
Restore time and data loss in a second target
RTO and RPO met
Timed restore report and egress invoice
On-call team
1-2 days plus prep
Yearly and after major changes
5. Latency and interconnect
p50 and p95 from user locations, bandwidth cost
p95 inside existing SLO budget
Measurement dataset
SRE or network
1 week
After topology changes
6. Managed-service parity
Each dependency's equivalent, version lag, SLA
Equivalent or owned gap per line
Dependency matrix
Platform or architecture
1-2 weeks
Twice a year
7. Day-2 operability
DORA four key metrics
Within 10% of baseline at day 90
Before and after dashboard
Engineering leadership
90 days
Quarterly
Is hosting in an EU region of AWS, Azure or Google Cloud enough to be sovereign?
No. An EU region answers where the data physically sits, not who can legally be compelled to produce it or who can technically reach it for support. The EDPB and EDPS told the European Parliament in July 2019 that CLOUD Act transfers cannot be shown to be lawful without an international agreement, which is why region selection alone never closed the Dutch DPIA findings.
People conflate three separate questions:
Data location: which datacentre holds the bytes.
Legal jurisdiction: which courts can compel the operator.
Technical access paths: support staff, telemetry pipelines, managed-service control planes.
An EU region solves the first, helps GDPR transfer mechanics for the primary store, gives you latency, and satisfies many procurement checklists. It does not solve parent-company compellability, diagnostic flows, support access from outside the EU, or concentration risk under NIS2 and DORA.
Tier 2 offerings change the picture in real ways: a separate EU legal entity, EU-resident operators, external key management. They still inherit the parent's engineering roadmap and proprietary APIs, so your exit difficulty is unchanged.
My practical guidance: for most private companies, an EU region plus customer-held keys plus a tested exit is a defensible position. For regulated or public-sector data classes, it is not enough.
The EU Data Act is why exit is now a legal expectation. Since 12 September 2025, providers must complete a switch within a 30-day transitional period after a notice period of at most two months (Article 25), and from 12 January 2027 they may not charge any switching fees (Article 29) (Regulation (EU) 2023/2854).
Does it solve it?
EU region of a US hyperscaler
Hyperscaler sovereign offering
EU-operated joint venture
EU-owned provider
Self-hosted Kubernetes
Data location
Yes
Yes
Yes
Yes
Yes
Legal jurisdiction over the operator
No, US parent
Partly, EU entity with a US parent
Mostly, EU operator
Yes
Yes
Support access
Varies by service
Yes, EU-resident staff
Yes
Yes
Yes, your own staff
Telemetry and metadata
Must be verified per service
Mostly, verify
Mostly, verify
Mostly, verify
Yes, if you configure it
Encryption key control
Possible with external keys
Yes, external key options
Yes
Varies by provider
Yes
Concentration risk
No
No
Partly
Partly
Yes, but on your own team
Ship faster on infrastructure you control.
Qovery gives your team self-service deployments on your own AWS, GCP, Azure, or Scaleway account - or your existing Kubernetes cluster. Start deploying in under 10 minutes.
How do you run a cloud exit test so it actually proves something?
A credible exit test is a timed, end-to-end restore of a production-like environment into a second target, executed by the same on-call team that would do it during a real incident. A migration plan on a slide proves nothing and will not satisfy a DORA Article 28 or NIS2 reviewer asking for evidence that the exit plan was "sufficiently tested".
Scope it right. One real revenue-path application with its data, dependencies and secrets. Never a hello-world, never a staging app with synthetic data.
Run the steps in order. Rebuild infrastructure from IaC, restore data from backup, re-point DNS, run the full test suite, serve real traffic for at least an hour, then measure RTO and RPO against your targets.
Record four things. Wall-clock hours, people involved, the egress invoice in euros, and every manual step that was missing from the runbook. That last list is the real output of the exercise.
Expect these blockers. Proprietary managed services with no equivalent, provider IAM referenced in application code, serverless runtimes, vendor observability agents, and data gravity.
Egress is cheaper than people fear, and engineering hours cost more. As of November 2026, list prices for internet egress are:
AWS (Frankfurt): 100 GB a month free, then $0.09 per GB for the first 10 TB, so roughly $90 per TB (AWS).
Check that your contract reflects Data Act Chapter VI: the two-month notice cap, the 30-day transition (extendable up to seven months only if the provider proves 30 days is technically unfeasible, Article 25(4)), and the end of switching charges on 12 January 2027. If it does not, renegotiate at renewal.
Cadence: at least once a year, plus after any major architecture change. Publish the result internally as one shared number ("we can leave in 31 hours"), not a compliance PDF nobody reads.
What makes a workload portable enough to move, and what locks you in?
Portability is decided at design time, not at migration time. OCI containers on standard Kubernetes with Postgres or S3-compatible storage and declarative infrastructure move in days, while provider-specific serverless, proprietary databases and native IAM baked into application code move in quarters.
Portable layer: OCI containers, Kubernetes APIs, Postgres, MySQL, Redis and Kafka-compatible engines, S3-compatible object storage, OpenTelemetry, Terraform or OpenTofu, open backup formats.
Sticky layer: managed serverless runtimes, proprietary databases, provider-native event buses, provider IAM in application code, vendor ML platforms, provider-specific CDN and edge logic.
Four rules worth adopting now:
Keep provider SDK calls behind an interface in your code.
Keep identity and secrets provider-neutral.
Keep all infrastructure as code in one repository.
Keep backups in an open format, stored outside the provider.
Component type
Concrete example
Portability
Typical migration effort
How to de-risk it now
Stateless services
Containerised API on Kubernetes
High
Days
Use standard manifests or Helm, avoid provider annotations in app config
Relational database
Managed Postgres
High
Days, bounded by data size
Stay on community Postgres features, test logical dump and restore
Proprietary database
DynamoDB, Cosmos DB, Spanner
Low
Months
Wrap access behind a repository layer, plan a Postgres or Cassandra-compatible target
Object storage
S3 or S3-compatible buckets
High
Days to weeks
Use the S3 API only, no provider-specific event hooks
Serverless functions
Lambda, Azure Functions, Cloud Functions
Low
Weeks to months
Package as containers, or isolate triggers from business logic
Event bus
EventBridge, Pub/Sub, Service Bus
Medium
Weeks
Prefer Kafka or NATS-compatible interfaces
Identity in code
Provider IAM roles called from the application
Low
Weeks
Move to OIDC and workload identity abstractions
Observability
Vendor agent plus proprietary dashboards
Medium
Weeks
Instrument with OpenTelemetry, keep dashboards as code
Infrastructure definitions
Terraform or OpenTofu modules
Medium
Weeks, provider resources differ
Separate provider modules from shared logic
This is where I'll bring in what we build. Qovery is not a cloud provider. It deploys into your own AWS, GCP, Azure or Scaleway account, or into an existing Kubernetes cluster (self-managed, on-prem, any distribution), and the infrastructure it manages is standard Kubernetes plus Terraform. The application layer stays the same across those targets, and the cloud bill, committed-use discounts and data stay in your name. In tier terms, that covers tiers 1, 4 and 5.
Why do sovereign and on-premises migrations fail on developer experience rather than compliance?
Sovereign migrations rarely fail the legal review. They fail around six months later, when getting a database becomes a ticket, per-PR preview environments disappear, cluster upgrades get postponed, and deployment frequency drops far enough that somebody proposes going back.
The pattern I keep hearing from CTOs: the compliance box gets ticked, then the two engineers who understand the new stack become the bottleneck for everyone else. The symptoms are predictable:
A ticket and a two-day wait to get a database.
No per-PR environments, so reviews happen on a shared staging that is always broken.
Cluster upgrades postponed until a version goes out of support.
On-call concentrated on two people.
Cost visibility lost, with non-production environments running 24/7.
You cannot hire your way out cheaply. In Eurostat's latest data, 57.5% of EU enterprises that tried to recruit ICT specialists in 2023 had difficulty filling the roles (Eurostat). And Kubernetes is now the default target: 82% of container users ran it in production in 2025 (CNCF, January 2026), so everyone competes for the same people.
"We will just run Kubernetes, Helm and ArgoCD ourselves" underestimates day 2: version upgrades every few months, CVE patching, RBAC across environments, secrets rotation, multi-tenancy and cost control. Each is manageable. All of them together, on top of a migration, is where velocity dies.
Measure it. Track deployment frequency, lead time for changes, change failure rate and failed-deployment recovery time before and after. For reference, the 2024 DORA report puts elite teams at on-demand deploys, lead time under a day, a 5% change failure rate and recovery in under an hour (DORA 2024).
Metric
Regression I typically see after a sovereign move
How to prevent it
Deployment frequency
Drops from daily to weekly as deploys go through the few engineers who know the new stack
Git-push deploys with self-service, no ticket in the path
Lead time for changes
Grows as review environments disappear
Per-PR preview environments on the new target
Environment provisioning time
Goes from minutes to days when databases become tickets
Self-service databases backed by the target's managed services
Change failure rate
Rises when staging no longer matches production
Identical environment definitions across stages
Failed-deployment recovery time
Lengthens when only two people can debug the cluster
Shared runbooks, standard tooling, one-click rollback
On-call headcount
Collapses to two or three people
Managed cluster upgrades and per-environment RBAC so more engineers can operate safely
This is the failure mode Qovery exists for. It is an Internal Developer Platform that installs into your own AWS, GCP, Azure or Scaleway account, or an existing Kubernetes cluster, and gives your team git-push deploys, per-PR preview environments, auto-stop for non-production environments, managed cluster upgrades, per-environment RBAC, and databases backed by managed cloud services. Sovereignty should not cost you velocity.
To be explicit: Qovery does not replace Microsoft 365, Nextcloud, LibreOffice or openDesk. The Belastingdienst decision was about office productivity. This section is about the applications your engineers build and run.
Fair comparison with what teams also evaluate here:
Red Hat OpenShift: a complete enterprise Kubernetes distribution with vendor support, strong for on-prem tier 5. You still staff the platform team.
SUSE Rancher: good multi-cluster management across clouds and on-prem. Developer self-service is something you assemble on top.
Backstage-based in-house platform: an excellent portal framework. The orchestration behind it is yours to build and maintain.
Platform.sh: a managed PaaS that operates the infrastructure for you, a different trade-off from running in your own account.
Northflank and Porter: developer platforms that can also deploy into your own cloud account. Compare cloud coverage, on-prem Kubernetes support and governance features against your tier map.
What should a realistic sovereign migration plan look like over 12 months?
Sequence it instead of big-banging it: classify workloads by sovereignty requirement in month one, run all seven tests on one representative application before month three, move low-risk workloads first, keep a second target warm, and re-run the exit drill before anything critical moves.
Month 0-1: data classification and legal control review. Decide which workloads need which tier, and write down which ones do not. That list saves the most money.
Month 1-3: pick one representative application, run all seven tests, publish the results and artifacts internally.
Month 3-6: migrate internal and low-risk workloads. Standardise on Kubernetes, IaC and a self-service platform before volume grows, not after.
Month 6-9: migrate customer-facing workloads tier by tier, with the four DORA metrics on a dashboard everyone can see.
Month 9-12: re-run the exit drill against the new home, and renegotiate contracts against Data Act switching terms at renewal.
The anti-pattern is all-or-nothing. The Belastingdienst had to unwind a rollout already in use by thousands of staff. Hybrid is a legitimate end state: sensitive data classes on EU-owned or on-prem infrastructure, everything else wherever it runs best, with the exit tested in both directions.
How do I run the portability and operability tests with Qovery from Claude Code or Cursor?
You can run tests 4, 6 and 7 from your coding agent: install the Qovery Agent Skills once, then ask the agent in plain language to deploy the same application into a second provider or your own Kubernetes cluster and report what differs. Every action is proposed for your approval before it runs, and the MCP Server is read-only by default.
BASH|Global install for Claude Code, Cursor, Codex, OpenCode, Gemini CLI
curl -fsSL https://skill.qovery.com/install.sh | bash
# Or scoped to one repository
curl -fsSL https://skill.qovery.com/install.sh | bash -s -- --project
# Qovery MCP Server in Claude Code (OAuth, read-only by default)
claude mcp add --transport http qovery https://mcp.qovery.com/mcp --callback-port 4242
# Write access, only when you want the agent to act (also enable it in the Qovery Console)
claude mcp add --transport http qovery "https://mcp.qovery.com/mcp?read_write=true" --callback-port 4242
The skills give the agent qovery-onboard, qovery-deploy, qovery-troubleshoot, qovery-optimize, qovery-speedup, qovery-preview and qovery-terraform. With the MCP Server connected, it can inspect clusters, environments and deployments.
Then ask something like: "Deploy this application to my Scaleway account, then redeploy it to my existing Kubernetes cluster and report what differs." Time the run and keep the output as your exit-drill artifact for test 4. The gaps it reports feed your parity matrix for test 6.
Why did the Dutch tax authority scrap its Microsoft 365 cloud rollout?
The Belastingdienst paused the rollout in July 2026 after the government's ICT review board (AcICT) advised rolling it back, citing vendor lock-in, concentration risk, weak backups and no workable exit strategy. In October 2026 it chose on-premises plus European open source instead, helped by newly expanded datacentre capacity. Mail and calendar move first in 2027, collaboration tools follow in 2027 and 2028.
What should European companies test before trusting a sovereign cloud migration?
Seven things: legal control of the operator, data and metadata residency, encryption key custody, a timed exit drill, latency, managed-service parity and day-2 operability. Each test needs a pass criterion and a written artifact, such as a signed clause, a data-flow map, a revocation log or a timed restore report. Vendor statements do not count as evidence.
Is hosting in an EU region of AWS, Azure or Google Cloud enough to be sovereign?
It settles where data is stored, not who can compel access or who can reach it for support. For most private companies, an EU region combined with customer-held keys and a tested exit is defensible. For regulated or public-sector data classes, look at sovereign offerings, EU-owned providers or self-hosting.
What is the difference between a sovereign cloud, an EU-owned cloud and a self-hosted cloud?
A hyperscaler sovereign cloud runs through an EU-incorporated entity of a US group with EU-resident operators. An EU-owned cloud such as OVHcloud, Scaleway, IONOS or Hetzner is European at every level of ownership. A self-hosted cloud runs on infrastructure you operate, which gives full control and full operational responsibility.
How do you run a cloud exit test, and how long should it take?
Restore one real revenue-path application and its data into a second target from backups and IaC, re-point DNS, run tests and serve real traffic for an hour. Execution usually takes one to two days for a well-prepared team. If it takes weeks, the list of undocumented manual steps you collect is your most valuable finding.
Does the EU Data Act make it cheaper to leave a cloud provider?
Yes. Since 12 September 2025 providers can only charge reduced, cost-based switching fees, and from 12 January 2027 they cannot charge any switching fees at all. AWS, Google Cloud and Azure already waive egress for customers leaving, so the bigger exit cost is now engineering time.
Can you get cloud sovereignty without losing developer self-service and deployment speed?
Yes, if you plan for it before the move. Baseline your DORA metrics, keep workloads on standard Kubernetes and Postgres, and give developers self-service deploys, preview environments and databases on the new target. An Internal Developer Platform that installs in your own cloud account or cluster, such as Qovery, covers that layer without a dedicated platform team.
Romaric founded Qovery to make Kubernetes accessible to every engineering team. He writes about platform strategy, developer experience, and the future of cloud infrastructure.
Next step
Ship faster on infrastructure you control.
Qovery gives your team self-service deployments on your own AWS, GCP, Azure, or Scaleway account - or your existing Kubernetes cluster. Start deploying in under 10 minutes.
