AWS Migration Readiness Checklist

Why readiness matters more than speed

Most migrations that go over budget or stall do so for reasons that were visible before the first server moved: an unclear application inventory, an undefined landing zone, or a team that has never operated infrastructure as code. This checklist helps you surface those gaps early, while they are still cheap to fix.

Work through each section honestly. If you cannot answer a question with evidence, treat it as a risk to close before migration — not a detail to figure out later.

1. Business case and scope

• You have a written reason for migrating (cost, resilience, scale, end-of-life hardware, or acquisition) and it is agreed by both IT and finance.
• You have defined what is in scope for the first wave versus later waves.
• You have a rough total cost of ownership comparison between staying put and moving.
• An executive sponsor owns the outcome, not just the project.

2. Application and dependency inventory

A migration is only as good as the inventory underneath it. Unknown dependencies are the single most common cause of cutover failures.

• Every application in scope is catalogued with its owner, criticality, and data classification.
• Upstream and downstream dependencies (databases, message queues, third-party APIs, file shares) are mapped.
• You have identified which applications are candidates for rehost, replatform, refactor, or retire.
• Licensing constraints (e.g. per-core database licences) are documented.

Choosing a migration strategy per app

Do not refactor everything at once. Rehost first where it is safe, then optimise.

3. Landing zone and security baseline

• A multi-account structure is planned (separate accounts for production, non-production, and shared services).
• Identity is centralised (single sign-on, no long-lived root or IAM user keys).
• Network design is agreed: VPC layout, subnets, connectivity back to on-premises, and egress control.
• Guardrails are defined for encryption at rest and in transit, logging, and config drift.
• A baseline for tagging is set so cost and ownership can be tracked from day one.

4. Operations and skills

• Your team can provision infrastructure as code rather than clicking in the console.
• Monitoring, alerting, and on-call responsibilities for the new environment are defined.
• Backup and patching responsibilities are clear — managed services shift, but do not remove, this work.
• There is a plan to upskill the existing team, not just hire around them.

5. Data migration and cutover

• Data volumes and acceptable downtime windows are known for each workload.
• A migration mechanism is chosen per data store (replication, snapshot, or database migration tooling).
• Rollback criteria are written down before cutover, not improvised during it.
• A representative dataset has been used to rehearse at least one full cutover.

6. Cost control from day one

• Budgets and alerts are configured before workloads land.
• You understand the difference between on-demand and committed pricing for your steady-state usage.
• Non-production environments have a plan to shut down outside working hours.
• Someone owns a recurring cost review, not just the migration team during the project.

How to score yourself

Count the boxes you can tick with evidence today.

• Below 60%: You are not ready to migrate at scale. Run a discovery phase first.
• 60–85%: You can begin a small, low-risk pilot wave while closing the remaining gaps.
• Above 85%: You are ready to plan a phased migration with confidence.

A migration is a programme of work, not a weekend project. The teams that succeed treat readiness as the first deliverable — and revisit this checklist at the start of every wave.