AWS Application Migration Service (MGN)
Key Takeaways
- AWS Application Migration Service (MGN), branded AWS Transform MGN in June 2026, is the live-server rehost factory: continuous block-level replication, then test launches, then cutover with typical downtime measured in minutes.
- Launching test instances does not replace production; Finalize cutover is what stops replication and tears down the staging area.
- VM Import/Export imports offline images into AMIs and is not a substitute for MGN when hundreds of live VMs change every minute.
- AWS Application Discovery Service and Migration Hub inventory can be exported as CSV and imported into MGN so waves, applications, and EC2 launch recommendations survive into execution.
- MGN needs TCP 443 to the service API and TCP 1500 to staging replication servers; a disconnected site cannot use MGN until that path exists.
Why rehost still appears on a Professional exam
SAP-C02 Task 4.2 asks you to determine the optimal migration approach for existing workloads. Independent OpenExamPrep study material for this task treats AWS Application Migration Service (MGN) as the named application-migration tool in the exam guide. In June 2026 AWS announced that Application Migration Service is available as AWS Transform MGN. The replication, test, and cutover engine is the same service with a new console name. This section uses MGN, the identifier the exam outline still lists, and notes the Transform branding so a renamed console does not throw you.
MGN is a rehost (lift-and-shift) factory. It copies disks at block level while the source stays up, then converts those disks so they boot as Amazon Elastic Compute Cloud (Amazon EC2) instances with Amazon Elastic Block Store (Amazon EBS) volumes. AWS documents typical cutover windows of minutes, not the multi-hour freeze of exporting a cold virtual machine (VM) image. That is why MGN, not VM Import/Export, is the default answer when production servers keep changing.
MGN does not choose the 7 Rs for you. If the strategy for a 50 TB Oracle system is replatform onto Amazon Aurora, MGN is the wrong primary tool for the database. If the strategy for eighty application VMs is rehost, MGN is the factory. Professional items mix both in one company story.
Replication architecture
Initialize MGN in the target AWS Region and account. For many member accounts, Global View works with AWS Organizations so operators can see source servers, applications, and waves across accounts. Create a dedicated staging area subnet. MGN launches replication servers there. Those servers receive blocks and write them to staging EBS volumes. They are not the instances your users will hit.
On each source server you install the AWS Replication Agent (Windows or Linux). The agent registers the server, completes an initial sync, then sends changed blocks continuously. Official network requirements are specific enough to appear in architecture scenarios:
- Source servers to MGN API endpoints over TCP 443 for agent download and upgrade, replication status, events, and hardware inventory.
- Source servers to replication servers over TCP 1500 for encrypted, compressed block traffic using TLS 1.2, with a per-replication-server certificate validated by the agent.
- Staging subnet back to MGN over TCP 443, and to Amazon S3 for service artifacts.
A factory, mine, or ship that cannot open 443 and 1500 cannot run MGN until a path exists (AWS Direct Connect, AWS Site-to-Site VPN, or at least internet to those endpoints). That constraint is how MGN questions connect to the data-transfer section of Task 4.2.
Agentless replication exists for supported VMware vCenter environments when you cannot install an in-guest agent. It is snapshot-based rather than continuous in-guest block capture. On the exam, “cannot install an agent on VMware” points to agentless MGN, not to AWS DataSync and not to shipping VMDK files.
Three templates control behavior for every newly added server; you can override per server:
| Template | What it governs |
|---|---|
| Replication | Staging subnet, replication server type, EBS encryption, bandwidth throttling |
| Launch | Right-sizing, copy private IP, OS licensing, boot mode, and the EC2 launch template (subnet, security groups, IAM instance profile) |
| Post-launch | Optional actions such as installing the AWS Systems Manager agent or Amazon CloudWatch agent, a Windows version upgrade, or converting Microsoft SQL Server bring-your-own-license to license-included |
Launch test and cutover instances into a migrated resources subnet, not into the staging subnet. Staging is a dirty copy area. Production identity, load balancers, and Amazon Route 53 records should target the migrated-resources instances after cutover.
Test versus cutover
This distinction is the highest-yield MGN trap on SAP-C02.
Launch test instances when the source server shows healthy replication and is Ready for testing. MGN creates EC2 instances from the latest replicated disks. The source keeps serving customers. Keep tests in an isolated subnet or tightly scoped security group so a test domain controller or application server does not steal the source’s computer account in Active Directory or write into production. After testers sign off, Revert test terminates the test instances. Replication never stopped. Then mark the servers Ready for cutover.
Launch cutover instances is go-live. A practical sequence: drain or quiesce writers on the source, wait until replication lag is near zero, launch cutover instances, move users (Route 53 weighted or failover records, load balancer target groups, or an IP cut if you copied private IPs into a matching VPC CIDR), then Finalize cutover. Finalize stops replication, removes staging resources, and archives the source server in MGN. Revert cutover exists if you must fall back before you finalize.
Do not Finalize to “save money” during a proof of concept. Do not treat the first launch as cutover when the stem still needs the source online. Do not launch tests into the same subnet as production domain controllers unless the question explicitly wants that risk.
MGN versus VM Import/Export
VM Import/Export imports offline images (VMDK, VHD/VHDX, OVA) into Amazon Machine Images (AMIs) or EBS snapshots, and can export AMIs back out. It is the right tool for a golden-image catalog, an air-gapped appliance, or a one-time import of a powered-off lab VM. AWS’s own VM Import/Export guide points live VMware vSphere, Microsoft Hyper-V, and Microsoft Azure server migrations to MGN.
| Decision | MGN | VM Import/Export |
|---|---|---|
| Source state | Live servers; continuous replication | Offline or quiesced image files |
| Downtime | Minutes at cutover | Hours of export, upload, and import |
| Test cycle | First-class test launches and revert | You launch from the AMI yourself |
| Scale | Waves, applications, dashboards, CSV import | Per-image jobs |
| Network | TCP 443 and 1500 for as long as you replicate | Upload the image once (internet, Direct Connect, or physical media) |
| Fallback | Revert cutover while the source still exists | You own the rollback AMIs |
If the prompt is “200 production VMs with daily change and a cutover window of minutes,” MGN wins. If the prompt is “approved hardened OVA library into AMI form,” VM Import/Export wins. DataSync copies files and objects; it does not convert a running guest into an EC2 instance. AWS Database Migration Service (AWS DMS) copies database rows, not VM block devices.
Application Discovery Service as an MGN input
AWS Application Discovery Service (ADS) collects server inventory, utilization, and (with agents) process and network-connection data. AWS Migration Hub groups servers into applications and waves. EC2 instance recommendations built from utilization can be exported as CSV and imported into MGN. The import creates MGN applications and waves and can fill launch settings such as instance type, subnet, and private IP.
When you later install the Replication Agent, the user-provided ID must match the inventory ID so MGN does not create duplicates. The MGN connector can push agents after inventory exists. None of this replaces landing-zone work: discovery feeds the factory; AWS Control Tower and Organizations still need to exist so those launch subnets live in the right member accounts with logging and guardrails already on.
Mixed-estate scenario
A 50 TB Oracle database on a physical host plus eighty application VMs is not a single-tool problem. MGN rehosts the application VMs (and the Oracle host only if the chosen R is rehost onto EC2). If the database target is Amazon Relational Database Service (Amazon RDS) or Amazon Aurora, the data path is DMS and AWS Schema Conversion Tool (AWS SCT), covered next. Shipping 50 TB of database files on a Snow device does not register VMs in MGN. A disconnected site cannot start MGN until 443/1500 exist; use physical transfer and a landing zone first, then install agents when the network is ready.
Exam traps: using DataSync to “copy VMs”; using DMS on the operating-system disk; skipping test launches; Finalize before users move; assuming MGN works with no network; treating VM Import/Export as a live-estate factory; forgetting that ADS/Migration Hub CSV import is how discovery becomes executable waves.
A global retailer must prove that 40 Windows application servers will boot in the landing-zone VPC, join the correct security groups, and pass smoke tests before any production DNS change. The source servers must keep serving customers during that proof. Which MGN action matches the requirement?
A company runs 200 live VMware virtual machines that change every minute. Leadership wants a repeatable rehost with a cutover window of minutes, not a weekend freeze to export images. Which approach should the architect choose?
Discovery used Application Discovery Service agents. Migration Hub grouped servers into applications and waves and produced EC2 instance recommendations. How should that work feed MGN so operators do not rebuild waves by hand?