nexalign

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. 1

    Define sovereignty

    Draft a one-page sovereignty statement specific to this workload. Review with Legal and the Data Protection Officer before shortlisting.

  2. 2

    Classify the workload

    Data class, regulatory scope, personal data exposure, intellectual property sensitivity.

  3. 3

    Eliminate by dealbreaker

    Drop every candidate that fails the sovereignty statement. Do not rescue them with weights.

  4. 4

    Score remaining candidates

    On performance, managed-service breadth, TCO, exit path. Weight by the business owner's priorities.

  5. 5

    Model migration

    Parallel-run cost, cutover plan, training, vendor exit fees. Time-box the analysis.

  6. 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.

VendorSovereignty-TiefeSchlüsselkontrolleEU-Personal-GarantieManaged-Services-BreiteGAIA-X-ZertifizierungHyperscaler-API-Kompatibilität
Microsoft Cloud for Sovereignty ↗EU Data Boundary plus Sovereign Landing ZonesBYOK, HYOK über Confidential ComputingBedingte Garantie, Cloud for Sovereignty TenantsSehr breit, Azure-Voll-StackTeilkonformität, Roadmap für Sovereign TenantsVollständig Azure-API-kompatibel
Google Sovereign Cloud (T-Systems) ↗Sovereign Cloud Operated by T-Systems in DEExternal Key Manager, BYOKDE-Personal durch T-Systems OperationsBreit, einige Services nicht in Sovereign TenantSovereign Cloud GAIA-X-orientiertGCP-API-kompatibel
AWS European Sovereign Cloud ↗Eigenständige EU-Region geplant ab 2026BYOK, HYOK über externe HSMsEU-Personal mit EU-Staatsbürgerschaft angekündigtAWS-Service-Set, schrittweise verfügbarGAIA-X-Anbindung evaluiertVollständig AWS-API-kompatibel
OVHcloud ↗FR/EU Hauptsitz, SecNumCloud-ZertifizierungenKMS verfügbar, BYOKEU-Personal durch FR-KonzernModerat, Open-Source-StackAktiver GAIA-X-ProviderEigene API plus OpenStack
IONOS Cloud ↗DE-Hauptsitz, BSI-C5KMS und BYOKDE-PersonalModerat, IaaS-FokusAktiver GAIA-X-ProviderEigene API plus S3-Kompatibilität
Open Telekom Cloud (T-Systems) ↗DE-Hauptsitz, BSI-C5, EU-OperationsKMS, BYOKDE-PersonalModerat, Huawei-Stack-basiertAktiver GAIA-X-ProviderOpenStack-/Huawei-API
StackIT (Schwarz IT) ↗DE-Hauptsitz, BSI-C5, EU-OperationsKMS, HYOK in RoadmapDE-Personal (Schwarz Gruppe)Wachsendes Service-SetAktiver GAIA-X-ProviderEigene API plus S3-Kompatibilität
plusserver ↗DE-Hauptsitz, BSI-C5BYOK, HYOK in Sovereign-TierDE-PersonalModerat, OpenStack/VMwareAktiver GAIA-X-ProviderOpenStack-API
Delos Cloud (SAP) ↗DE-Hauptsitz, für Bundes- und BehördenkundenHYOK über externe HSMs geplantDE-Personal, Microsoft Azure unter Delos-HoheitAzure-Service-Set unter Sovereign-OperationsGAIA-X-Anbindung in RoadmapAzure-API-kompatibel

Stand: 2026-04. Basierend auf öffentlich zugänglichen Vendor-Angaben. Stand April 2026. Eigene Validierung über DecisionOS-Profil empfohlen.

Anonymised memo excerpt

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
  • StackIT (Schwarz IT)
  • Open Telekom Cloud (T-Systems)
  • Delos Cloud (SAP)
Decision
Open Telekom Cloud für Workloads mit Standardprofil, plus StackIT als zweiter Provider für höchstvertrauliche Daten.
Rationale
Delos befindet sich noch im Aufbau und ist für Produktiv-Workloads nicht reif. OTC liefert breitere Service-Decken inkl. SAP-Integration. StackIT bietet höhere Sovereignty-Tiefe für kritische Workloads. Eine 80/20-Split-Strategie mindert Konzentrationsrisiko und erfüllt EVB-IT-Cloud-Eignungsprüfung.
Residual risks
  • Multi-Cloud-Operations-Modell erhöht initialen Personalaufwand
  • Service-Roadmap der Sovereign-Provider wird in 12-Monats-Reviews neu bewertet
Run your own memo →

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.

Run this decision in DecisionOS →What is DecisionOS?