A realistic 90-day plan for migrating workloads to sovereign cloud infrastructure. Covers discovery, workload classification, landing zone design, identity, networking, cutover, and post-migration validation.
Sovereign cloud is not a political preference. It is a compliance requirement. Since Schrems II invalidated the EU-US Privacy Shield, organisations processing European personal data face a concrete legal problem: data stored or processed by providers subject to extraterritorial access laws may not meet GDPR requirements. Add NIS2, DORA, and sector-specific regulations in finance, healthcare, and public administration, and the picture sharpens fast. If your data classification includes anything above "public", you need to know exactly where it lives, who can access it, and under which jurisdiction.
This is the 90-day migration playbook we use at Out.Cloud. It is not theoretical. It comes from moving production workloads for organisations that cannot afford regulatory ambiguity. The model assumes 20 to 50 workloads, a mix of cloud-native and legacy, and a target sovereign provider such as OVHcloud, S3NS, or similar European-operated infrastructure.
Week 1-2: Discovery and Classification
Every migration that runs late started with an incomplete inventory. Discovery is not optional and it is not a checkbox exercise. You need three things before any architecture work begins: a complete workload inventory, a data sensitivity classification for each workload, and a dependency map that shows what talks to what.
Workload Inventory
Start with automated discovery. Use your existing cloud provider's tools or open-source scanners to catalogue every running workload, its resource profile, and its network connections. Manual spreadsheets miss things. Automated scans find the forgotten test environment that is still processing production data.
For each workload, capture:
- Compute profile: vCPU, memory, storage type and volume
- Network dependencies: inbound and outbound connections, DNS records, load balancers
- Data stores: databases, object storage, file shares, caches
- Authentication method: how users and services authenticate
- SLA requirements: availability target, maximum acceptable downtime during cutover
- Current compliance posture: which regulations apply to this specific workload
Data Classification
Not every workload needs sovereign infrastructure. That is an important point. Migrating everything to sovereign cloud when only 40% of your workloads handle regulated data wastes budget and adds unnecessary complexity. Classify each workload into clear tiers:
- Tier 1 - Sovereign required: personal data under GDPR, financial data under DORA, health data, data subject to national security rules. Must reside in-jurisdiction with no extraterritorial access risk.
- Tier 2 - Sovereign preferred: business-sensitive data, intellectual property, internal communications. Not legally mandated but strategically important to keep in-jurisdiction.
- Tier 3 - No residency constraint: public data, marketing assets, non-sensitive analytics. Can remain on any provider.
Data classification is a legal decision, not a technical one. Your DPO and legal team must validate the tier assignment for each workload before architecture begins. Reclassification after migration has started causes delays measured in weeks, not days.
Dependency Mapping
Map every connection between workloads. Pay special attention to cross-tier dependencies, situations where a Tier 3 workload calls a Tier 1 API or reads from a Tier 1 database. These dependencies determine migration sequencing. You cannot migrate a database before migrating the services that depend on it, and you cannot leave a Tier 1 database behind when its consumers move to sovereign infrastructure.
"The dependency map is the migration plan. Everything else is scheduling."
Out.Cloud Migration Practice
Week 3-4: Landing Zone Design
The landing zone is the foundation that receives your workloads. Get it wrong and you spend months reworking networking, permissions, and logging after migration. Get it right and every subsequent workload lands cleanly.
Network Topology
Design your network architecture before provisioning anything. Key decisions include:
- VPC/VNet segmentation: separate environments (production, staging, shared services) into isolated network segments with controlled peering
- Private connectivity: establish dedicated links between on-premises infrastructure and your sovereign cloud provider. Do not rely on VPN as your primary production path.
- DNS architecture: plan split-horizon DNS early. You will need internal resolution for private endpoints and external resolution for public services. This is where most teams underestimate complexity.
- Egress controls: define what traffic can leave the sovereign environment and where it can go. This is a compliance control, not just a cost control.
Resource Hierarchy and Policy-as-Code
Establish an organisational hierarchy that maps to your governance model. Projects, folders, or accounts should reflect business units, environments, and compliance boundaries. Then codify your policies from day one.
# Example: enforce data residency at the project level
resource "ovhcloud_cloud_project" "sovereign_prod" {
description = "Production - Sovereign Tier 1"
region = "EU-WEST-PAR"
# Policy: no resources outside approved EU regions
lifecycle {
precondition {
condition = contains(["EU-WEST-PAR", "EU-WEST-SBG", "EU-WEST-GRA"], var.region)
error_message = "Tier 1 workloads must deploy to approved EU regions only."
}
}
}Logging and Audit Architecture
Logging is not something you add after migration. It is a landing zone component. Every action on sovereign infrastructure must be auditable: who did what, when, from where. Configure centralised log collection, immutable audit trails, and retention policies that meet your regulatory requirements. For DORA-regulated workloads, this means minimum retention periods and tamper-evident storage.
Week 5-6: Identity and Security
Identity is the perimeter. In sovereign cloud, this is doubly true because you are establishing trust boundaries that have legal significance. Who can access what, from where, under which jurisdiction's authority, these are not abstract questions.
SSO and Identity Federation
Integrate your existing identity provider with the sovereign cloud platform. This typically means SAML or OIDC federation from your corporate IdP (Azure AD, Okta, Keycloak) to the cloud provider's IAM. Key requirements:
- All human access through federated SSO. No local cloud accounts for humans.
- Service accounts with short-lived credentials, rotated automatically
- MFA enforced for all administrative access, no exceptions
- Session duration limits aligned with your security policy
RBAC Model
Design your role-based access control before migrating workloads. Map existing roles to the new environment. Common roles include:
- Platform admin: manages landing zone infrastructure, networking, and IAM policies
- Workload owner: deploys and manages applications within assigned projects
- Security auditor: read-only access to all logs, policies, and configurations
- Billing viewer: cost visibility without operational access
Keep the role model simple. Five to seven roles cover most organisations. More than ten roles signals over-engineering that will collapse into "everyone gets admin" within six months.
Encryption and Key Ownership
Sovereign cloud only works if you control your encryption keys. This is non-negotiable. If the provider holds the keys, jurisdictional protection is weakened because a legal order to the provider can compel decryption.
- At rest: all data encrypted with customer-managed keys (CMK). Keys stored in an HSM you control or in the provider's KMS with BYOK (Bring Your Own Key).
- In transit: TLS 1.3 minimum for all connections. Mutual TLS for service-to-service communication within the sovereign environment.
- Key rotation: automated rotation on a schedule that meets your compliance requirements. Typically 90 days for data encryption keys, 12 months for key encryption keys.
Week 7-8: Migration Execution
This is where the work gets tangible. Two weeks of focused migration execution, prioritised by the dependency map built in week one.
Migration Strategy Per Workload
Not every workload migrates the same way. For each workload, decide:
- Lift and shift (rehost): move the workload as-is. Best for VMs and stateful applications where refactoring is not justified by the timeline. Fast, low risk, but you inherit technical debt.
- Re-platform: minor modifications to take advantage of managed services. Move a self-managed PostgreSQL to the provider's managed database service, for example. Moderate effort, good ROI.
- Refactor: significant changes to the application. Only justified if the workload is already scheduled for modernisation. Do not combine migration and refactoring unless you have budget for delays.
"Migrate first, optimise later. The goal of the 90-day window is operational sovereignty, not architectural perfection."
Out.Cloud Migration Practice
Data Replication and Cutover
For stateful workloads, the migration sequence matters:
- Set up continuous replication from source to target (database replication, object storage sync)
- Validate data consistency between source and target, checksums, row counts, application-level tests
- Schedule a cutover window with stakeholders. Communicate the window to all affected teams.
- During the window: stop writes to source, verify final sync, switch application endpoints to target, verify reads and writes on target
- Keep source available in read-only mode for 48 to 72 hours as a rollback option
DNS Cutover Planning
DNS changes are the most underestimated risk in any migration. Reduce TTLs to 300 seconds at least 48 hours before cutover. Prepare rollback DNS records in advance. Test resolution from multiple locations and ISPs. Account for clients that ignore TTLs, some enterprise proxies and resolvers cache aggressively regardless of TTL settings.
Week 9-10: Validation and Hardening
Migration is not complete when the workload runs on the new infrastructure. It is complete when you can prove it runs correctly, securely, and within compliance boundaries.
Performance Benchmarking
Compare performance baselines between the old and new environments. Measure:
- Application response times (p50, p95, p99)
- Database query latency
- Inter-service communication latency
- Throughput under load, run synthetic load tests that simulate production traffic patterns
Performance regressions of more than 15% require investigation before moving to the next phase. Common causes include undersized instances, missing database indices after migration, and network path changes that add latency.
Compliance Validation
Run a compliance check against the requirements documented in week one. For each Tier 1 workload, verify:
- Data residency: all data stored in the approved jurisdiction, confirmed by provider audit tools
- Access controls: only authorised identities can reach the workload, confirmed by IAM policy review
- Encryption: customer-managed keys in use, confirmed by KMS audit logs
- Audit trail: all operations logged, logs stored immutably, retention meets regulatory minimums
- Network isolation: no unapproved egress paths, confirmed by network policy review and flow logs
A sovereign landing zone is a new attack surface. Run an infrastructure penetration test before declaring the migration complete. Focus on IAM misconfigurations, network segmentation gaps, and exposed management interfaces. Internal pen tests catch what automated scanners miss.
Failover and Disaster Recovery Testing
Test your failover procedures in the new environment. Simulate a zone failure. Simulate a database failover. Verify that backups restore correctly and within your RTO. Document the results. This documentation becomes part of your compliance evidence pack and your operational runbook.
Week 11-12: Operationalisation
The final two weeks shift focus from migration to operations. The goal is to hand over a sovereign environment that the team can run independently, with confidence.
Monitoring and Alerting
Deploy observability across the entire sovereign environment. This means:
- Infrastructure monitoring: CPU, memory, disk, network for all compute resources
- Application monitoring: request rates, error rates, latency distributions
- Security monitoring: failed authentication attempts, privilege escalations, policy violations
- Cost monitoring: daily spend tracking with alerts for anomalies
Build dashboards that answer the question "is everything working?" at a glance. Then build the second layer of dashboards that answer "what is broken and where?" for incident response.
Runbooks and Knowledge Transfer
Write runbooks for every operational scenario the team will encounter. At minimum:
- How to deploy a new version of each migrated application
- How to scale up and scale down compute and storage
- How to respond to a security alert
- How to restore from backup
- How to rotate encryption keys
- How to onboard a new team member with appropriate access
- How to handle a compliance audit request
Conduct formal knowledge transfer sessions. The team that will operate the environment must be able to perform every runbook procedure without assistance from the migration team.
Ongoing Governance Model
Establish a governance cadence that will outlast the migration project:
- Weekly: review alerts, incidents, and cost anomalies
- Monthly: review access permissions, rotate any manual credentials, check compliance posture
- Quarterly: run compliance validation against current regulatory requirements, update policies for any regulatory changes, review and update runbooks
Common Pitfalls
After running this playbook across multiple engagements, the failure patterns repeat. These are the issues that cause the most delays and post-migration pain.
Underestimating DNS Propagation
Teams plan a 2-hour cutover window and discover that some clients are still hitting the old infrastructure 24 hours later. Enterprise firewalls, CDN edge caches, and mobile carriers all have caching behaviours that ignore TTL settings. Plan for a 48-hour convergence window, not a 2-hour cutover.
Identity Federation Gaps
The SSO integration works for human users but breaks for CI/CD pipelines, monitoring agents, and third-party integrations that were using API keys tied to the old environment. Inventory every non-human identity during discovery. They outnumber human users by a factor of 5 to 10 in most organisations.
Network Latency Between Regions
If you are migrating from a hyperscaler region in Frankfurt to a sovereign provider in Paris, you are adding 10 to 15 milliseconds of latency to every cross-environment call. For a single API call this is negligible. For a request that fans out to 20 microservices, some of which still run in the old environment during migration, the cumulative effect is measurable. Plan your migration waves to minimise cross-environment chattiness.
Underscoping Shared Services
Shared services like logging pipelines, secret management, and container registries are easy to forget during discovery because they "belong to everyone". They need to migrate first, not last, because everything depends on them.
Decision Framework: When Sovereign Cloud Is the Right Choice
Sovereign cloud is not always the answer. It is the right answer when specific conditions exist. Use this framework to decide.
Sovereign cloud is the right choice when:
- You process personal data of EU residents and your current provider is subject to laws like the US CLOUD Act or FISA 702
- Your regulator has issued explicit guidance on data residency (common in banking, healthcare, and public sector)
- You operate in a sector covered by NIS2 or DORA and need to demonstrate operational resilience within EU jurisdiction
- Your customers or partners contractually require data residency guarantees
- You are bidding on public sector contracts that mandate European cloud infrastructure
Sovereign cloud may not be necessary when:
- Your workloads process only non-personal, non-sensitive data
- Your regulatory framework accepts Standard Contractual Clauses or adequacy decisions as sufficient safeguards
- Your compliance team has assessed the risk and determined that hyperscaler data processing agreements provide adequate protection for your specific use case
- You do not operate in a regulated sector and your data classification shows no Tier 1 or Tier 2 workloads
The honest assessment matters. Over-migrating to sovereign cloud when it is not required adds cost and operational complexity without compliance benefit. Under-migrating when it is required creates regulatory exposure that can result in fines up to 4% of global annual turnover under GDPR.
FAQ: Sovereign Cloud Migration
How long does a sovereign cloud migration typically take?
A well-scoped migration of 20 to 50 workloads can be completed in 90 days. Larger estates with complex legacy dependencies or multiple regulatory jurisdictions may require 6 to 9 months, but the 90-day model works as a first wave to establish the landing zone and migrate priority workloads.
Is sovereign cloud only relevant for companies subject to GDPR?
No. GDPR is the most cited driver, but NIS2, DORA, national security regulations, and sector-specific rules in healthcare, finance, and public administration all create data residency and operational sovereignty requirements that sovereign cloud addresses.
Can we use a sovereign cloud provider and still run multi-cloud?
Yes. Sovereign cloud handles workloads with residency or jurisdictional constraints. Non-regulated workloads can remain on hyperscalers. The key is a clear data classification model that determines which workloads go where, and consistent identity and networking across environments.
What is the biggest risk in a sovereign cloud migration?
Underestimating identity and networking complexity. Most teams focus on compute and storage migration but neglect SSO federation, DNS propagation timing, and inter-region latency. These are the issues that cause delays and post-migration incidents.
If you are evaluating a sovereign cloud migration or need to validate your current approach, start with a 30-minute discovery call. We will assess your workload profile, regulatory exposure, and timeline, and tell you honestly whether the 90-day model fits your situation.
