VMware Workload Migration Strategy - A Phased Approach That Uses MGN and EVS Selectively
This article explains how to choose between MGN (Application Migration Service) and EVS when migrating VMware workloads to AWS, how to draw up a phased migration plan, and post-migration optimization.
Three Approaches to VMware Migration
Methods for migrating VMware workloads to AWS are broadly classified into three types. The first, lift & shift, is a method of relocating the VMware environment onto AWS as it is with Amazon EVS. No application changes are needed, but VMware licenses are still required. The second, replatforming, is a method of converting VMware VMs into EC2 instances with AWS MGN (Application Migration Service). It frees you from VMware licenses, but compatibility verification of the OS and middleware is required. The third, refactoring, is a method of containerizing applications and running them on ECS or EKS. It is the most cloud-native form, but the effort required to modify applications becomes large.
Migration Assessment and Planning
Before migration, if you are already using AWS Migration Hub (which stopped accepting new customers starting November 7, 2025), you can collect an inventory of the existing environment and map the dependencies between workloads. With Migration Evaluator (formerly TSO Logic), you can calculate the optimal configuration and a cost estimate on AWS from usage data of your current on-premises environment. Based on the assessment results, you determine whether to migrate each workload with EVS, MGN, or refactoring. As decision criteria, you choose EVS for workloads highly dependent on VMware-specific features (vMotion, DRS, HA), MGN for standard Linux/Windows servers, and refactoring for applications that can be expected to move to microservices.
Putting EC2 Migration with MGN into Practice
AWS MGN installs an agent on the source server and creates a replica on AWS through continuous block-level replication. Because the source server keeps running during replication, there is no impact on business operations. You verify the replica's behavior with a test launch, and if there are no problems, you run the cutover to switch over production. Downtime at cutover is only the time to synchronize the final changes (usually a few minutes to a few tens of minutes). With MGN, the agent can coexist with VMware Tools, so you can install it as is on servers in a vSphere environment. After migration, the servers run as EC2 instances, so you can make use of AWS-native features such as integration with Auto Scaling and ALB.
Considering Migration Costs
MGN itself is free to use, and only the cost of the staging area for replication (EC2 + EBS) is incurred. For EVS, the charge for dedicated hosts (i4i.metal) is the main cost factor, at about $15,000 or more per month for the minimum 3-host configuration (as of August 2026). Because the choice of migration method greatly affects cost, you carefully evaluate the tradeoff between EC2 migration with MGN (low cost, app changes required) and VMware environment relocation with EVS (high cost, no changes required). You analyze the costs of the current environment with Migration Evaluator and estimate the post-migration TCO before deciding on the method.
Organizing Migration Strategies
There are several approaches to cloud migration. The method of moving virtual machines almost as they are lets you migrate in a short period with few changes, and it is suited to cases where you first want to get things running reliably. The method of replacing part of the OS and middleware to optimize for the cloud strikes a balance between reducing the operational load and the speed of migration. The method of rebuilding applications to make them cloud-native takes effort, but you can obtain the greatest effect. Rather than moving everything with the same method, a realistic strategy is to choose between methods according to the importance of each application and the room for modification, and to proceed in phases.
How MGN Works and Its Features
Application Migration Service (MGN) is a representative means of migrating running servers to AWS almost as they are. By continuously replicating the data of the source servers, you can prepare for migration without stopping production. Before the switchover, you can launch test instances from the replicated data and verify in advance whether they work correctly at the migration target. At the production switchover, you switch over from a state synchronized up to just before the switchover, so you can keep downtime to a minimum. Being able to migrate safely and with short downtime without greatly changing the existing configuration is a major advantage of using MGN.
Post-Migration Optimization and Modernization
After migrating servers as they are, you move on to optimization that draws out the benefits of the cloud. You measure actual usage, adjust overprovisioned instances to appropriate sizes, and reduce costs. Furthermore, if you advance modernization in phases, such as moving databases to managed services and replacing processing with containers or serverless, you can lower the operational load and increase scalability. By taking a two-stage approach of first migrating reliably and getting things running and then making repeated improvements, you can maximize the benefits of the cloud over the long term while keeping migration risk down. You treat migration as the starting point for optimization.
How to Run a Migration Project
To make a large-scale migration succeed, designing how to proceed is important as well as the technology. If you prepare the target AWS environment with the security and permissions foundation in place, you can accept each workload safely. You group the migration targets by dependency, assign priorities, and proceed in phases. You apply the knowledge gained in the first wave to subsequent migrations to increase efficiency. You also prepare in parallel for the team to become proficient in cloud operations. Rather than trying to move everything at once, proceeding steadily while running the cycle of planning / execution / verification / improvement leads a migration project to success.
Summary - Recommended Strategy for Phased Migration
For migrating VMware workloads to AWS, a phased strategy that uses EVS and MGN selectively according to the characteristics of each workload, rather than a single approach, is effective. First, you migrate development / test environments to EC2 with MGN to build up know-how in cloud operations, and for production environments you lift & shift them with EVS and then convert them to EC2 one after another. After migration, you optimize instance sizes with Compute Optimizer and reduce costs with Savings Plans. A phased move away from VMware licenses lets you achieve a reduction in long-term operating costs.
References (Official AWS Resources)
The primary sources for this page are the official AWS website and documentation. Check the official pages below for the latest specifications and pricing.
- AWS MGN official page
- Amazon EVS official page
- AWS Migration Hub official page
- AWS Documentation (official)
If this page and the official documentation disagree, treat the official documentation as authoritative.