cutover-control-plane

AWS Migration: Cutover (Control Plane)

This skill produces the runbook for creating the empty target shape. No data moves here. The output is what the operator (or the cutover-executor) runs to provision the target account so that the data-plane runbook has a destination to copy into.

When to use this skill

• After migration-planner (reads migration-plan.json)
• Before cutover-data-plane (the data-plane runbook depends on this completing)
• Re-run if the migration-plan changes

Prerequisites

• migration-plan.json, resource-ownership.json, dependency-graph.json, hardcoded-values.json exist
• terraform/ modules generated by terraform-generator exist with terraform validate clean

Inputs

Input	Source	Required
migration-plan.json	migration-planner	yes
resource-ownership.json	inventory	yes
dependency-graph.json	dependency-analyzer	yes
hardcoded-values.json	dependency-analyzer	yes
terraform/ modules	terraform-generator	yes

Outputs

• cutover-checklist-control-plane.md — printable runbook for the operator
• cutover-checklist-control-plane.json — validates against schemas/cutover-checklist-control-plane.schema.json. Consumed by the cutover-executor.

Phase structure (always 7 phases, numbered 0–6)

Phase 0 — Globals

Account-global resources that exist once, not per-region:

• IAM roles, policies, OIDC providers, SAML providers (terraform apply iam/)
• Route53 hosted zone (records NOT yet changed — that's Phase 5 + data-plane)
• CloudFront distributions
• AWS Backup vaults
• ACM certificates (validation in target)

Operator IAM during this phase: target-cutover-control-plane.json only.

Phase 1 — Networking

VPCs, subnets, NAT gateways, security groups, NACLs, route tables, TGW attachments, VPC peering bridges back to source (for cross-account data plane), VPC endpoints.

terraform apply networking/. One module apply, one operator approval (Terraform's own plan UI), no further per-resource gating in this phase.

Phase 2 — Storage Containers

Empty resource containers, no data:

• S3 buckets (with versioning + replication config, no objects yet)
• EFS / FSx file systems (empty)
• EBS volumes (empty, just allocated)
• KMS keys for storage encryption (so that data-plane snapshot-restore has a target key ready)

terraform apply storage/. The actual data movement is the data-plane runbook's job.

Phase 3 — Database Containers

The structural pieces databases need:

• DB subnet groups
• Parameter groups
• Option groups
• Security groups for DB access
• KMS keys for DB encryption
• Empty RDS instances IF the strategy is DMS continuous replication (DMS needs a target to write into)
• For snapshot-restore strategies: no empty instance — the restore creates the instance

terraform apply databases/. Check data-migration-plan.json to know which databases need an empty container created vs which will appear via restore.

Phase 4 — Compute Containers

• Launch templates, ASGs (desired_capacity=0 until data-plane is done)
• Lambda function metadata (no code uploaded yet — that's data-plane)
• ECS task definitions, services with desired_count=0
• EKS clusters, node groups
• IAM instance profiles, Lambda execution roles
• ECR repositories (empty)

terraform apply compute/.

Phase 5 — DNS Scaffolding

NOT actual record changes — the records still point at source. This phase creates the scaffolding needed for the eventual cutover:

• ALB / NLB in target (so target ALB ARN exists for health checks)
• Route53 health checks against target endpoints
• Reduce TTL to 60s on all public records (24h before cutover ideally)
• Pre-stage the Route53 change-batch JSON files that the data-plane runbook will apply

The actual DNS swap is in the data-plane runbook (Phase 4 there).

Phase 6 — Control Plane Validation

Before handing off to data plane:

• terraform plan against every module shows no drift
• IAM trust policies validate against iam:simulate-principal-policy
• All Phase 0–4 resources visible in aws ... describe-*
• Resource-counts match expectation per module's .generation-report.md
• Cost watchdog: 24h of target steady-state is on track

Handoff to data plane

The control-plane runbook ends with a handoff_to_data_plane.criteria[] list. All criteria must be checked before the operator starts /aws-migration-architect:execute on the data-plane checklist. Example criteria:

• All target buckets created, with correct policy and KMS key
• All target VPCs visible with expected CIDR
• IAM roles exist in target with correct trust
• KMS keys ready for cross-account grants (data-plane will create the grants)
• DNS health checks green against target endpoints

Standard scaffolding per phase

Every phase gets these standard items:

Pre:

• aws sts get-caller-identity --profile $MIGRATION_TARGET_PROFILE succeeds
• terraform plan -target=module.<mod> reviewed
• Rollback procedure printed (terraform state rm + terraform apply -refresh-only on source-only resources)

During:

• terraform apply runs cleanly (or AWS CLI commands for non-Terraform control-plane operations)
• Operator records the Terraform state file location post-apply

Post:

• Resources visible via aws ... describe-*
• CloudWatch alarms armed in target

Per-team approval gates

For each phase where any resource has owner_team set in migration-plan.json, inject an approval gate at phase boundary:

> ⚠ Approval required from **<team>** before Phase N begins
> Sign-off: ________________________________

What this skill does NOT include

• Any data movement (snapshot share, sync, DMS) — those are in the data-plane runbook
• DNS record changes that affect traffic — Phase 5 here only scaffolds; the swap is data-plane
• Any operation that requires target-cutover-data-plane.json IAM

Anti-patterns — DO NOT

• Do not include aws s3 sync, aws rds restore-db-instance-from-db-snapshot, aws datasync ..., aws dms ... — those are data-plane.
• Do not include aws route53 change-resource-record-sets for production records — that's data-plane's traffic shift.
• Do not include freeze-write operations — those belong to data-plane Phase 4.
• Do not assume the target is empty when starting — the operator may have re-run; check state before applying.

Sub-agent

Calls cutover-control-plane-builder to render the per-phase steps from migration-plan.json.