Cloud Migration

Retire       — Decommission. 10-20% of portfolios are redundant or unused.
               Identify by usage analytics; avoid migrating what you'll delete.

Retain        — Keep on-premises for now. Regulatory, latency, or cost reasons.
               Revisit in 12-24 months. Don't migrate everything at once.

Rehost        — "Lift and Shift". Move the VM or container as-is to EC2 or ECS.
               Fastest migration path. Little or no code changes.
               Good for: legacy apps with stable workloads, tight deadlines.
               Risk: you keep old costs patterns; no cloud-native benefits yet.

Replatform    — "Lift, Tinker, and Shift". Small optimisations without redesign.
               Examples: RDS instead of self-managed MySQL on EC2;
                         S3 for file storage instead of local disk;
                         ECS/Fargate instead of running Docker on EC2 yourself.
               Good for: getting partial cloud-native benefits quickly.

Repurchase    — Replace with a SaaS product.
               Examples: Salesforce, ServiceNow, Workday, Shopify.
               Good for: commodity functions not worth migrating (HR, CRM).

Re-architect  — Redesign for the cloud. Microservices, serverless, managed services.
               Highest effort. Highest long-term ROI.
               Good for: competitive differentiators, high-growth workloads.
               Risk: underestimate complexity; budget for 2-3× the estimate.

Low business value + easy to migrate    → Retire or Rehost (populate cloud footprint)
Low business value + hard to migrate    → Retain until natural end-of-life
High business value + easy to migrate   → Replatform (quick wins with cloud benefits)
High business value + hard to migrate   → Re-architect (invest in the right foundations)

Start with Rehost to build capability, then Re-architect as the team matures.
Never start with Re-architect for a large portfolio — too risky.

Migrate in waves of 10-30 workloads, not all at once.

Wave 0: Foundation
  - Landing zone (AWS Control Tower)
  - Networking (Transit Gateway, VPN/Direct Connect)
  - Security baseline (SCPs, GuardDuty, CloudTrail)
  - Identity federation (IAM Identity Center)
  - Cost governance (AWS Budgets, tagging SCP)

Wave 1: Low-risk pilots
  - Non-production workloads, dev environments
  - Simple stateless apps
  - Build team confidence and runbooks
  - Validate networking, IAM, and tooling

Wave 2: Business-critical secondary systems
  - Reporting, analytics, batch jobs
  - May have some state (RDS migrations with DMS)

Wave 3: Revenue-critical systems
  - eCommerce, payments, APIs
  - Blue-green switchover, DNS cutover, rollback plan rehearsed

Wave 4: Complex legacy (if re-architecting)
  - Monolith decomposition, mainframe offload
  - Runs in parallel with Wave 3 delivery

Between each wave: retrospective, cost review, security assessment.

# Migration Hub tracks all migrations in one place — discovery → migration → tracking

# 1. Discovery: AWS Application Discovery Service
aws discovery start-data-collection-by-agent-ids --agent-ids agent-1234

# 2. Import discovered servers into Migration Hub
aws migrationhub import-migration-task \
  --progress-update-stream "MyMigrationStream" \
  --migration-task-name "web-server-01"

# 3. Update task status as you progress
aws migrationhub notify-migration-task-state \
  --progress-update-stream "MyMigrationStream" \
  --migration-task-name "web-server-01" \
  --task '{"Status":"IN_PROGRESS","ProgressPercent":50,"StatusDetail":"Replicating data"}'

# 4. Mark complete
aws migrationhub notify-migration-task-state \
  --progress-update-stream "MyMigrationStream" \
  --migration-task-name "web-server-01" \
  --task '{"Status":"COMPLETED"}'

# AWS Database Migration Service — continuous replication until cutover

# Typical pattern for zero-downtime DB migration:
#   1. DMS full load: copies existing data to target (hours/days for large DBs)
#   2. DMS CDC: change data capture keeps target in sync with source in real-time
#   3. Validation: DMS data validator confirms row counts and checksums
#   4. Cutover window: stop writes to source, wait for CDC to catch up, cut DNS
#   5. Rollback: DMS can replicate back to source if needed

import boto3

dms = boto3.client("dms", region_name="eu-west-1")

# Create replication task
task = dms.create_replication_task(
    ReplicationTaskIdentifier="postgres-to-aurora",
    SourceEndpointArn="arn:aws:dms:eu-west-1:123:endpoint:SOURCE",
    TargetEndpointArn="arn:aws:dms:eu-west-1:123:endpoint:TARGET",
    ReplicationInstanceArn="arn:aws:dms:eu-west-1:123:rep:instance",
    MigrationType="full-load-and-cdc",   # full load then change capture
    TableMappings='{"rules": [{"rule-type": "selection", "rule-id": "1", '
                  '"rule-name": "select-all", "object-locator": '
                  '{"schema-name": "public", "table-name": "%"}, "rule-action": "include"}]}',
    ReplicationTaskSettings='{"TargetMetadata":{"TargetSchema":"public"},'
                            '"FullLoadSettings":{"TargetTablePrepMode":"DROP_AND_CREATE"}}',
)

# Start task
dms.start_replication_task(
    ReplicationTaskArn=task["ReplicationTask"]["ReplicationTaskArn"],
    StartReplicationTaskType="start-replication",
)

# Migration Runbook: [Service Name]

## Pre-migration Checklist
- [ ] Stakeholder sign-off obtained
- [ ] Rollback procedure rehearsed
- [ ] Monitoring dashboards created for target environment
- [ ] Support team briefed
- [ ] Maintenance window communicated

## Cutover Steps
| Step | Action | Owner | Duration | Rollback Trigger |
|------|--------|-------|----------|-----------------|
| 1    | Enable maintenance mode | SRE | 2 min | Any step fails |
| 2    | Stop writes to source DB | DBA | 1 min | DMS lag > 0 after 5 min |
| 3    | Wait for DMS CDC lag = 0 | DBA | 0-5 min | Lag non-zero after 10 min |
| 4    | Cut DNS to new endpoint | SRE | 2 min | Error rate > 1% |
| 5    | Verify health checks green | SRE | 5 min | Health check fails |
| 6    | Disable maintenance mode | SRE | 1 min | N/A |
| 7    | Monitor for 30 minutes | SRE | 30 min | Error rate > 0.1% |

## Rollback Procedure
1. Enable maintenance mode on new endpoint
2. Cut DNS back to source endpoint (TTL was already lowered to 60s)
3. Verify health checks on source are green
4. Disable maintenance mode
5. Post-mortem within 24h