A migration readiness assessment is a written inventory of dependencies, landing-zone gaps, data gravity and cutover risk, completed before you copy the first production datastore. It is not a wave plan based on a CMDB export alone. Confirm identity, logging, network and accounts exist in the target provider. Map every inbound and outbound dependency, including license servers and SaaS allow lists. State RTO for the cutover window and a rollback that does not assume the source is already decommissioned. Documentation dated 2026-08-30 is the cloud-product source. Readiness is a decision to migrate, wait or stay.

The checklist form of this work is the cloud migration assessment checklist. Scoped help is cloud migration assessment. The foundation you migrate into is a landing zone.

Assumptions

  • You have, or can get, source inventory plus the target organization’s landing-zone tree.
  • The target is AWS, Azure or Google Cloud. Alibaba Cloud is not covered here.
  • This is a readiness decision, not a wave plan or a cutover runbook.
  • You will not copy the first production datastore until identity, logging, network and accounts exist in the target.

What ready means

Ready means the target landing zone can accept the workload: accounts or subscriptions, IAM, hub network, log sinks and the SKUs you intend to use in the chosen region. AWS Control Tower, Azure landing zones and Google Cloud’s landing-zone series all treat this as a prerequisite, not a parallel workstream you finish after the first VM lands.

Ready also means you can name:

  • The source of truth for inventory (discovery tool plus interviews, not only the CMDB)
  • Data that cannot leave a country or a network
  • The cutover mechanism (rehost, replatform, rewrite) per application, not for the whole estate
  • Who pages if DNS flips and the old VPN is the only path back

If those answers are missing, the assessment result is “not ready,” which is a valid outcome.

Inventory that includes packets, not only servers

Discovery agents and export tools list hosts and processes. They miss DNS names that only exist in a desktop hosts file, and they miss the nightly file drop to a partner. Add flow logs, firewall rules and interview notes.

On a source vSphere or on-premises Linux estate you can at least list listening ports and established connections:

ss -lntup
ss -antp | awk 'NR==1 || /ESTAB/'

Interpret ESTAB rows as live dependencies. A process listening on 0.0.0.0:5432 with connections from three app subnets is a database you will migrate or you will break those apps. A listening port with no established clients for a week still might be the monthly batch. Mark it unknown, do not delete it from the plan.

In AWS after a pilot landing, aws ec2 describe-instances and VPC Flow Logs play the same role for the next wave. In Azure, az vm list plus NSG flow logs. In Google Cloud, gcloud compute instances list plus VPC Flow Logs.

Landing-zone gaps that block a wave

Use the production checklist in Designing a production landing zone and the account split in multi-account and multi-subscription structure. Common blockers:

  • No organization or management group, so every migrated account is a snowflake
  • No hub, so every rehosted VM gets a public IP
  • No identity federation, so operators create IAM users to “just get in”
  • Target region missing the database SKU or the GPU family you assumed

Google Cloud’s landing-zone guidance says you can add on-premises connectivity later if the first workload does not need it. That is true only if the first workload truly has no hybrid dependency. Most production estates do.

Data gravity and the cutover window

The largest store sets the clock. A 20 TiB database with a 200 Mbps path is a weekend you can calculate. A store you have not sized is an open risk. Replication egress during dual-run is a cost line. See egress cost planning.

Rehost (lift and shift) preserves unknown dependencies and usually preserves unknown cost. Replatform (managed database, managed queue) removes some of those dependencies and creates new ones (parameter groups, auth, extension lists). Rewrite is a product project wearing a migration badge. The assessment should say which one you are doing per app.

Rollback: keep the source writable or keep a reverse replica until you pass the defined soak. DNS TTL and client connection pools decide whether rollback is minutes or days. Practice the flip in DNS routing failure.

Risks and limitations

Discovery coverage is never 100%. Write residual unknown dependencies on the risk register with an owner.

Provider migration programs and partner tools help copy disks. They do not create your OU tree or your SCP set.

Licensing (Windows, Oracle, VMware) can make a technically ready wave commercially not ready. That is in scope for readiness even though it is not a VPC setting.

This site does not run your cutover. The assessment deliverable is findings, a dependency map and a risk register, as described on cloud migration assessment.

Official sources