AWS MAP Migrate and Modernize Phase: Executing at Scale

How Do the 7Rs Apply to Each Workload?

The 7Rs framework provides a structured approach to deciding how each workload should be handled during migration. Not every application needs the same treatment. Applying the right strategy to each workload optimizes cost, effort, and outcome.

Retire applies to applications that are no longer needed. Portfolio discovery during Assess often reveals 10-20% of workloads that can be decommissioned. Retiring these before migration reduces scope, cost, and complexity. Every retired server is one fewer to migrate, secure, and operate.

Retain covers workloads that cannot move to the cloud right now. Hardware dependencies, regulatory restrictions, or pending replacement timelines keep some applications on-premises. Retain is not permanent — it is a deferral with a future review date.

Rehost (lift-and-shift) moves workloads to AWS with minimal changes. This is the fastest migration strategy and applies to the majority of workloads in most enterprise migrations. AWS Application Migration Service (MGN) automates rehosting by continuously replicating source servers to AWS.

Relocate moves VMware workloads to VMware Cloud on AWS without modifying the application or the operations model. This strategy applies specifically to organizations with significant VMware investments that want to reduce data center dependency while preserving their VMware tooling.

Repurchase replaces existing software with a SaaS equivalent. Moving from self-hosted email to Microsoft 365, or from on-premises CRM to Salesforce, are common repurchase decisions. The workload moves to cloud, but it leaves your AWS environment entirely.

Replatform makes targeted modifications during migration. Migrating a self-managed MySQL database to Amazon RDS, or moving a .NET application from Windows Server to containers on ECS, are replatform examples. The application functionality stays the same, but the underlying platform improves.

Refactor (re-architect) redesigns the application to be cloud-native. This is the most effort-intensive strategy but delivers the greatest long-term benefits. Monolithic applications broken into microservices, batch processes converted to event-driven architectures, and legacy APIs rebuilt as serverless functions are common refactor patterns.

Which Migration Tools Support Large-Scale Execution?

AWS Application Migration Service (MGN) is the primary tool for server rehosting. It installs a lightweight agent on source servers that continuously replicates data to AWS. When ready for cutover, MGN launches target instances from the replicated data. This approach minimizes cutover downtime to minutes rather than hours.

AWS Database Migration Service (DMS) handles database migrations. It supports homogeneous migrations (Oracle to Oracle on RDS) and heterogeneous migrations (Oracle to PostgreSQL on Aurora). DMS can run continuous replication during a transition period, allowing both source and target databases to stay in sync until cutover.

AWS Migration Hub provides a central dashboard for tracking migration progress across tools. It aggregates status from MGN, DMS, and third-party migration tools into a single view. Migration Hub also integrates with the MAP program to track workload counts against your migration targets.

For containerization, AWS App2Container converts existing Java and .NET applications into container images. AWS App Runner and Amazon ECS provide managed container runtime environments. These tools support organizations that want to replatform traditional applications into containers during migration rather than as a separate modernization effort.

How Do You Handle Cutover Windows?

Cutover is the moment when production traffic switches from the source environment to AWS. Planning cutover windows requires coordination between migration teams, application owners, business stakeholders, and sometimes external partners or customers.

Most organizations schedule cutovers during low-traffic periods — weekends, overnight, or holiday windows. The cutover plan should include a detailed timeline: stop source applications, perform final data sync, launch target instances, run validation tests, update DNS or load balancers, and confirm production readiness.

Rollback procedures are non-negotiable. Every cutover plan must include a tested rollback path. If post-cutover validation reveals issues, the team needs a documented process to revert to the source environment within your defined recovery time objective. MGN maintains source-server replication until rollback risk has passed.

Cutover velocity increases with experience. Early waves may take 4-6 hours per cutover. By Wave 5, automated runbooks and experienced teams can complete cutovers in 1-2 hours. This acceleration is another benefit of the wave-based approach — each wave teaches the team to move faster.

What Modernization Options Run Alongside Migration?

Modernization during the Migrate and Modernize phase does not mean stopping migration to refactor everything. Instead, it means making targeted improvements to selected workloads while the migration factory continues processing rehost waves.

