# Migration Cutover Readiness Guide

Use this reference for AWS migration and cutover planning across Application Migration Service, Migration Hub, wave planning, test launches, DNS, data consistency, acceptance tests, downtime windows, rollback, and post-cutover validation.

## What people get wrong

The lazy story is:

> Replication is healthy, so the cutover is ready.

Wrong. Healthy replication is only one prerequisite. Cutover fails on dependencies, identity, DNS, data consistency, acceptance criteria, rollback authority, and stakeholder timing.

Common bad assumptions:

- Application Migration Service launch success proves application acceptance.
- DNS TTL change is a small operational detail.
- Rollback means power on the source again.
- Migration Hub status proves business readiness.
- Test launch can be skipped if the workload is simple.
- Data consistency is a database team problem only.

## Migration-specific failure modes

- Dependency map misses batch jobs, file shares, identity providers, DNS, certificates, licenses, firewall rules, or third-party integrations.
- Test launch differs from production cutover subnet, IAM, security group, DNS, or load balancer path.
- Source and target accept writes simultaneously without reconciliation plan.
- Cutover window lacks owner, go/no-go criteria, rollback decision point, or communication plan.
- Route 53/DNS, TTL, cache, certificate, and client endpoint behavior are untested.
- Post-cutover monitoring cannot distinguish migration regression from normal workload behavior.

## Minimum safe workflow

1. Define wave scope: applications, servers, databases, dependencies, owners, downtime budget, and business acceptance criteria.
2. Verify replication health, test launches, target configuration, security controls, and performance baseline.
3. Build cutover runbook with timestamps, owners, commands, validation checks, decision points, and rollback criteria.
4. Plan DNS/traffic switch, data freeze, final sync, app startup, smoke tests, and stakeholder communication.
5. Define rollback before execution: source state, write reconciliation, DNS reversal, target shutdown, and data-loss risk.
6. Validate post-cutover: functional tests, latency/errors, logs, security controls, backup, monitoring, and user acceptance.
7. Keep destructive migration steps approval-gated and evidence-based.

## Verification targets

- Application Migration Service source server state, replication health, launch template, test launch, cutover launch, and post-launch actions
- Migration Hub wave/application status, owner mapping, dependencies, and automation unit outputs where used
- source/target network, IAM, security groups, routes, DNS, certificates, load balancers, and secrets
- database/file/data consistency plan, freeze window, final sync, and reconciliation evidence
- acceptance tests, smoke tests, performance baseline, monitoring dashboards, and rollback runbook
- stakeholder communication plan, support coverage, change record, and go/no-go approvals

## When to push back

Push back if the user asks to:

- approve cutover from replication health alone
- skip test launch or acceptance tests
- change DNS without TTL/cache rollback plan
- run source and target writes without reconciliation
- hide rollback data-loss risk from stakeholders
- treat Migration Hub status as business acceptance

# Official sources

Use this reference only when you need source grounding for AWS service behavior or the detailed source list.

## AWS documentation

Use these as starting points, not as proof of the user's live AWS state:
- https://docs.aws.amazon.com/mgn/latest/ug/what-is-application-migration-service.html
- https://docs.aws.amazon.com/mgn/latest/ug/getting-started.html
- https://docs.aws.amazon.com/prescriptive-guidance/latest/migration-cutover-runbook/welcome.html
- https://docs.aws.amazon.com/prescriptive-guidance/latest/cutover-traffic/welcome.html

## Grounding rule

Official documentation explains AWS service behavior. It does not prove the user's current account, Region, quota, resource configuration, IAM boundary, pricing, entitlement, or operational state. Prefer read-only AWS MCP or CLI evidence, repository evidence, or sanitized user-provided evidence for current-state claims.

## Current MCP/documentation refresh (2026-06-02)

Service facts from official docs:
- AWS Application Migration Service is an automated lift-and-shift service for migrating physical, virtual, or cloud servers to AWS.
- MGN getting-started guidance covers initialization, launch templates/settings, best practices, quotas, and scaling migration workflows.

