Implementation Guidance
→
→
→
→
→
→
→
Application Modernisation Strategy
Comprehensive guidance for COTS replacement, application rewrites, upgrade management, and shared development opportunities across the coalition.
1. Current and Planned Cloud Migrations
Migration to sovereign cloud must coordinate with—not duplicate—existing cloud migration programmes.
Departments mid-migration to US hyperscalers face a critical decision point.
Migration Status Categories
| Category | Current State | Recommended Action | Risk Level |
|---|---|---|---|
| Pre-migration Still on-premises |
Legacy datacentre, not yet in cloud | Redirect to sovereign Skip US cloud entirely |
Low |
| Planning phase Migration designed, not started |
Architecture complete, contracts pending | Pivot architecture Redesign for sovereign target |
Medium |
| Early migration <25% workloads moved |
Some workloads in US cloud | Pause and redirect Complete assessment, redirect remaining |
Medium |
| Mid-migration 25-75% workloads moved |
Significant US cloud footprint | Complete critical, then migrate out Avoid half-finished state |
High |
| Complete >75% in US cloud |
Fully cloud-native on US provider | Prioritise for sovereign migration Highest sovereignty risk |
Critical |
Treatment Plans for Applications in Migration
Database Upgrades (e.g., Oracle 19c → 23ai, PostgreSQL 14 → 17)
Scenario: Department planning database version upgrade as part of cloud migration.
| Option | Approach | Recommendation |
|---|---|---|
| A: Continue to US cloud | Complete Oracle/AWS RDS upgrade as planned | Not recommended - deepens lock-in |
| B: Upgrade on-premises, then migrate | Upgrade in current DC, then migrate to sovereign | Acceptable - if timeline allows |
| C: Migrate then upgrade | Move current version to sovereign, upgrade there | Preferred - single migration |
| D: Re-platform to PostgreSQL | Convert Oracle → PostgreSQL during migration | Best long-term - eliminates Oracle dependency |
COTS Version Upgrades (e.g., ServiceNow, SAP, Dynamics)
Scenario: Vendor-mandated upgrade to maintain support/security.
- If COTS is strategic (keeping long-term): Complete upgrade, plan sovereign hosting if self-hosted option exists
- If COTS is tactical (replacement planned): Defer upgrade, accelerate replacement timeline
- If COTS is SaaS-only (no self-host option): Evaluate sovereign alternatives immediately; upgrade only if replacement timeline exceeds support window
2. COTS Application Strategy
Commercial Off-The-Shelf (COTS) applications present unique sovereignty challenges: many are US-headquartered SaaS products with no self-hosting option.
COTS Sovereignty Assessment Matrix
| Category | Examples | Sovereignty Risk | Strategy |
|---|---|---|---|
| US SaaS-only | Salesforce, ServiceNow, Workday, Slack | Critical | Replace with sovereign alternative or open source |
| US with self-host option | GitLab (US HQ), Atlassian (AU but US-listed) | High | Self-host on sovereign infrastructure; evaluate open alternatives |
| EU/Allied COTS | SAP (DE), OpenText (CA), Sopra Steria (FR) | Medium | Acceptable with sovereign hosting; monitor for US acquisition |
| Open source with commercial support | Red Hat (US but OSS), SUSE (DE), Canonical (UK) | Low | Preferred; code is sovereign even if vendor changes |
COTS Replacement Roadmap
| US COTS Product | Function | Sovereign Alternative | Maturity | Coalition Action |
|---|---|---|---|---|
| Microsoft 365 | Productivity suite | Nextcloud + OnlyOffice / Collabora | Production | Deploy; proven at scale (Munich, Denmark) |
| Slack | Team messaging | Mattermost / Element (Matrix) | Production | Deploy; French government uses Element |
| Zoom | Video conferencing | Jitsi Meet / BigBlueButton | Production | Deploy; widely used in education |
| ServiceNow | ITSM | GLPI / iTop / Zammad | Maturing | Coalition investment to reach enterprise scale |
| Salesforce | CRM | Odoo / SuiteCRM / ERPNext | Maturing | Coalition investment for government-specific modules |
| Workday | HR/Finance | Odoo / ERPNext | Maturing | Significant investment required; phased approach |
| Autosys / Control-M | Job scheduling | Apache Airflow / Rundeck | Production | Coalition development opportunity - see Section 4 |
| Splunk | Log management | OpenSearch / Grafana Loki | Production | Deploy; widely adopted |
| Datadog / New Relic | APM/Observability | Grafana + Prometheus + Jaeger | Production | Deploy; standard cloud-native stack |
| GitHub | Source control | GitLab CE / Forgejo / Gitea | Production | Deploy; see Section 7 |
3. Upgrade Suspension Risk Analysis
Suspending upgrades to await sovereign migration creates security and operational risks
that must be explicitly managed.
Risk Matrix: Upgrade Suspension Scenarios
| Risk Category | If Upgrade Suspended 6 Months | If Upgrade Suspended 12 Months | If Upgrade Suspended 24+ Months |
|---|---|---|---|
| Security Vulnerabilities | Low - vendor patches still available | Medium - may miss security-only releases | High - version likely out of support |
| Vendor Support | Low - still in support window | Medium - approaching end of support | High - extended support costs or no support |
| Licensing Compliance | Low - normal renewal cycle | Medium - may require contract renegotiation | High - audit risk, compliance penalties |
| Technical Debt | Low - one version behind | Medium - multiple versions behind | High - major upgrade effort required |
| Migration Complexity | Low - straightforward migration | Medium - version compatibility issues | High - may require intermediate upgrades |
Decision Framework: Upgrade vs. Wait
Proceed with Upgrade If:
- Sovereign migration timeline exceeds vendor support window
- Security vulnerabilities in current version are actively exploited
- Regulatory compliance requires specific version features
- Upgrade is to open-source compatible version (e.g., Oracle → PostgreSQL compatible)
- Upgrade can be done on sovereign infrastructure (not deepening US lock-in)
Defer Upgrade If:
- Sovereign migration timeline is within 12 months
- Upgrade would deepen proprietary lock-in (e.g., new AWS-specific features)
- System is planned for replacement, not migration
- Extended support is available at reasonable cost
- Risk can be mitigated through compensating controls (WAF, network isolation)
Compensating Controls for Deferred Upgrades
| Risk | Compensating Control | Implementation |
|---|---|---|
| Unpatched vulnerabilities | Virtual patching via WAF | Deploy ModSecurity rules for known CVEs |
| Network exposure | Network segmentation | Isolate legacy systems in dedicated VLANs |
| Data exfiltration | DLP and monitoring | Enhanced logging, anomaly detection |
| Authentication weakness | External identity layer | Wrap with Keycloak/ZITADEL proxy |
| Support gap | Internal expertise | Retain/hire specialists; document tribal knowledge |
4. Shared Development Opportunities
The coalition model creates unique opportunities: applications developed by one member can be consumed by all members, multiplying the return on investment.
Coalition Development Principle: "Build once, deploy everywhere."
Every jurisdiction faces similar challenges. A scheduling system developed by the UK
benefits all four nations immediately.
Priority Coalition Development Projects
Project: SovereignScheduler (Autosys/Control-M Replacement)
Problem: Autosys (Broadcom) and Control-M (BMC) are US COTS products used across all four jurisdictions for enterprise job scheduling. Both are expensive, proprietary, and present sovereignty risks.
Solution: Coalition-funded development of enterprise-grade open-source job scheduler based on Apache Airflow with government-specific extensions.
| Lead Nation: | UK (existing Airflow expertise in HMRC) |
| Estimated Cost: | €15-25M over 3 years |
| Cost per Nation: | €4-6M (vs €10-20M/year in Autosys licences each) |
| Timeline: | MVP in 12 months; production in 24 months |
| ROI: | Break-even in Year 2; €40-80M savings by Year 5 |
Project: SovereignITSM (ServiceNow Replacement)
Problem: ServiceNow is deeply embedded in government IT operations across all jurisdictions. US SaaS-only model with significant sovereignty risk.
Solution: Coalition investment in GLPI or iTop to reach enterprise government scale, with shared module development.
| Lead Nation: | EU (France - GLPI originated in France) |
| Estimated Cost: | €30-50M over 4 years |
| Cost per Nation: | €8-12M (vs €20-50M/year in ServiceNow each) |
| Timeline: | CMDB/Asset in 12 months; full ITSM in 36 months |
| ROI: | Break-even in Year 3; €80-200M savings by Year 7 |
Project: GovCRM (Salesforce/Dynamics Replacement)
Problem: Citizen relationship management is critical but dominated by US vendors. Government-specific needs (case management, benefits, licensing) poorly served.
Solution: Government-specific CRM built on Odoo/ERPNext with shared modules for common use cases.
| Lead Nation: | Canada (existing Odoo deployments in provinces) |
| Estimated Cost: | €40-60M over 5 years |
| Cost per Nation: | €10-15M |
| Timeline: | Core CRM in 18 months; full suite in 48 months |
| ROI: | Varies by current spend; typically 3-5x over 10 years |
Project: SovereignIdentity (Entra ID/Okta Replacement)
Problem: Identity management increasingly dependent on Microsoft Entra ID (formerly Azure AD) and Okta. Critical infrastructure with US control.
Solution: Coalition deployment of Keycloak/ZITADEL with government-specific federation and citizen identity modules.
| Lead Nation: | EU (Germany - existing government Keycloak expertise) |
| Estimated Cost: | €20-35M over 3 years |
| Cost per Nation: | €5-9M |
| Timeline: | Internal identity in 12 months; citizen identity in 24 months |
| ROI: | Security value exceeds cost; reduces single point of failure |
Coalition Development Governance
| Role | Responsibility | Rotation |
|---|---|---|
| Lead Nation | Hosts development team; sets technical direction; manages releases | Fixed per project (based on expertise) |
| Contributing Nations | Provide developers, funding, requirements; validate for local needs | All non-lead nations |
| Technical Steering Committee | Architecture decisions; roadmap prioritisation; conflict resolution | 1 representative per nation |
| Release Manager | Coordinates releases; manages CI/CD; ensures quality gates | Appointed by Lead Nation |
5. Development Team Leadership
Cloud Services Development Organisation
Platform Engineering Division
Mission: Develop and maintain core sovereign cloud platform services.
| Team | Lead Nation | FTE | Scope |
|---|---|---|---|
| Compute & Containers | EU (France) | 25-40 | Kubernetes, VM orchestration, serverless |
| Storage & Data | UK | 20-30 | Object storage, block storage, backup |
| Networking | EU (Netherlands) | 15-25 | SDN, load balancing, DNS, CDN |
| Security & Identity | UK | 20-30 | IAM, secrets, encryption, HSM |
| Databases | EU (Germany) | 20-30 | PostgreSQL, MySQL, Redis, managed DB services |
| Observability | Australia | 15-20 | Monitoring, logging, tracing, alerting |
| Messaging & Integration | Canada | 15-20 | Kafka, RabbitMQ, API gateway |
Application Services Division
Mission: Develop shared COTS replacement applications.
| Team | Lead Nation | FTE | Product |
|---|---|---|---|
| Enterprise Scheduling | UK | 15-25 | SovereignScheduler (Airflow-based) |
| ITSM | EU (France) | 20-35 | SovereignITSM (GLPI-based) |
| Government CRM | Canada | 25-40 | GovCRM (Odoo-based) |
| Productivity Suite | EU (Germany) | 15-25 | Nextcloud/OnlyOffice integration |
| Identity Platform | EU (Germany) | 15-25 | SovereignIdentity (Keycloak-based) |
Leadership Roles
| Role | Grade Equivalent | Accountability | Reports To |
|---|---|---|---|
| Chief Platform Architect | SCS2 / Director | Overall technical vision; cross-team architecture | Programme Director |
| Division Head | SCS1 / Deputy Director | Division delivery; budget; staffing | Chief Platform Architect |
| Team Lead | G6 / Technical Lead | Team delivery; technical decisions; code quality | Division Head |
| Product Owner | G7 / Senior Product Manager | Roadmap; stakeholder liaison; prioritisation | Division Head |
| Delivery Manager | G7 / Delivery Lead | Sprint delivery; blockers; cross-team coordination | Team Lead |
6. Sovereign CI/CD Pipeline
The development pipeline itself must be sovereign. Dependence on GitHub Actions, Azure DevOps, or AWS CodePipeline creates the same risks we are mitigating in production.
Sovereign CI/CD Stack
| Function | US-Controlled (Avoid) | Sovereign Alternative | Notes |
|---|---|---|---|
| Source Control | GitHub | GitLab CE, Forgejo, Gitea | Self-hosted on sovereign infrastructure |
| CI/CD Engine | GitHub Actions, Azure DevOps | GitLab CI, Jenkins, Woodpecker CI | GitLab CI preferred for integration |
| Container Registry | Docker Hub, ECR, ACR | Harbor, GitLab Registry, Quay | Harbor for enterprise features |
| Artifact Repository | GitHub Packages, AWS CodeArtifact | Nexus, Artifactory (JFrog - IL/US dual) | Nexus OSS for full sovereignty |
| GitOps | - | ArgoCD, Flux | CNCF projects, no US control |
| Infrastructure as Code | Terraform (IBM - US, acquired HashiCorp 2024) | OpenTofu, Pulumi | OpenTofu is the open-source community fork; Pulumi (US) but OSS option |
| Secret Management | GitHub Secrets, AWS Secrets Manager | OpenBao, Infisical | OpenBao is the open-source fork of Vault; self-hosted with sovereign HSM |
| Security Scanning | Snyk (US), GitHub Advanced Security | Trivy, Semgrep, Gitleaks | All open source, self-hosted |
Pipeline Stages
CI/CD Pipeline Stages
COMMIT
- Push/MR
- Forgejo
- GitLab
BUILD
- Compile
- Container
- SBOM
- Sign
TEST
- Unit
- Integration
- E2E
- Performance
SECURITY
- SAST
- DAST
- Deps scan
- Container scan
STAGING
- EU
- UK
- CA
- AU
▼
APPROVAL GATE (Multi-Jurisdiction)
- Technical Review: 2 of 4 jurisdiction tech leads approve
- Security Review: Security Council sign-off for HIGH+ findings
- Change Advisory: CAB approval for production changes
▼
CANARY
- 5% traffic
- 1 hour
- Rollback ready
ROLLOUT
- 25/50/100%
- Auto/Manual
- Per-region
MONITOR
- Error rate
- Latency
- Alerts
COMPLETE
- Announce
- Docs
- Changelog
Quality Gates
| Gate | Threshold | Enforcement |
|---|---|---|
| Code Coverage | ≥80% line coverage | Hard block |
| SAST Findings | 0 CRITICAL, 0 HIGH | Hard block |
| Dependency Vulnerabilities | 0 CRITICAL, 0 HIGH without waiver | Hard block (waiver requires Security Council) |
| Container Scan | 0 CRITICAL in base image | Hard block |
| SBOM Generated | CycloneDX or SPDX format | Hard block |
| Performance Regression | <10% degradation vs baseline | Soft block (exception path) |
| Multi-Jurisdiction Test | Pass in all 4 staging environments | Hard block |
7. Source Control Independence
GitHub is owned by Microsoft (US). All code, issues, wikis, and CI/CD workflows
are subject to US jurisdiction. This creates unacceptable risk for sovereign development.
GitHub Alternatives Comparison
| Platform | Origin | Licence | Self-Host | CI/CD | Recommendation |
|---|---|---|---|---|---|
| GitLab CE | Netherlands (now US HQ) | MIT | Yes | Built-in | Primary choice |
| Forgejo | EU community fork | MIT | Yes | Woodpecker CI | Lightweight option |
| Gitea | China origin, global | MIT | Yes | External | Acceptable |
| GitHub Enterprise | USA (Microsoft) | Proprietary | Yes | Built-in | Not recommended |
| Azure DevOps | USA (Microsoft) | Proprietary | Server option | Built-in | Not recommended |
Migration from GitHub
GitHub → GitLab/Forgejo Migration Checklist
- Repository Migration
- Export repositories with full history (git clone --mirror)
- Migrate LFS objects separately
- Update remote URLs in all developer machines
- Issues and PRs
- Use GitLab importer for issues/MRs (built-in)
- Manually migrate open PRs that need continuation
- Archive closed issues for reference
- CI/CD Workflows
- Convert .github/workflows/*.yml → .gitlab-ci.yml
- Replace GitHub Actions with GitLab CI equivalents
- Migrate secrets to GitLab CI/CD variables or OpenBao
- Integrations
- Update webhooks for external services
- Reconfigure deployment keys
- Update documentation references
- Team Onboarding
- Training on GitLab/Forgejo differences
- Update developer documentation
- Parallel running period (2-4 weeks)
Forking Upstream Open Source Projects
Critical open source dependencies hosted on GitHub should be forked to sovereign infrastructure to ensure continuity if GitHub access is restricted.
Fork Governance Framework
| Category | Examples | Fork Strategy |
|---|---|---|
| Critical Infrastructure | Kubernetes, PostgreSQL, Linux kernel | Mirror fork; sync daily; test sovereign build |
| Platform Components | CloudStack, MinIO, Keycloak | Mirror fork; sync weekly; sovereign customisations branch |
| Development Tools | ArgoCD, Trivy, OpenTofu | Mirror fork; sync weekly |
| Libraries/Dependencies | Common npm/pip/maven packages | Cache in sovereign Nexus; snapshot critical versions |
Fork Maintenance Process
- Automated Sync: CI job pulls upstream changes on schedule
- Conflict Resolution: Sovereign customisations rebased onto upstream
- Security Patches: Cherry-pick critical patches immediately
- Testing: Sovereign CI runs full test suite on each sync
- Upstream Contribution: Submit improvements back to upstream where possible
Package Registry Independence
Development also depends on package registries (npm, PyPI, Maven Central, Docker Hub). These should be mirrored to sovereign infrastructure.
| Registry | Risk | Sovereign Mirror |
|---|---|---|
| npm (npmjs.com) | US-operated; package removal possible | Nexus Repository npm proxy + hosted |
| PyPI (pypi.org) | US-operated (PSF) | Nexus Repository PyPI proxy + hosted |
| Maven Central | US-operated (Sonatype) | Nexus Repository Maven proxy |
| Docker Hub | US-operated; rate limits; removal | Harbor registry with proxy cache |
| GitHub Container Registry | Microsoft-operated | Harbor registry (full mirror) |