Migration Phases

Migration phases organize the work required to move applications, data, and operational responsibilities to the cloud. They cover more than copying servers: a successful migration also requires business justification, security controls, staff readiness, testing, and operational ownership. AWS commonly describes this journey through three phases: assess, mobilize, and migrate and modernize. These phases provide a planning structure rather than a rigid sequence that every workload must complete simultaneously.

During assess, an organization establishes why it is migrating and whether it is ready. Teams inventory workloads, identify application dependencies, examine licensing and compliance requirements, and compare current costs with projected cloud costs. They also assess skills, governance, and operating practices. Practical outputs include a business case, an initial application portfolio, readiness gaps, and measurable goals such as leaving a data center before a lease expires. A cost comparison should account for migration effort, network connectivity, support, and temporary operation of both environments.

During mobilize, teams address the gaps identified in assessment and build the foundation for migration at scale. This commonly includes a landing zone with account structure, identity controls, networking, logging, security policies, and cost allocation. Teams establish operating procedures, train staff, refine dependency information, and test their approach with initial workloads. Migration waves group applications into manageable batches, usually taking dependencies and business constraints into account. For example, an application server and its database might need to move together to avoid unacceptable network latency.

During migrate and modernize, teams execute workload migration plans, test functionality and performance, synchronize data, and perform controlled cutovers. A cutover plan should define acceptable downtime, success criteria, responsibilities, and rollback conditions. After migration, teams monitor the workload, verify backups and recovery procedures, optimize resources, and retire the old environment only after acceptance and retention requirements are satisfied. Modernization can occur during migration or later; redesigning every application before moving it is not mandatory.

The phases describe when and how migration work is organized, whereas migration strategies describe what happens to each workload. The commonly tested seven strategies are rehost, relocate, replatform, repurchase, refactor or re-architect, retain, and retire. Rehosting may support a tight exit deadline but preserve inefficient sizing or operational patterns. Refactoring can improve architectural fit but usually requires more development and testing. Retaining or retiring an application can be a valid portfolio decision rather than a failed migration.

A common misconception is that each phase ends permanently before the next begins. In practice, discoveries during a pilot or migration wave can change the business case, dependency map, or target design. Another misconception is that technical cutover completes cloud adoption: security, governance, financial management, and operations continue afterward. For exam questions, distinguish these migration phases from the AWS Cloud Adoption Framework transformation phases of envision, align, launch, and scale, which describe a broader organizational transformation journey.