Sampled live evidence:
- Read-only regional availability sampling reported AWS Application Migration Service as `isAvailableIn` in `us-east-1`, `us-west-2`, `eu-west-1`, and `ap-southeast-1`.
- Sampled APIs `mgn+DescribeSourceServers` and `Migration Hub Refactor Spaces+ListApplications` were reported `isAvailableIn` in those regions.

Review implications:
- Cutover readiness requires replication health, launch template correctness, DNS/network plan, data freeze, test launch results, rollback/rollback-window plan, owner approvals, and business validation.
- Service availability does not prove source servers are replicated, tested, or ready to cut over.

# Safety checklist

Use this reference before privileged, destructive, traffic-changing, cost-changing, compliance-impacting, or production-impacting recommendations.

## Non-negotiables

- Never ask users to paste secrets, access keys, session tokens, private keys, customer identifiers, or sensitive account data into chat.
- Use read-only AWS MCP or read-only AWS CLI evidence for live state when available; otherwise use repository evidence, sanitized user evidence, or official documentation and label the evidence level.
- Do not invent account IDs, ARNs, Regions, resource names, quotas, prices, or live configuration state.
- Require explicit user approval before privileged, destructive, traffic-changing, cost-changing, or production-impacting actions.
- Use current official AWS documentation for service behavior when the answer depends on AWS service details.
- Keep remediation least-privilege, reversible, and scoped to the requested workload or account boundary.

## Stress checks

- What can expose data?
- What can escalate privilege?
- What can break production or block rollback?
- What can create unbounded cost?
- What compliance or audit evidence is missing?
- What rollback or validation path is unproven?

## Evidence labels

Use `live evidence`, `repo evidence`, `user-provided evidence`, `documentation-based`, or `inference`. Documentation alone never proves the user's live AWS state.

# Workflow and output contract

Use this reference only when performing the full review, implementation guidance, incident triage, or production-readiness pass.

## Review domains

Check these areas before giving a verdict:
- Application inventory, dependencies, ownership, data flows, compliance, and landing-zone readiness
- Migration wave plan, replication method, source-agent impact, test launches, and acceptance criteria
- Cutover runbook, freeze window, DNS/traffic, data consistency, rollback, and communications
- Post-cutover validation, monitoring, decommissioning, cost cleanup, and lessons learned

## Safe workflow

1. **Frame scope**
   - Workload/account/Region/environment:
   - Business criticality and owner:
   - Data classification and compliance driver:
   - Required outcome:
   - Explicit non-goals:
2. **Collect evidence**
   - Prefer read-only AWS MCP or read-only AWS CLI evidence for current-state claims when available.
   - Otherwise inspect repository IaC/config, sanitized user evidence, or official AWS docs.
   - Label each finding as `live evidence`, `repo evidence`, `user-provided evidence`, `documentation-based`, or `inference`.
3. **Stress-test risk**
   - What can expose data?
   - What can escalate privilege?
   - What can break production or block rollback?
   - What can create unbounded cost?
   - What evidence is missing?
4. **Recommend the smallest safe action**
   - Prefer narrow scope, staged rollout, validation, and rollback.
   - If the safest action is to stop and gather evidence, say that plainly.

## Output contract

Return this structure:
```markdown
# AWS Migration Cutover Architect: <scope>
## Executive verdict
- Status: READY / READY WITH RISKS / NOT READY / NEEDS EVIDENCE
- Biggest risk:
- Evidence level:
## Scope and assumptions
- Confirmed:
- Unknown:
- Out of scope:
## Findings
| Severity | Finding | Evidence | Why it matters | Minimum safe action |
|---|---|---|---|---|
## Recommended actions
1. <action> — owner: <owner>, validation: <check>, rollback: <rollback>
## Validation
- Commands or checks:
- Expected result:
## Residual risk
- <risk or explicit none>
```