SAP-C02 Practice Question 6: Large Scale Rehost Application Migration Service
AWS Certified Solutions Architect – Professional (SAP-C02) · Test 1 · question 6 of 10
A retailer's data centre lease expires in six months and 800 VMware virtual machines (a mix of Windows Server and Linux, running commercial off-the-shelf and in-house applications) must be out of the building by then. The applications are not documented well enough to re-architect in the time available, and the business has approved a rehost ("lift and shift") as the first step, with modernization to follow later.
The migration team needs a solution that continuously replicates each server so the final cutover window per application is minutes rather than hours; that lets them boot non-disruptive test instances in AWS from the replicated data while the source servers keep serving production; that groups servers into applications and waves so a whole wave can be cut over in one action; and that requires no changes to the applications or their operating systems.
Which approach should the team take?
Show answer and explanation
Answer:
AWS Application Migration Service (AWS MGN, now documented as AWS Transform MGN) is the AWS-recommended service for lift-and-shift rehosting. An agent installed on each source server performs continuous, block-level replication into a lightweight staging area in the target account, so the source stays in sync while the project runs. Because replication is continuous, cutover only has to apply the last few blocks and boot the converted instance, giving cutover windows measured in minutes. MGN launches *test* instances from the replicated volumes without touching the source server, which is exactly the non-disruptive validation the team needs, and it models servers into applications and waves so launch, cutover, and archival can be performed in bulk. Nothing inside the guest application changes, which keeps rehost as a first step toward later replatform or refactor work.
Option A is a repeated offline copy. DataSync moves files, not running servers, and VM Import/Export produces a point-in-time AMI with no change data capture, so the delta between the last copy and cutover must be handled by a long outage. Re-importing 800 VMs every weekend is also enormous manual effort.
Option C uses the right replication technology for the wrong purpose. AWS Elastic Disaster Recovery is built for ongoing DR, recovery drills and failback, not for a one-way migration project. Its recovery plans can launch ordered groups of servers with a single action, but they sequence DR drills and failover; they do not manage a one-time migration portfolio the way MGN's applications, waves, cutover, and archival tracking do. The option's own wording, keeping drill instances as production, gives it away, and running a permanent DR subscription for servers you intend to migrate once is both more expensive and operationally awkward than MGN.
Option D is a refactor, not a rehost. Containerizing 800 poorly documented applications, including commercial off-the-shelf software that may not be supported in containers, cannot be delivered in six months and directly contradicts the stated decision to rehost first.
References: What Is AWS Transform MGN?; Orchestrating recovery with recovery plans (AWS Elastic Disaster Recovery)