Common Framework

Migration Strategy

Patterns for phased, risk-based migration including workload prioritisation, data migration approaches, and cutover planning.

Strategic Approach

Migration is not a "big bang" event. A phased approach reduces risk, builds capability, and allows course correction. The strategy prioritises workloads by sovereignty risk and migration complexity to achieve early wins while building toward complete US cloud exit.

The 6 Rs of Migration

Each workload should be assessed against these migration patterns:

Pattern Description When to Use
Rehost (Lift & Shift) Move as-is to sovereign infrastructure Simple workloads, VMs, urgent timelines
Replatform (Lift & Optimise) Minor modifications for new platform Database swaps, containerisation
Refactor (Re-architect) Significant redesign for cloud-native Performance needs, legacy modernisation
Repurchase (Replace) Move to different (sovereign) product SaaS replacement, commercial off-shelf
Retain Keep on current platform (temporarily) Deep dependencies, decommission planned
Retire Decommission entirely Redundant systems, end-of-life

Workload Prioritisation

Prioritisation Matrix

Workloads are assessed on two dimensions: Sovereignty Risk (how dangerous is US control of this workload?) and Migration Complexity (how difficult is migration?).

Workload Prioritisation Matrix
SOVEREIGNTY RISK
HIGH
QUADRANT 2: Complex but Critical

Defence systems, legacy critical infrastructure. Plan carefully, migrate with extra resources.

QUADRANT 1: HIGHEST PRIORITY

Citizen data, policy systems, ministerial. Migrate first - high risk, achievable complexity.

QUADRANT 4: Lowest Priority

Public websites, legacy admin. Plan for last, may retire instead.

QUADRANT 3: Quick Wins

Internal admin, dev/test. Build capability, validate platform.

LOW
MIGRATION COMPLEXITY (LOW → HIGH)

Sovereignty Risk Assessment Criteria

Risk Level Criteria Examples
Critical National security, intelligence, diplomatic, or classified data Defence logistics, intelligence analysis, diplomatic communications
High Sensitive citizen data, policy development, economic data Healthcare records, tax systems, benefits, ministerial papers
Medium Internal government operations, non-sensitive services HR systems, internal collaboration, procurement
Low Publicly available information, non-citizen-facing Public websites, open data portals, marketing

Migration Complexity Assessment

Complexity Characteristics
Low Containerised, stateless, standard APIs, well-documented, modern architecture
Medium Some proprietary dependencies, requires replatforming, moderate data migration
High Deep vendor lock-in, legacy technology, complex integrations, large data volumes

Migration Waves

Wave 0: Pilot (Months 1-12)

Objective: Prove the platform and build capability

  • 2-3 low-risk, volunteer workloads
  • Development/test environments
  • Internal tools (not citizen-facing)
  • New greenfield projects

Success criteria: Workloads running stable, team trained, processes documented

Wave 1: High-Risk/Low-Complexity (Months 12-30)

Objective: Reduce greatest sovereignty risk quickly

  • Citizen data systems (health, benefits, tax)
  • Policy and ministerial document systems
  • Cross-government shared services
  • Cloud-native applications on US providers

Success criteria: Most sensitive data on sovereign platform, 40-50% spend reduction

Wave 2: Remaining Portfolio (Months 30-54)

Objective: Complete the migration

  • Legacy system modernisation
  • Complex integrations
  • Department-by-department transitions
  • Lower priority workloads

Success criteria: 95%+ workloads migrated, US dependency minimal

Wave 3: Exit (Months 54-72)

Objective: Complete US cloud exit

  • Final workload migration
  • Contract termination
  • Data deletion verification
  • Account closure

Success criteria: Zero US cloud dependency

Data Migration Patterns

Database Migration

Pattern Approach Downtime Complexity
Dump & Restore Export, transfer, import Hours to days Low
Logical Replication Continuous sync, cutover Minutes Medium
Change Data Capture Stream changes via Debezium/Kafka Seconds High
Dual-Write Write to both, verify, cutover Zero High

Object Storage Migration

Pattern Tools Notes
Sync Tools rclone, s3cmd, MinIO mc S3-compatible, handles incremental
Batch Transfer AWS DataSync, custom scripts Large volumes, scheduled windows
Live Sync Bucket replication, event triggers Continuous, near-zero RPO

Data Validation

All data migrations must include:

Cutover Planning

Cutover Types

Type Description Risk Best For
Big Bang Switch all traffic at once High Simple systems, acceptable downtime
Blue-Green Two environments, instant switch Medium Stateless applications
Canary Gradual traffic shift (1%, 10%, 50%, 100%) Low High-traffic, critical services
Strangler Fig Gradually replace components Low Monoliths, legacy systems

Cutover Checklist

Risk Mitigation During Migration

Parallel Running

Critical workloads should run in parallel on both platforms during transition:

  • Maintain source system capability throughout migration
  • Sync data continuously or at defined intervals
  • Test sovereign platform under real load (shadow traffic)
  • Enable instant rollback if issues discovered
  • Gradual cutover reduces blast radius of failures

Rollback Planning

Every migration must have a documented rollback plan:

  • Criteria: Specific metrics that trigger rollback
  • Procedure: Step-by-step rollback process
  • Data handling: How to sync data written to new platform back to source
  • Timeline: Maximum time for rollback decision
  • Testing: Rollback procedure tested before cutover
Back to Reference Architecture
Continue to Supplier Consortium