AWS Cloud Migration Readiness Assessment: The 47-Point Checklist for MAP and Your Business Case

As of July 19, 2026, AWS Migration Hub remains closed to new customers as of November 7, 2025—net-new programs should anchor on AWS Transform, Application Migration Service (MGN), and MAP, not legacy hub onboarding. CAF 3.0 still frames organizational capabilities; your CFO funds waves with evidence.

This checklist is the 47-control readiness gate we attach to Assess → Mobilize: People (10), Platform (12), Security (13), FinOps (12). It complements CAF in practice, MAP funding, and migration cost surprises.

Composite program pattern (benchmark) — Recurring mid-market silhouette in our reviews: 60–180 VMs, VMware or mixed hypervisor, “engineering knows the dependencies,” 4–8 week parallel-run assumption, NAT-heavy egress, MAP tags defined after first invoice. Programs that pass Mobilize with ≤3 Security/Platform fails typically spend ~120–160 engineer-hours on Assess evidence; programs that skip discovery spend that again during firefighting.

Why Assess artifacts matter more than slides

MAP Assess expects a defensible business case and migration plan. Auditors and AWS reviewers look for:

1. Discovery inventory with owners (not just server names).
2. TCO with parallel-run and data transfer line items.
3. Wave plan with 7 Rs classification per workload (migration strategy guide).
4. Risk register with rollback criteria.

The checklist below is how you prove those exist before replication agents touch production subnets.

The four pillars (summary)

People (10 controls)

Fails here mean cutover without on-call ownership or FinOps sign-off. Minimum bar: P1 executive sponsor, P4 skills plan, P10 FinOps liaison.

Platform (12 controls)

Fails here mean you will migrate into a heroic account. Minimum bar: PL1 Organizations, PL4 network topology, PL7 tooling path (MGN/DMS/Transform), PL10 central logging.

Security (13 controls)

Fails here mean audit findings post-cutover. Minimum bar: S1 SCPs, S3 Security Hub or documented deferral with risk acceptance, S13 org CloudTrail. Pair with cloud compliance services when scope spans HIPAA, PCI DSS, or SOC 2 alongside the cutover.

FinOps (12 controls)

Fails here mean surprise invoices. Minimum bar: F1 tag policy, F5 parallel-run budget, F6 data transfer model, F9 MAP tags if pursuing credits. Programs without dedicated FinOps capacity often partner with FinOps consulting through the parallel-run window so the invoice surprise lands on a dashboard, not a board slide.

Full tables with evidence columns: copy from the artifact (link below).

MAP gate: when Mobilize may start

Rule we use: ≤5 Fail across Platform + Security combined, zero Fail on P1 (sponsor) and F5 (parallel-run budget).

Sample deliverables (what “Pass” looks like)

1. Discovery — CSV or Transform export: app name, owner, RTO/RPO, dependencies, data class.
2. TCO — 36-month model with NAT, cross-AZ, licensing, and weeks of dual-run explicit.
3. Wave 0 — Landing zone + tagging + logging only (no app cutover).
4. Runbook — Cutover + rollback + communications template.

What broke when readiness was skipped

What broke — A B2B SaaS portfolio (~95 VMs, US-only, SOC 2 on roadmap) started MGN replication before Organizations SCPs or centralized logging. Cutover week 3: member account disabled Config to “speed up” deploys; Security Hub went FAILED on 38 controls; finance could not allocate spend because Environment tags were optional. Program paused 11 weeks for Control Tower retrofit under live traffic—roughly 2× the calendar time a Wave 0 would have consumed (their program post-mortem, shared with permission as anonymized pattern).

When lift-and-shift readiness is enough vs not

Enough: regulatory window mandates datacenter exit; apps are ISV binaries you cannot refactor pre-cutover; discovery is complete.

Not enough: collations change, you need app-level changes for cloud networking, or data gravity requires refactor-first (7 Rs).

What to do this week

1. Copy the 47-row checklist into your program wiki.
2. Mark Pass/Fail with ticket links—no oral “we’re fine.”
3. Block Mobilize if Platform + Security fails exceed threshold.
4. Schedule Migration Lens review on the pilot workload after Wave 0.

Reproduce this — Checklist source: examples/architecture-blog-2026/migration-readiness/checklist.md. Pair with AWS MAP in the Transform launch guide and the Migration Hub closure notice (Nov 7, 2025) when updating procurement templates.

What this post does not cover

• Partner selection (when to hire a migration partner).
• DMS cutover drills (see migration mistakes post).
• Application modernization ROI (board business case).
• Industry-specific regulatory packs (HIPAA, PCI) beyond Security pillar references.

Services: AWS Cloud Migration · Related: Common migration mistakes (2026) · CAF + MAP + Well-Architected

If you only do one thing: Score Platform + Security before you install the first replication agent—not after the first failed audit.

Frequently asked questions

How is this different from the AWS Cloud Adoption Framework (CAF)?

CAF 3.0 (47 capabilities across six perspectives) is the organizational transformation map. This checklist is the migration program gate: pass/fail controls with evidence links you attach to MAP Assess deliverables and CFO business cases. Use CAF for capability gaps; use this list for “are we allowed to cut over wave 1?”

When should we NOT start migration waves?

Do not start production cutovers if: (1) no executive sponsor on the charter, (2) parallel-run budget is not in the 12-month forecast, (3) mandatory tags are undefined, (4) more than five Fail items remain in Platform or Security pillars, or (5) discovery is still sticky notes without owners. Pilot non-prod migrations can proceed with documented exceptions in the risk register.

Does passing this checklist guarantee MAP funding?

No. MAP eligibility depends on committed AWS spend, partner authorization, and AWS approval—not checklist completion. The checklist prevents you from burning Mobilize weeks on workloads that will stall when SCPs, logging, or chargeback were deferred. See our MAP SMB guide for funding mechanics.

What goes wrong if we skip Assess and jump to MGN replication?

Teams replicate VMs with Application Migration Service (MGN) before Organizations, logging, or FinOps tags exist—then refactor tenancy under live traffic. A typical pattern: cutover succeeds, Cost Explorer spikes on NAT and cross-AZ traffic in week two, security audit finds unencrypted volumes because Config was off in member accounts. Rollback is politically impossible; you pay refactor tax for 6–12 months. Do not confuse MGN with AWS Managed Services (AMS).

How long should Assess take?

For mid-market portfolios (~50–200 VMs), Assess with machine-readable discovery is often 4–8 weeks calendar time with a dedicated architect and app owners—not two days. Shorter only if a recent Cloud Maturity Assessment and dependency graph already exist and are younger than six months.

Where does AWS Transform fit after Migration Hub closed to new customers?

AWS documented that Migration Hub stopped accepting new customers on November 7, 2025. Net-new planning should use AWS Transform for discovery/modernization assistance alongside Application Migration Service for rehost and DMS for databases—not “activate Migration Hub first” decks. See our 2026 migration mistakes post for product-path updates.