The Sovereignty Roadmap: Compliant Cloud in 12 Months

Executive Summary

Sovereign cloud is no longer a question of whether, but of how and when. This article provides a proven 4-phase roadmap for DACH enterprises that want to build a NIS2- and GDPR-compliant Sovereign Landing Zone on the AWS European Sovereign Cloud (ESC) within 12 months. The roadmap is grounded in the AWS Migration Acceleration Program (MAP) and Storm Reply's practical project experience from over 600 completed cloud migrations in the DACH market. Each phase includes concrete milestones, decision gates, and the most common mistakes — so your organization avoids the typical pitfalls.

Why a Structured Roadmap Is Critical

Sovereign cloud migrations rarely fail due to technology. They fail due to poor planning: unclear scope definition, missing stakeholder alignment, underestimated legacy complexity, and neglected compliance documentation. The difference between a successful and a failed project lies almost always in the first eight weeks — in the quality of the assessment phase.

The migration patterns for sovereign cloud are now well understood. AWS provides the MAP as a structured methodology. Partners like Storm Reply bring experienced specialists. And the BSI has defined a clear compliance framework with the C5 catalog against which progress is measurable.

The following 12-month roadmap is structured in four phases: Assessment, Architecture, Migration, and Validation. Each phase has defined entry and exit criteria, along with stage gates where the decision to proceed to the next phase is formally evaluated.

The 4-Phase Roadmap at a Glance

1. Phase 1 — Assessment (Months 1–2): Gap Analysis and Scope Definition

   Goal: complete inventory of the current state, classification of all workloads by sovereignty requirement, identification of regulatory gaps.

2. Phase 2 — Architecture (Months 3–4): Sovereign Landing Zone and Target Architecture

   Goal: design and build the Sovereign Landing Zone on the ESC, define security and governance guardrails, service mapping, and decision on migration strategies per workload.

3. Phase 3 — Migration (Months 5–10): Staged Workload Migration

   Goal: migrate all sovereignty-relevant workloads in prioritized waves, validate compliance controls after each wave, hand over operations to internal teams.

4. Phase 4 — Validation (Months 11–12): Audit Readiness and Certification

   Goal: full BSI C5 audit readiness, completed NIS2 documentation package, BSI registration, handover to steady-state operations with defined SLAs.

Phase 1: Assessment — The Foundation (Months 1–2)

What Happens in This Phase

The assessment is the most important phase of the entire project. This is where the project's direction is set: what must be sovereign? What can stay on eu-central-1? Which regulatory requirements apply specifically to this organization? How large is the gap to the target state?

The assessment runs three parallel workstreams:

1. Workload Inventory and Classification

   All systems, applications, and data sets are catalogued and classified by sovereignty requirement. Classification dimensions: data type (personal data, restricted classified, trade secret), regulatory framework (GDPR Art. 9, NIS2 KRITIS, DORA), availability requirement (RTO/RPO), external dependencies (third-party vendors, APIs, SaaS).

2. Regulatory Gap Analysis (NIS2 Gap Assessment)

   Current state compared against NIS2 requirements, BSI C5 controls, and GDPR obligations. Output: prioritized remediation plan with timeline. For NIS2-affected organizations not yet registered with the BSI, registration must be initiated immediately — it has a separate deadline.

3. Technical Discovery on AWS

   Where AWS accounts already exist: automated discovery with AWS Migration Evaluator. Identifies all services in use, resource inventory, cost baseline. This data forms the basis for service mapping in Phase 2.

Stage Gate 1 — Decision Point After Phase 1

Before Phase 2: Is the scope clear and accepted by all stakeholders — IT, legal, data protection, compliance, leadership? Is there an approved business case? Has the MAP program been applied for? All three must be confirmed before Phase 2 begins.

Common Mistakes in Phase 1

• Scope inflation: classifying too many workloads as "sovereignty-relevant" without regulatory justification — drives unnecessary cost and complexity.
• Missing legal involvement: running the assessment as a purely technical exercise without a legal assessment of regulatory requirements.
• Missing BSI registration: NIS2-affected organizations not yet registered with the BSI may already be in breach of the March 6, 2026 registration deadline.

Phase 2: Architecture — The Sovereign Landing Zone (Months 3–4)

What Happens in This Phase

Phase 2 has two outputs: the Sovereign Landing Zone (SLZ) on the ESC, and the target architecture for every sovereignty-relevant workload.

Sovereign Landing Zone Build

