Accelerate Workload Migration and Modernization

Assuming you know the basic AWS landing-zone building blocks (accounts, VPCs, and core compute/database services), this domain moves an existing estate onto AWS, then improves it; by the end you can sequence a large migration and pick each workload's strategy and tool. The AWS Migration Acceleration Program (MAP) frames a large move in three phases: Assess (find capability gaps and build a realistic total-cost-of-ownership model), Mobilize (close those gaps, build the landing zone, the multi-account, networking, and guardrail foundation, and run a few migrations to prove the pattern), and Migrate & Modernize (run the portfolio at scale). The exam rewards this order: plan and stand up the landing zone during Mobilize, not mid-migration. AWS Migration Hub is the single pane tracking status from each tool (MGN, DMS) across the portfolio; note Migration Hub and Application Discovery Service are no longer open to new customers as of November 7, 2025 (existing customers continue), with AWS pointing new work at AWS Transform.

AWS classifies each application by one of the 7 Rs: Retire (decommission what is no longer needed), Retain/revisit (leave it where it is for now), Relocate (hypervisor-level lift-and-shift, e.g. VMware Cloud on AWS, no OS or app change), Rehost (lift-and-shift to EC2 with no changes), Repurchase (drop-and-shop to a SaaS product), Replatform (lift-and-reshape with targeted optimization such as moving a self-managed database to RDS), and Refactor/re-architect (rebuild to be cloud-native). The trade-off runs along a curve: Retire/Retain/Rehost are low-effort and low-benefit; Replatform is the pragmatic middle; Refactor is highest-effort and highest long-term benefit. The exam tests the choice: the lowest-utilization workloads, the 'zombie' and 'idle' applications defined under Decide from portfolio data below, are usually retired or retained rather than rehosted.

Strategy selection is a data-driven exercise: discover the estate, measure dependencies and utilization, then assign an R. AWS Application Discovery Service collects server inventory, performance, and network-dependency data (agentless connector via the OVA, or the agent for deeper data) that feeds Migration Hub; Migration Evaluator (formerly TSO Logic) builds the business case and projected AWS cost. AWS Prescriptive Guidance uses precise utilization labels you should not paraphrase: an application averaging under 5% CPU/memory is a 'zombie application' and one between 5% and 20% over a 90-day window is an 'idle application'; both are commonly retired or retained rather than migrated.

Two valid sequences win different questions. Rehost-then-modernize moves the workload to AWS quickly with AWS Application Migration Service (MGN), the primary recommended lift-and-shift service, which replaced the retired CloudEndure Migration and Server Migration Service (SMS), and then refactors once it is running, minimizing the cutover window and migration risk when the deadline (e.g. a data-center exit) is the binding constraint. Modernize-during-migration changes the architecture as part of the move (containerize a .NET/Java app with App2Container into ECS/EKS, or convert a database with the AWS Schema Conversion Tool and DMS) and is preferred when the legacy form factor is the actual problem and a second migration is not worth it. MGN itself blurs the line: it supports post-launch templates and actions so you can replatform/refactor right after rehosting, so for many large moves rehost is the start line, not the finish, and modernization continues afterward.

Three tooling families cover most scenarios. For servers, MGN does block-level replication and automated cutover for physical, virtual, or other-cloud servers (rehost). For databases, AWS Database Migration Service (DMS) moves the data with optional change-data-capture for near-zero-downtime cutover, while the AWS Schema Conversion Tool (SCT) converts schema and stored procedures for heterogeneous (cross-engine) migrations. Mnemonic: SCT converts structure, DMS moves data. For bulk data, AWS DataSync handles online transfer over the network and the AWS Snow Family (Snowball Edge) handles offline transfer when bandwidth or time rules out the wire; Snowmobile is retired, so multi-petabyte answers use Snowball Edge fleets, Direct Connect, or DataSync.