Quick Start Guide
Concrete, actionable steps to begin migration away from US cloud providers. What to do this week, this month, and this quarter.
1. Immediate Risk Mitigation (This Week)
Actions that reduce exposure without migrating anything. These create resilience and buy time.
Data Backup & Export
Action: Create offline backups of all critical data currently in US cloud.
- Export database snapshots to local/European storage
- Copy object storage (S3/Blob) contents to sovereign backup location
- Export all configuration, IAM policies, infrastructure-as-code
- Document all API keys, secrets (store copies in sovereign vault)
Why it matters: If US providers disable access tomorrow, you have your data. Even encrypted data exports are better than nothing—you retain the data even if keys are revoked.
Effort: 1-2 days per major system
Key & Secret Duplication
Action: Copy all encryption keys and secrets to sovereign control.
- Export customer-managed keys from AWS KMS/Azure Key Vault where possible
- Set up OpenBao on European/local infrastructure
- Duplicate all application secrets to sovereign vault
- For keys that cannot be exported: plan data re-encryption with sovereign keys
Why it matters: US providers can revoke your encryption keys. Sovereign key copies mean you can decrypt data even if provider access is terminated.
Effort: 2-5 days depending on key estate size
Dependency Inventory
Action: Create complete inventory of US cloud dependencies across all systems.
- List all AWS/Azure/GCP/OCI accounts and what runs on them
- Identify which systems would fail if provider access revoked
- Map data flows to identify where sensitive data resides
- Document monthly spend per provider (establishes migration priority)
Why it matters: You cannot migrate what you haven't inventoried. This is the foundation for all planning.
Effort: 1 week for initial inventory; ongoing refinement
2. Low-Hanging Fruit (First Month)
Workloads that can be migrated quickly to prove capability and build momentum. These are not the most critical systems—they're the easiest wins.
Ideal First Migration Candidates
| Workload Type | Why It's Easy | Typical Effort | Example |
|---|---|---|---|
| Static websites | No database, no state, just files | 1-2 days | Information sites, documentation portals |
| Development/test environments | Non-production, low risk if issues | 1-2 weeks | CI/CD pipelines, test databases |
| Internal tools | Limited users, tolerant of downtime | 1-2 weeks | Wiki, project management, document storage |
| Containerised applications | Portable by design, minimal refactoring | 1-2 weeks | Kubernetes workloads, Docker containers |
| Object storage (cold) | Just files, S3-compatible APIs exist | Days-weeks | Archives, backups, media assets |
| PostgreSQL databases | Standard, same on any provider | 1-2 weeks | Application databases not using RDS-specific features |
Where to Migrate (Available Now)
These sovereign providers are available on existing procurement frameworks or can be procured quickly. No need to wait for new infrastructure:
| Provider | Ownership | Key Services | Procurement |
|---|---|---|---|
| OVHcloud | French | VMs, Kubernetes, Object Storage, Databases | G-Cloud (UK), EU frameworks |
| Hetzner | German | VMs, Dedicated Servers, Storage | Direct, EU frameworks |
| Scaleway | French | VMs, Kubernetes, Serverless, Object Storage | Direct, EU frameworks |
| IONOS | German | VMs, Kubernetes, Databases, S3 Storage | G-Cloud (UK), EU frameworks |
| Exoscale | Swiss | VMs, Kubernetes, Object Storage | Direct |
Key insight: These providers offer S3-compatible object storage and standard Kubernetes. If your applications use these standard APIs (not AWS-specific features), migration can be as simple as changing endpoint URLs and credentials.
3. First Real Migration (First Quarter)
Once you've proven capability with low-risk workloads, move to the first meaningful migration that demonstrates sovereignty value.
Recommended First Meaningful Migration
Target: Email & Document Storage
Why this first:
- High sovereignty value (internal communications, policy documents)
- Proven alternatives exist (Nextcloud, Open-Xchange, sovereign mail)
- Moderate complexity—not trivial, not overwhelming
- Visible win that demonstrates capability to leadership
- Does not directly impact citizen services (lower risk)
Migration approach:
- Deploy Nextcloud or equivalent on sovereign infrastructure
- Pilot with one department/team
- Migrate document storage from SharePoint/OneDrive
- Migrate email from Exchange Online/Gmail (use sovereign mail provider or self-host)
- Establish as default for new documents; archive old in read-only
Sovereign alternatives:
- Documents: Nextcloud, ownCloud, Seafile
- Email: Open-Xchange, Zimbra, self-hosted (Postfix/Dovecot)
- Collaboration: Mattermost, Rocket.Chat, Element (Matrix)
Second Priority: Backup & Archive Migration
Target: Move All Backups to Sovereign Storage
Why this second:
- Protects against data loss if US access terminated
- Low risk—backups, not live systems
- High volume = demonstrates scale capability
- Uses standard S3 APIs (MinIO, Ceph, European providers)
Migration approach:
- Set up MinIO or use European provider S3-compatible storage
- Redirect all backup jobs to sovereign storage
- Copy existing backups/archives from S3/Azure Blob
- Validate restore capability from sovereign backups
- Decommission US cloud backup storage
4. Priority Migration Sequence
After quick wins, migrate based on sovereignty risk, not technical convenience. The question is: "What data/systems would hurt most if weaponised against us?"
Sovereignty Risk Prioritisation
Timeline Calculation Methodology
Base assumptions:
- Peacetime programme: 84 months (7 years) - sequential phases, standard procurement, normal staffing
- Wartime programme: 24 weeks (6 months) - maximum parallelisation, emergency powers, surge staffing
- Linear compression ratio: 84 months ÷ 6 months = 14:1
Why linear compression doesn't work:
- Irreducible minimums: Hardware delivery (4-8 weeks), security certification (2-4 weeks minimum)
- Parallelisation: Wartime runs phases concurrently; peacetime runs sequentially
- Scope reduction: Wartime migrates critical systems only; peacetime migrates everything
- Risk tolerance: Wartime accepts higher operational risk for speed
Compressibility analysis by activity:
| Activity | Peacetime | Wartime Min | Compressible? | Constraint / Rationale |
|---|---|---|---|---|
| Hardware procurement & delivery | 6-12 months | 4-8 weeks | HARD LIMIT | Manufacturing lead time, shipping, customs. Emergency: pre-positioned stock, allied nation transfers, commandeer existing datacentre capacity. |
| Datacentre facility readiness | 12-24 months | 0-2 weeks | HARD LIMIT | New build: 18+ months. Emergency: use existing government facilities, commercial colo, repurpose office space with containerised DC. |
| Security certification (full) | 6-12 months | 2-4 weeks | HARD LIMIT | Full accreditation takes months. Emergency: provisional authority to operate (ATO), risk acceptance at ministerial level, continuous assessment. |
| Network connectivity (new circuits) | 3-6 months | 1-2 weeks | HARD LIMIT | New fibre: months. Emergency: use existing circuits, temporary microwave/satellite links, commandeer commercial capacity. |
| Staff recruitment & onboarding | 3-6 months | 1-2 weeks | PARTIALLY | Normal HR: months. Emergency: redeploy existing staff, call up reservists, emergency contractor onboarding, waive clearance for non-sensitive roles initially. |
| Training & skills development | 3-6 months | 1-2 weeks | PARTIALLY | Full training: months. Emergency: pair with experienced staff, learn on the job, vendor professional services, accept higher error rate initially. |
| Procurement process | 3-12 months | 0-1 weeks | PARTIALLY | Competitive tender: months. Emergency: direct award powers, existing framework call-offs, emergency regulations (Civil Contingencies Act). |
| Data migration (large datasets) | 2-6 months | 1-4 weeks | PARTIALLY | Bandwidth limited. Emergency: physical data transfer (Snowball-style), parallel streams, accept longer cutover windows, prioritise critical data subsets. |
| Governance & decision-making | 1-3 months | 0-1 days | FULLY | Normal: committee cycles, consultations. Emergency: COBRA/national security council, ministerial direction, pre-delegated authorities. |
| Documentation & compliance paperwork | 1-3 months | Deferred | FULLY | Normal: extensive documentation. Emergency: do first, document later, accept audit findings, retrospective paperwork. |
| Stakeholder consultation | 2-6 months | Parallel/skip | FULLY | Normal: extensive engagement. Emergency: inform rather than consult, ministerial direction overrides, brief afterwards. |
| Pilot/testing phases | 3-6 months | 1-2 weeks | FULLY | Normal: extensive pilots. Emergency: compressed smoke testing, parallel running, accept rollback risk, fix forward. |
| Platform software deployment | 1-3 months | 1-3 days | FULLY | Software is instant. Peacetime delay is process, not technical. Ansible/OpenTofu can deploy CloudStack in hours. |
Key insight: Most peacetime duration is process, not physics. The truly incompressible constraints are hardware manufacturing, physical logistics, and minimum viable security assessment. Everything else is policy choice.
Wartime timeline drivers (priority-based, not ratio-based):
| Week | Constraint | What's possible |
|---|---|---|
| 0-2 | Decision & mobilisation | Emergency declaration, staff mobilisation, existing infrastructure identification |
| 2-8 | Hardware lead time | Deploy on existing capacity; emergency procurement initiated; first migrations using European providers |
| 8-16 | First hardware arrives | Critical system migration at scale; sovereign infrastructure online |
| 16-24 | Platform stabilisation | Secondary systems; optimisation; US exit for core systems |
Adjustment variables:
// Timeline configuration - adjust these values based on scenario
const TIMELINE_CONFIG = {
// Base durations
peacetime_months: 84, // 7 years standard programme
wartime_weeks: 24, // 6 months emergency programme
// Phase boundaries (wartime weeks)
phases: {
mobilisation: { start: 0, end: 2 },
infrastructure: { start: 2, end: 8 },
critical_migration: { start: 8, end: 16 },
secondary_exit: { start: 16, end: 24 }
},
// System priority to phase mapping
system_phase: {
identity_auth: 'infrastructure', // Wk 2-8 (enables everything else)
gov_communications: 'infrastructure', // Wk 2-8 (high value target)
benefits_welfare: 'critical_migration', // Wk 8-16
tax_systems: 'critical_migration', // Wk 8-16
healthcare_records: 'critical_migration', // Wk 8-16
immigration_border: 'secondary_exit', // Wk 16-24
shared_services: 'secondary_exit', // Wk 16-24
internal_admin: 'secondary_exit', // Wk 20-24
public_info_sites: 'post_core' // Wk 24+
},
// Peacetime equivalent (months from programme start)
peacetime_months_map: {
identity_auth: { start: 3, end: 12 },
gov_communications: { start: 3, end: 12 },
benefits_welfare: { start: 6, end: 18 },
tax_systems: { start: 6, end: 18 },
healthcare_records: { start: 6, end: 18 },
immigration_border: { start: 12, end: 24 },
shared_services: { start: 12, end: 24 },
internal_admin: { start: 18, end: 36 },
public_info_sites: { start: 24, end: 48 }
}
};
WARTIME targets shown primary; (Peacetime) in brackets. Wartime based on priority and dependencies, not linear compression.
| Priority | System Category | Sovereignty Risk | Wartime Target | Peacetime | Wartime Rationale |
|---|---|---|---|---|---|
| 4 | Identity & Authentication | Enables access to everything else | Wk 2-8 | Months 3-12 | Dependency: All other systems need auth. Must migrate first. Can use existing EU providers immediately. |
| 6 | Government Communications | Policy development; ministerial comms | Wk 2-8 | Months 3-12 | High-value target: Immediate espionage risk. Nextcloud/Matrix deployable on existing infrastructure. |
| 1 | Benefits/Welfare Systems | Mass citizen impact; social stability | Wk 8-16 | Months 6-18 | Hardware dependency: Requires sovereign infrastructure at scale. Wk 8 = first hardware delivery. |
| 2 | Tax Systems | Revenue collection; economic function | Wk 8-16 | Months 6-18 | Hardware dependency: Large databases require sovereign storage. Parallel with benefits. |
| 3 | Healthcare Records | Life-critical; highly sensitive data | Wk 8-16 | Months 6-18 | Hardware dependency: Compliance requirements need certified sovereign platform. |
| 5 | Immigration/Border Systems | National security; border control | Wk 14-20 | Months 12-24 | Sequencing: Complex integrations. After core platform proven. May require SECRET classification. |
| 7 | Shared Services (Notify, Pay) | Cross-government dependency | Wk 14-20 | Months 12-24 | Dependency: Other departments depend on these. Migrate after platform stable. |
| 8 | Internal Admin Systems | Operational but less citizen-facing | Wk 20-24 | Months 18-36 | Lower priority: Important but not citizen-critical. Backfill after core complete. |
| 9 | Public Information Sites | Important but lower sovereignty risk | Wk 24+ | Months 24-48 | Deferrable: Public data, low coercion value. Can remain on EU providers longer. |
Note: Priority order (1-9) reflects sovereignty risk. Migration order differs because of dependencies (e.g., Identity/Auth is priority 4 for risk but migrates first because everything depends on it).
5. What NOT to Do First
Anti-Patterns
| Don't Do This | Why It Fails | Do This Instead |
|---|---|---|
| Start with the most critical system | Too risky; failure kills programme momentum | Start with low-risk systems to prove capability |
| Wait for perfect sovereign infrastructure | Delays action indefinitely | Use existing European providers; iterate |
| Big-bang migration | Catastrophic if anything goes wrong | Incremental migration with rollback |
| Lift-and-shift AWS-specific services | Lambda, DynamoDB etc. have no direct equivalent | Refactor to standard tech before migration |
| Migrate without data backup first | Data loss risk if migration fails | Always backup to sovereign storage first |
| Ignore vendor lock-in in new platform | Creates new dependency | Use open standards (K8s, S3 API, PostgreSQL) |
6. Week 1 Checklist
Actions for This Week
Start Today
The actions above can begin immediately.
Perfect is the enemy of done.