1. AWS Organizations and ESC Account Structure

   Build organizational structure with dedicated OUs for production, test, and management environments. ESC accounts are created as a separate OU within the existing AWS Organizations structure — or built from scratch.

2. AWS Control Tower Deployment with Sovereign Guardrails

   Control Tower is the core of the Landing Zone: automated account vending, baseline guardrails, and compliance monitoring. For the ESC, additional Sovereign Controls are activated: blocking data exports outside the ESC, enforcing region locks, mandating MFA for all access.

3. Service Control Policies (SCPs) Definition

   Organization-level SCPs that make prohibited actions technically impossible: replication to non-EU regions, creation of public S3 buckets, disabling CloudTrail, use of non-approved AWS services. SCPs are the last line of defense — they apply even when IAM permissions are misconfigured.

4. Key Management Strategy

   Define KMS key structure: which workloads require Customer Managed Keys (CMKs), which require CloudHSM? Key rotation policy, key lifecycle, and audit trail configuration via CloudTrail.

5. Network Architecture

   Hub-and-spoke VPC design with Transit Gateway. PrivateLink for service-to-service communication without internet egress. Direct Connect for hybrid on-premises-to-ESC connections. Network Firewall and WAF at network boundaries.

6. Compliance Monitoring Setup

   AWS Config with compliance rules against BSI C5, GDPR, and NIS2. AWS Security Hub as central compliance dashboard. AWS Audit Manager with BSI C5 Assessment Framework for automated evidence collection.

Service Mapping and Migration Strategies

For each sovereignty-relevant workload, the migration strategy is determined. AWS defines six strategies (the "6 Rs"):

Rehost (Lift and Shift)

1:1 migration without architectural changes. Fast, low risk, but no cloud optimization. Suitable for simple applications without ESC-incompatible service dependencies.

Replatform (Lift, Tinker and Shift)

Migration with minimal optimizations: e.g., switching from self-managed MySQL to RDS, or from EC2-based queue to SQS. Small changes, measurable efficiency gains.

Refactor / Re-architect

Significant architectural changes: containerization, microservices decomposition, serverless migration. Highest effort, but strongest long-term cost optimization and resilience.

Repurchase

Switching to a different product, typically a SaaS solution. Relevant when current software lacks ESC compatibility and a better ESC-native equivalent exists.

Retire

Decommissioning systems that no longer serve a business function. Assessments typically identify 10–20% of workloads as retire candidates — these do not need to be migrated.

Retain

Workloads staying on-premises or in eu-central-1 for now — either because the required service is not yet available in the ESC, or because the sovereignty risk is assessed as manageable.

Stage Gate 2 — Decision Point After Phase 2

The Landing Zone must pass an internal security review and optionally an external pre-audit by a BSI-accredited auditor. Only then does Phase 3 begin.

Phase 3: Migration — Staged Workload Waves (Months 5–10)

The Wave Model

Sovereign cloud migrations run in waves — typically 3 to 5 waves over 6 months. Prioritization follows a clear principle: Wave 1 contains the simplest, lowest-risk workloads. Each subsequent wave incrementally increases complexity. Critical production systems come in Wave 3 or later.

1. Wave 1 (Months 5–6): Proof-of-Value Workloads

   Simple, non-critical systems: development environments, test data repositories, internal tools. Goal: build operational ESC experience, test processes, validate monitoring. No production pressure, but real ESC infrastructure.

2. Wave 2 (Months 7–8): Medium Complexity

   Systems with moderate business value and clearly defined data sovereignty obligations: internal data marts, HR systems, analytics platforms. The encryption and key management strategy is validated in a production context here for the first time.

3. Waves 3–4 (Months 9–10): Critical Production Systems

   Core production systems with the highest sovereignty requirements: core banking, patient data, KRITIS OT systems. These waves require careful rollback planning, parallel operation during the transition period, and intensive testing before cutover.

Compliance Checkpoint After Each Wave

After each wave, a compliance checkpoint confirms: do the configured controls align with BSI C5 requirements? Are all CloudTrail logs complete? Are SCPs correctly enforced? This checkpoint is not bureaucratic overhead — it is the mechanism that prevents compliance debt from accumulating across waves.

Common Mistakes in Phase 3

• Skipped waves: pressure to migrate critical systems early, before sufficient ESC operational experience is built. This significantly increases the risk of unplanned outages.
• Missing rollback planning: every cutover requires a tested rollback path. "We can go back if needed" is not a rollback strategy.
• Neglected third-party software: many enterprise applications have dependencies on SaaS services that may not be ESC-compatible. These must be identified in Phase 1 and addressed in Phase 2.