Database modernization is the most common parallel activity. Moving self-managed databases to Amazon Aurora, DynamoDB, or other managed services reduces operational overhead and improves performance. AWS DMS supports these migrations with minimal downtime, and the resulting managed databases qualify for MAP credits.

Containerization of application tiers is another parallel modernization path. Web and application tiers are often candidates for containerization on Amazon ECS or EKS. The database tier may rehost initially and modernize later. This layered approach balances migration speed with modernization benefits.

Serverless adoption applies to specific workload patterns. Batch processing jobs, scheduled tasks, and event-driven workflows are natural candidates for AWS Lambda. API backends can migrate to API Gateway with Lambda. These serverless patterns eliminate server management entirely and scale automatically with demand.

How Do You Track MAP Credits During Execution?

Proper resource tagging is the foundation of credit tracking during this phase. Every migrated resource must carry the map-migrated tag with your MAP agreement identifier. Without this tag, the resource generates AWS spend but not MAP credits. Follow the detailed guidance in our MAP tagging guide to avoid common mistakes.

Monitor your Cost and Usage Report (CUR) weekly during active migration. Verify that newly migrated resources appear with correct tags. Track the gap between total migration-account spend and tagged spend — any difference represents potential lost credits.

Work with your AWS partner to submit regular progress reports to AWS. These reports document workload counts, migration completion rates, and credit-eligible spend. Consistent reporting maintains your MAP engagement health and ensures funding continues through the program duration.

How Do You Manage Risk During Large-Scale Migration?

Risk management during the Migrate phase operates at two levels: wave-level and workload-level. At the wave level, each wave has a go/no-go decision point based on pre-cutover validation results. If critical issues surface during testing, the wave can be postponed without affecting other waves in the pipeline.

At the workload level, each application has defined acceptance criteria. Post-migration validation tests confirm that the application functions correctly, meets performance benchmarks, and maintains data integrity. Automated testing scripts created during the Mobilize phase run these validations consistently across every workload.

Communication planning is a risk mitigation management services tool that teams often overlook. Stakeholders need regular updates on migration progress, upcoming cutover windows, and potential business impact. A communication plan that specifies who is notified, when, and through what channel prevents confusion during active migration weekends.

Data migration deserves special risk attention. Large databases with terabytes of data require extended replication periods before cutover. AWS DMS continuous replication keeps source and target databases in sync, but the final switchover still involves a brief period of write-lock. Plan this window with application owners and test the switchover procedure during dry runs.

What Metrics Should You Track During Execution?

Track workload counts across four states: planned, in-progress, completed, and blocked. A healthy migration program shows steady flow from planned to completed with minimal items in the blocked state. Blocked workloads need immediate attention — they represent dependencies or issues that may cascade to other waves.

Monitor migration velocity as servers completed per wave and per week. Early waves will show lower throughput as the team builds proficiency. By mid-program, velocity should stabilize at your target throughput. A sustained decline in velocity signals process issues, tool problems, or team fatigue that needs addressing.

Financial metrics matter alongside operational ones. Track tagged spend against projected MAP-eligible spend. Monitor credit accrual monthly. Compare actual AWS costs against the business case projections developed during the Assess phase. Early detection of cost variances allows corrective action before the gap becomes significant.

Completing the Migration and Looking Ahead

The Migrate and Modernize phase concludes when all in-scope workloads have moved to AWS or been handled through their designated 7R strategy. Final activities include decommissioning source environments, completing data center exit procedures, and transitioning from migration mode to steady-state operations.

Post-migration optimization begins immediately. Right-sizing instances based on actual AWS utilization data, purchasing Reserved Instances or Savings Plans for steady workloads, and implementing automated scaling policies improve cost efficiency. These optimizations compound the financial benefits already gained through MAP credits.

The skills, processes, and governance structures built during MAP continue to serve your organization. The Cloud Center of Excellence established during Mobilize becomes your permanent cloud operations team. The migration factory transforms into an innovation factory. Partner with an experienced AWS migration services provider like Opsio to maintain momentum from migration through ongoing cloud optimization.