How to Migrate VMware VMs to AWS EC2 Using AWS MGN
Moving VMware virtual machines to Amazon Web Services requires more than converting a virtual disk and attaching it to an EC2 instance. A reliable migration must preserve application data, account for operating system differences, validate network behavior, and provide a controlled cutover.
AWS Application Migration Service, commonly called AWS MGN, provides continuous block-level replication from VMware environments to AWS. It creates a recoverable copy of each source server in a staging area, allowing administrators to test the workload before launching the final EC2 instance.
This workflow suits lift-and-shift migrations where the goal is to move existing Windows or Linux servers with minimal application changes. The process is agent-based, repeatable, and compatible with migration waves ranging from a single VM to a large data center exit.
Prepare The AWS Landing Zone
Begin by selecting the AWS Region and target account for the migration. Confirm that the required VPC, subnets, route tables, security groups, IAM permissions, and connectivity are available before installing the replication agent.
AWS MGN uses a staging subnet for replication servers. These lightweight EC2 instances receive data from the VMware source and maintain replicated volumes in the target Region. The staging subnet should have outbound connectivity to AWS MGN endpoints, either through a NAT gateway, VPC endpoints, or another approved network path.
Create or verify the IAM roles used by AWS MGN. The service-linked role allows MGN to operate within the account, while the replication settings determine how staging servers and target instances are provisioned. Review encryption requirements carefully if the organization uses customer-managed AWS Key Management Service keys.
Check VMware Source Requirements
Inventory each candidate VM before migration. Record its operating system, hostname, IP configuration, disk sizes, boot mode, installed agents, database dependencies, and application owner. This information helps identify servers that require special treatment, such as domain controllers, clustered systems, or appliances with hardware-specific drivers.
The source VMware environment must be able to communicate with AWS MGN and its replication infrastructure. The replication agent is installed inside the guest operating system, so administrative credentials are required. Confirm that firewalls permit the necessary outbound traffic and that the source server can resolve the AWS endpoints used by the service.
Remove obsolete snapshots and confirm that the guest operating system is healthy. VMware snapshots can increase disk activity and complicate performance analysis. Also verify that the server has enough free space for the agent, current security updates, and any temporary files created during testing.
Install The Replication Agent
In the AWS MGN console, create the initial replication settings and identify the staging subnet, security group, data replication behavior, and EBS volume type. The console then provides an installation command for Windows or Linux sources.
Run the installer on the VMware guest with administrative privileges. The agent registers the source server with AWS MGN and begins sending changed blocks to the staging area. Full initial synchronization may take considerable time, depending on the amount of data, disk write rate, available bandwidth, and replication throttling settings.
The source VM remains online while replication continues. Monitor the MGN console for replication health, lag, stalled disks, and data validation status. A server should reach a healthy, continuous replication state before it is included in a test or cutover wave.
Configure EC2 Launch Settings
AWS MGN separates replication from instance launch configuration. For each source server, review the launch settings before creating a test instance. Choose the target subnet, security groups, instance type, EBS volume configuration, IAM instance profile, tenancy, and private IP behavior.
Pay close attention to boot mode and disk mapping. A VM configured for BIOS boot may require different settings from a UEFI-based system. Windows servers may also need the correct AWS drivers, while Linux systems should be checked for cloud-init behavior, initramfs support, and persistent network interface naming.
The following decisions commonly affect the quality and cost of the migrated workload:
| Migration Decision | Recommended Practice | Common Risk |
|---|---|---|
| Staging instance type | Start with the default MGN recommendation and tune after observation | Excessive replication cost |
| Target EC2 size | Match CPU, memory, and network needs rather than VMware vCPU labels alone | Under- or over-provisioning |
| EBS volume type | Use gp3 for general workloads and provisioned IOPS only when required | Unnecessary storage expense |
| Private addressing | Preserve application network design where possible | Broken firewall rules or dependencies |
| Security groups | Permit only required application, management, and monitoring traffic | Overly broad access |
| Test launch | Use a separate validation subnet or controlled security group | Accidental production interaction |
Run A Test Launch
A test launch creates EC2 instances from the replicated data without stopping the VMware source. Use it to confirm that the operating system boots, disks are present, services start, and applications behave as expected.
Validate DNS registration, domain membership, time synchronization, monitoring agents, backup agents, endpoint protection, scheduled tasks, and license activation. Test application connectivity from dependent systems rather than checking only the server console. A migrated database may boot successfully while still failing due to network ACLs, name resolution, or storage latency.
Testing should also include operational procedures. Confirm that administrators can connect through approved management tools, that logs reach the monitoring platform, and that the instance can be backed up and restored. If changes are needed, adjust the launch settings or target configuration and repeat the test rather than modifying the source VM unnecessarily.
Perform The Cutover
Schedule cutover during an approved maintenance window. Stop application services on the VMware source, or shut down the source VM when the workload requires filesystem consistency. Allow AWS MGN to capture the final changes, then choose the cutover action in the console.
The service launches the target EC2 instance from the latest replicated point and marks the source server as cut over. Update DNS, load balancer targets, firewall rules, monitoring records, and automation references so users and dependent systems reach AWS instead of VMware.
Keep the source VM isolated but available according to the rollback plan. Do not immediately delete source disks or replication data. First verify application functionality, data integrity, performance, scheduled operations, and user access during the agreed observation period.
Operational Recommendations
A migration wave is easier to manage when servers are grouped by application dependency rather than migrated in arbitrary inventory order. Document owners, test criteria, rollback timing, and communication contacts for every wave.
Use tags for application name, environment, migration wave, owner, and support team. These tags improve cost allocation and make it easier to identify resources created by AWS MGN. After stabilization, remove temporary staging resources and retire replication only when the rollback window has expired.
- Start with a low-risk, representative VMware server before moving business-critical workloads.
- Measure replication lag and bandwidth consumption during peak production activity.
- Use separate security groups for testing and production validation.
- Confirm licensing, backup, monitoring, and patching requirements before cutover.
- Record every launch-setting change so later migration waves remain consistent.
AWS MGN provides the replication engine, but a successful VMware-to-EC2 migration still depends on disciplined preparation and validation. Build the landing zone first, replicate in manageable waves, test with real application dependencies, and treat cutover as a controlled operational change. Use this workflow as the foundation for your next migration runbook and begin with a representative server in a noncritical wave.