Stage Gate 3 — Decision Point After Phase 3

Are all target workloads successfully migrated? Is operations stable (at least 4 weeks without critical incidents)? Have all compliance checkpoints been completed positively? Only then does Phase 4 begin.

Phase 4: Validation — Audit Readiness and Certification (Months 11–12)

What Happens in This Phase

Phase 4 is not a technical phase — it is a documentation and evidence phase. The goal: full audit readiness for BSI C5, NIS2, and where applicable DORA. Upon completion, the organization is able to present all compliance evidence to an auditor on request.

1. BSI C5 Evidence Collection via AWS Audit Manager

   AWS Audit Manager automatically generates compliance evidence for the BSI C5 control framework: screenshots, configuration reports, CloudTrail logs, Security Hub findings. This evidence is structured into an audit package ready for external review.

2. NIS2 Documentation Package

   Complete documentation of implemented cybersecurity measures per NIS2 Article 21: risk analysis, business continuity, supply chain security, encryption, access controls, incident response plan, and reporting processes.

3. GDPR Processing Register and Technical/Organizational Measures

   Updated record of processing activities (ROPA) referencing the ESC as processing location. Technical and organizational measures (TOMs) updated and aligned with ESC-specific controls.

4. Final Assessment and Pre-Audit

   Optional pre-audit by an external BSI-accredited auditor before the formal audit. Identifies remaining gaps that can be closed in the final weeks before the audit date.

5. Operations Handover and RACI Update

   Formal handover to steady-state operations: updated RACI matrix for all sovereignty controls, ESC operations handbook covering ESC-specific processes (key rotation, incident response, change management), and runbooks for critical operational scenarios.

Outcome After Month 12

After Phase 4 is complete, the organization has:

• All sovereignty-relevant workloads operating in production on the ESC
• BSI C5 Type 2 audit readiness — complete evidence documentation
• NIS2 documentation package — ready for BSI inspection
• Updated GDPR record of processing activities
• Internally trained operations team with ESC-specific expertise
• Defined SLAs and escalation paths for sovereign steady-state operations

AWS Migration Acceleration Program (MAP): Credits and Methodology

The AWS Migration Acceleration Program (MAP) is the structural framework within which Storm Reply delivers ESC migrations. MAP offers three core advantages:

Migration Credits

Financial AWS credits that directly reduce migration costs. The credit volume depends on migration scope and is determined in the MAP assessment. For DACH organizations moving their first workloads to the ESC, credits are particularly valuable for covering transition costs.

Proven Tools and Accelerators

MAP migrations use pre-configured toolchains: AWS Application Migration Service (MGN) for server migrations, AWS Database Migration Service (DMS) for databases, CloudEndure for continuous replication during migration execution.

Technical Support and Reviews

MAP projects have access to AWS-internal architecture reviews, migration playbooks, and escalated support. For ESC migrations, this access is particularly valuable given that the ESC is a new platform and partner ESC experience is still rare.

Storm Reply is a MAP-qualified partner and can activate MAP credits and resources for customer projects. The MAP assessment is typically initiated at the end of Phase 1.

Storm Reply: 12 Months in Practice

Storm Reply is an AWS Premier Consulting Partner DACH with AWS Migration Competency and AWS Security Competency. Storm Reply's methodology for ESC migrations is built on over 600 completed cloud projects in the DACH market and integrates specifically German compliance requirements: NIS2 implementation, BSI registration, GDPR processing registers, and sector-specific requirements (KRITIS, DORA, TKG).

For the 12-month roadmap, Storm Reply typically deploys a dedicated project team of migration architects, security engineers, compliance specialists, and project management. The team works hybrid — on-site consulting in DACH combined with remote delivery from Gütersloh, Hamburg, Frankfurt, Berlin, Dortmund, or Munich.

Storm Reply is part of the Reply Group with 16 AWS Competencies, 17 Service Deliveries, and 1,500+ AWS certifications. Storm Reply — AWS Premier Consulting Partner DACH. Learn more: reply.com/storm-reply

Sources and Further Reading

1. AWS: AWS Migration Acceleration Program (MAP)
2. AWS: Europe Digital Sovereignty on AWS
3. AWS Documentation: AWS Control Tower — Landing Zone
4. BSI: BSI C5 Criteria Catalogue
5. BSI: NIS-2 in Germany — BSI
6. AWS Documentation: AWS Audit Manager