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.
Vendor market structure
Strukturvergleich der Sovereign-Cloud-Kandidaten für DACH-Behörden und regulierte Workloads.
| Vendor | Sovereignty-Tiefe | Schlüsselkontrolle | EU-Personal-Garantie | Managed-Services-Breite | GAIA-X-Zertifizierung | Hyperscaler-API-Kompatibilität |
|---|---|---|---|---|---|---|
| Microsoft Cloud for Sovereignty ↗ | EU Data Boundary plus Sovereign Landing Zones | BYOK, HYOK über Confidential Computing | Bedingte Garantie, Cloud for Sovereignty Tenants | Sehr breit, Azure-Voll-Stack | Teilkonformität, Roadmap für Sovereign Tenants | Vollständig Azure-API-kompatibel |
| Google Sovereign Cloud (T-Systems) ↗ | Sovereign Cloud Operated by T-Systems in DE | External Key Manager, BYOK | DE-Personal durch T-Systems Operations | Breit, einige Services nicht in Sovereign Tenant | Sovereign Cloud GAIA-X-orientiert | GCP-API-kompatibel |
| AWS European Sovereign Cloud ↗ | Eigenständige EU-Region geplant ab 2026 | BYOK, HYOK über externe HSMs | EU-Personal mit EU-Staatsbürgerschaft angekündigt | AWS-Service-Set, schrittweise verfügbar | GAIA-X-Anbindung evaluiert | Vollständig AWS-API-kompatibel |
| OVHcloud ↗ | FR/EU Hauptsitz, SecNumCloud-Zertifizierungen | KMS verfügbar, BYOK | EU-Personal durch FR-Konzern | Moderat, Open-Source-Stack | Aktiver GAIA-X-Provider | Eigene API plus OpenStack |
| IONOS Cloud ↗ | DE-Hauptsitz, BSI-C5 | KMS und BYOK | DE-Personal | Moderat, IaaS-Fokus | Aktiver GAIA-X-Provider | Eigene API plus S3-Kompatibilität |
| Open Telekom Cloud (T-Systems) ↗ | DE-Hauptsitz, BSI-C5, EU-Operations | KMS, BYOK | DE-Personal | Moderat, Huawei-Stack-basiert | Aktiver GAIA-X-Provider | OpenStack-/Huawei-API |
| StackIT (Schwarz IT) ↗ | DE-Hauptsitz, BSI-C5, EU-Operations | KMS, HYOK in Roadmap | DE-Personal (Schwarz Gruppe) | Wachsendes Service-Set | Aktiver GAIA-X-Provider | Eigene API plus S3-Kompatibilität |
| plusserver ↗ | DE-Hauptsitz, BSI-C5 | BYOK, HYOK in Sovereign-Tier | DE-Personal | Moderat, OpenStack/VMware | Aktiver GAIA-X-Provider | OpenStack-API |
| Delos Cloud (SAP) ↗ | DE-Hauptsitz, für Bundes- und Behördenkunden | HYOK über externe HSMs geplant | DE-Personal, Microsoft Azure unter Delos-Hoheit | Azure-Service-Set unter Sovereign-Operations | GAIA-X-Anbindung in Roadmap | Azure-API-kompatibel |
Stand: 2026-04. Basierend auf öffentlich zugänglichen Vendor-Angaben. Stand April 2026. Eigene Validierung über DecisionOS-Profil empfohlen.
Example memo, fictional case
Landesbehörde, 800 Mitarbeiter, datenschutzrechtlich besonders sensible Workloads
Readiness score
72
- Trigger
- Migration von On-Prem-VMware-Cluster nach Modernisierungs-Roadmap. EVB-IT-Cloud-Vergabe verlangt strukturierte Eignungsprüfung, BSI-C5 ist Mindestanforderung.
- Top criteria (weights)
- Sovereignty-Tiefe (Operations, Personal, Schlüssel)30%
- BSI-C5-Zertifizierung Typ 220%
- Managed-Services-Breite15%
- Hyperscaler-API-Kompatibilität (Exit)10%
- GAIA-X-Konformität10%
- TCO über 5 Jahre15%
- Shortlist
- Etablierter deutscher Anbieter mit breitem Managed-Service-Portfolio
- Deutscher Sovereign-Anbieter mit hoher Betriebstiefe
- Sovereign-Plattform im Aufbau
- Decision
- Der etablierte Anbieter für Workloads mit Standardprofil, dazu der Sovereign-Anbieter mit der höheren Betriebstiefe für die höchstvertraulichen Daten.
- Rationale
- Die Plattform im Aufbau schied aus, weil zum Vergabezeitpunkt kein Produktivbetrieb mit vergleichbarem Profil vorgelegt werden konnte, und eine Vergabe nach EVB-IT-Cloud braucht diesen Nachweis. Zwischen den beiden verbleibenden Optionen entschied nicht die Gesamtwertung, sondern die Aufteilung: das höchstgewichtete Kriterium Sovereignty-Tiefe zählt nur für einen kleinen Teil der Workloads, für den Rest zählt die Service-Breite. Ein 80/20-Split erfüllt beides und mindert das Konzentrationsrisiko, das die Eignungsprüfung ausdrücklich abfragt.
- Residual risks
- Multi-Cloud-Operations-Modell erhöht initialen Personalaufwand
- Service-Roadmap der Sovereign-Provider wird in 12-Monats-Reviews neu bewertet
Compliance note
Sovereign cloud decisions sit at the intersection of GDPR Chapter V (international transfers), NIS2 operational resilience and DORA Art. 28 bis 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.
Related decision guides
- InfrastructureHow to decide on IT outsourcing, a structured framework
- ComplianceHow to reach NIS2 readiness as a mid-market or enterprise operator
- ComplianceHow to reach DORA readiness as a financial entity
- SecurityHow to choose an EDR or XDR platform in 2026
- SecurityHow to choose an IAM, IGA and PAM stack
Related comparisons
- DecisionOS vs LeanIXLeanIX tracks your portfolio. DecisionOS decides what changes.
- DecisionOS vs strategy consultingConsultants structure your decision once. DecisionOS structures every decision.
- DecisionOS vs Excel and slide decksSpreadsheets work until the second stakeholder shows up.
- DecisionOS vs RFP toolsRFP tools automate Q&A. DecisionOS runs the decision.
- DecisionOS vs procurement suitesProcurement suites execute the purchase. DecisionOS makes the decision.
Relevant industries
- Banken & FinanzdienstleisterBanken entscheiden unter DORA, MaRisk, BAIT gleichzeitig. DecisionOS liefert das Memo, das alle drei Prüfer akzeptieren.
- Manufacturing & IndustrialManufacturing is a NIS2 important entity. OT security and supply-chain diligence are mandatory. The decision memo is the audit standard.
- Pharma & Life SciencesPharma IT is regulated IT. Validation (CSV/CSA) and audit trail are not optional. The decision memo is the mandatory front-end documentation.
- Automotive & SuppliersAutomotive = TISAX + UNECE R155/R156 + ISO 21434 + NIS2. The decision memo is the only format that maps all four in parallel.
- Chemicals & Process IndustryChemicals is a NIS2 important entity with physical major-accident risk. IT-OT convergence is the core strategic question.