Decision guide · Infrastructure
How to make a sovereign cloud migration decision
Sovereign cloud decisions are rarely about cloud; they are about sovereignty. The right decision starts by defining what sovereignty actually means for this workload (data, operations, keys, personnel, jurisdiction), separates that from generic cloud migration criteria, and captures board-level accountability alongside technical scoring. Cost is a scored criterion, not a driver.
TL;DR
Start with what sovereignty means for this workload, not with vendor shortlists.
Who owns this decision
CIO or Head of Infrastructure as decision owner, CISO, Legal, Data Protection Officer, and the business owner of the target workload.
Key criteria to weight
Sovereignty depth required
Data only, operations, keys, personnel, legal jurisdiction. Each level excludes more candidates.
Workload and data classification
Public, internal, confidential, strict. Drives acceptable hosting options.
Performance and latency profile
Some sovereign candidates lag on managed-service breadth. Quantify the gap.
Managed-service breadth
Databases, AI services, serverless. Sovereign offerings vary widely.
Exit path and portability
Terraform, open APIs, data export. Always a dealbreaker under DORA.
TCO including migration
Migration and parallel-run costs often dominate year-1 economics.
Step-by-step decision flow
- 1
Define sovereignty
Draft a one-page sovereignty statement specific to this workload. Review with Legal and the Data Protection Officer before shortlisting.
- 2
Classify the workload
Data class, regulatory scope, personal data exposure, intellectual property sensitivity.
- 3
Eliminate by dealbreaker
Drop every candidate that fails the sovereignty statement. Do not rescue them with weights.
- 4
Score remaining candidates
On performance, managed-service breadth, TCO, exit path. Weight by the business owner's priorities.
- 5
Model migration
Parallel-run cost, cutover plan, training, vendor exit fees. Time-box the analysis.
- 6
Board memo
Sovereignty rationale, criteria, trade-offs, residual risks, decision. NIS2 and DORA-relevant excerpts for submission.
Compliance note
Sovereign cloud decisions sit at the intersection of GDPR Chapter V (international transfers), NIS2 operational resilience and DORA Art. 28–30 third-party risk. The decision memo doubles as the core evidence for all three.
Common pitfalls
- !Starting with vendor selection before defining sovereignty.
- !Assuming EU hosting equals sovereignty.
- !Under-estimating managed-service gaps on sovereign platforms.
- !Forgetting to model exit from both the incumbent and the chosen sovereign vendor.
FAQ
Is sovereign cloud the same as EU-hosted cloud?
No. EU-hosted cloud means data residency is in the EU; the operator is often still a US-headquartered company. Sovereign cloud goes further: operational control, personnel, encryption keys and legal jurisdiction are fully inside the target sovereignty (typically EU or member-state level). The buying question is which level of sovereignty is actually required by regulator, customer or board.
Which sovereign cloud providers are relevant in Germany and the EU?
Public-cloud sovereign offerings (Microsoft Cloud for Sovereignty, Google Sovereign Cloud, AWS European Sovereign Cloud) plus EU-native providers (OVHcloud, IONOS, Open Telekom Cloud, Gaia-X aligned) form the typical shortlist. DecisionOS surfaces relevant candidates based on workload type, data class and compliance scope.
How does NIS2 affect a sovereign cloud decision?
NIS2 raises accountability for essential and important entities around incident reporting, supply-chain risk and executive responsibility. Sovereign cloud decisions are often the route through which a NIS2 programme delivers tangible control, which is why these decisions attract board-level scrutiny.