If you've looked at AWS's own migration documentation, you've probably seen the same three words over and over: Assess, Mobilize, Migrate & Modernize. It's not marketing fluff — it's the actual structure AWS uses in its Prescriptive Guidance docs and its Migration Acceleration Program (MAP), and it maps closely to where most migrations actually go wrong. Here's what each phase covers, and where the sharp edges are.
Phase 1: Assess
This is the discovery and business-case phase. Before any workload moves, the goal is to answer two separate questions: what do we have, and should we move it.
In practice this means:
Inventorying servers, applications, and their dependencies — AWS's own tooling here is Migration Evaluator and AWS Application Discovery Service, which passively collect server utilization and network dependency data rather than relying on someone's spreadsheet of "what we think we're running."
Building a directional business case (TCO comparison, right-sizing estimates) rather than a hand-wavy "cloud is cheaper" pitch.
Identifying blockers early — licensing constraints, compliance requirements, workloads with hard dependencies that make them bad candidates for an early wave.
The uncomfortable truth about this phase: dependency mapping almost always surfaces stuff nobody remembered existed. A cron job hitting an undocumented internal API, a service account with permissions nobody can explain. Finding that in Assess is cheap. Finding it mid-cutover is not.
Phase 2: Mobilize
Assess tells you what you have. Mobilize is where you build the thing you're actually going to migrate into, and close the gaps the assessment surfaced.
Core activities:
Landing zone setup — a secure, multi-account AWS environment with baseline networking, IAM, logging, and guardrails in place before workloads land in it. AWS Control Tower is the common starting point here.
Migration strategy selection per workload, using what AWS now documents as the 7 R's (an evolution of the older "6 R's" — Relocate was added as its own category, distinct from Rehost): Rehost, Replatform, Repurchase, Refactor, Retire, Retain, and Relocate (for VMware-based lift-and-shift via VMware Cloud on AWS, without re-architecting).
Operational readiness — runbooks, monitoring, and team skills-gap closure, so the org isn't learning CloudFormation for the first time during cutover week.
Mobilize is also where migration sequencing gets decided — which applications move in wave one versus later waves, generally starting with lower-risk, lower-dependency workloads to build confidence and tooling maturity before tackling anything business-critical.
Phase 3: Migrate and Modernize
This is the execution phase, and AWS's own guidance splits it into two stages worth knowing about:
Initialize — setting up the migration factory: tooling, automation, and repeatable patterns for the specific workload types being moved (servers via AWS Application Migration Service/MGN, databases via AWS DMS, bulk data via DataSync or Snow Family for offline transfer).
Implement — the actual migrate → test → cut over cycle per wave, ideally with a validated rollback path for each workload rather than a one-way door.
"Modernize" in this phase isn't optional set dressing — AWS's guidance recommends migrating first, then modernizing, rather than trying to refactor and migrate simultaneously. Trying to do both at once compounds risk in ways that make it hard to tell whether a failure is a migration bug or a modernization bug.
Why this structure matters more than it looks like
The three phases aren't just AWS's preferred vocabulary — they map directly to the three most common migration failure modes: moving things you didn't understand (skipped Assess), moving into an environment that wasn't ready (skipped Mobilize), and moving everything at once instead of in validated waves (rushed Migrate & Modernize). AWS's own Migration Acceleration Program data attributes a large share of failed or over-budget migrations to compressing or skipping the first two phases.
If you're evaluating a migration plan — yours or a vendor's — and it jumps straight to "we'll rehost your EC2 instances," it's worth asking what the Assess and Mobilize phases actually looked like. Skipping straight to execution is usually where the surprises live.
Has anyone here worked through AWS MAP directly? Curious whether the phase boundaries hold up as cleanly in practice as they do on paper.
Top comments (0)