VM migration to AWS EC2: A practical guide with Application Migration Service (lift-and-shift)
Infrastructure migration to the cloud has become a major strategic priority for organizations looking to modernize their IT environments. According to AWS, 75% of enterprise workloads are still running on premises, often hosted on software that is more than twenty years old. In that context, the question is no longer whether to migrate, but how to do it efficiently, with minimal risk and downtime.
AWS Application Migration Service (AWS MGN) is a particularly well-suited solution for DevOps teams and cloud architects looking to rehost virtual machines on Amazon EC2. Unlike traditional approaches that require teams to manually provision new instances and reconfigure applications from scratch, AWS MGN automates much of the migration process while minimizing service interruptions.
This practical guide outlines the concrete steps involved in migrating one or more virtual machines to AWS using Application Migration Service. Whether you are managing a one-time migration or planning a large-scale cloud transformation, this methodology will help you understand the critical phases of the process, anticipate potential friction points, and ensure a successful transition to AWS infrastructure.
Understanding AWS Application Migration Service: An optimized lift-and-shift approach
AWS Application Migration Service represents a major evolution in cloud migration methods. The service makes it possible to replicate physical, virtual, or cloud-hosted servers to AWS without requiring major application changes. This lift-and-shift approach relies on continuous block-level storage replication, compressed and encrypted, to maintain ongoing synchronization between the source servers and the target AWS environment.
The service architecture is built around three main components. In the source data center, lightweight agents installed on each server capture changes in real time. In AWS, a staging area hosts temporary replication servers that orchestrate data transfer. Finally, a migrated resources area contains the final EC2 instances used for testing and then production. This clear separation between staging and production makes it possible to thoroughly validate each migration before the final cutover.
AWS MGN’s decisive advantage over manual migration lies in its ability to drastically reduce the cutover window. Continuous replication means that only the latest changes need to be synchronized during the final cutover, turning a potential multi-hour interruption into just a few minutes. For organizations where application availability is critical, this feature alone can justify the use of the service.
From a networking standpoint, AWS MGN supports several connectivity topologies. Companies can use a public Internet connection for simpler migrations, but enterprise architectures generally prioritize AWS Direct Connect or a site-to-site VPN to ensure security and predictable bandwidth. This flexibility makes it possible to adapt the migration strategy to each organization’s specific constraints.
Preparing the migration: Initial configuration and technical prerequisites
The preparation phase largely determines the success of a migration project. Before any agent is installed, several prerequisites must be validated. The AWS account must be active in a region that supports Application Migration Service, and stable network connectivity must be established between the source servers and AWS. This connectivity can follow different paths depending on the organization’s security and performance requirements.
IAM configuration is the first concrete technical step. AWS MGN requires a specific IAM role with the AWSApplicationMigrationAgentInstallationPolicy policy attached. This role, usually named MGN_Agent_Installation_Role, allows the agents installed on the source servers to communicate securely with AWS services. Best practice is to use temporary credentials generated through AWS STS rather than permanent IAM keys, limiting exposure in the event of a compromise.
These temporary credentials are generated through AWS CLI or CloudShell using the aws sts assume-role command. The AccessKeyId, SecretAccessKey, and SessionToken values obtained remain valid for one hour, which is generally enough time for the initial agent installation. For migrations involving many servers over an extended period, this procedure will need to be repeated, reinforcing the value of automating this step through scripts.
Once permissions have been configured, initializing the service in the AWS console makes it possible to create the replication configuration template. This step defines the key parameters of the staging area: subnet, instance type for the replication servers (t3.small by default), EBS volume type (gp3 is recommended for a balance of cost and performance), and volume encryption. For organizations with private network connectivity to AWS, the “Use private IP for data replication” option should be enabled to avoid sending traffic over the Internet. Bandwidth throttling can also be configured to avoid saturating existing network links during production hours.
Executing the migration: Agent installation and data replication
Installing the AWS Replication Agent marks the actual start of the migration process. This operation varies slightly depending on the target operating system. On Linux servers, a single installation script downloads and configures the agent using the temporary credentials generated earlier. On Windows, the process involves downloading an installation file and running it with the same credentials.
Once the agent is installed and the credentials have been validated, the source server appears in the “Source servers” section of the Application Migration Service console. Initial replication starts automatically, synchronizing all server data to the AWS staging area. The duration of this phase varies considerably depending on the volume of data being transferred and available bandwidth. A server with 500 GB of data over a 100 Mbps connection will require several hours of initial replication, but this time is hidden because the source server remains fully operational throughout the process.
The console provides real-time replication status monitoring through the “Data replication status” field. A “Healthy” status indicates that replication is working properly, while any other status requires immediate investigation. Common causes of issues include firewall restrictions blocking communication on required ports, expired credentials, or network bandwidth saturation. Proactive monitoring of these indicators helps teams identify and resolve blockers quickly before they affect the migration schedule.
Once the initial replication is complete, the server moves into continuous synchronization mode. From that point on, only incremental changes are replicated, maintaining consistency between the source and target environments with minimal impact on bandwidth. This phase also allows teams to configure launch parameters in the “Launch settings” tab for each server. These settings define the characteristics of the final EC2 instance: instance type, security group, destination subnet, and storage options. Accurate configuration at this stage helps avoid last-minute adjustments during the cutover phase.
Validating and finalizing: Rigorous testing and controlled cutover
The testing phase is non-negotiable before any production cutover. AWS MGN allows teams to launch test instances without interrupting continuous replication from the source servers. This feature provides a fully isolated validation environment where teams can perform in-depth user acceptance testing. AWS documentation recommends allocating at least two weeks to this phase, giving teams enough time to identify and correct any potential incompatibilities.
A test instance can be launched directly from the Application Migration Service console by selecting the servers whose “Migration lifecycle” status shows “Ready for testing.” The “Launch Test Instance” action then provisions EC2 instances using the previously specified configuration. These instances contain an exact replica of the source server data at the time of launch, allowing teams to validate application functionality in the target AWS environment. Testing should cover not only application features, but also performance, network connectivity, and integration with other systems.
Once testing has been successfully completed, the cutover phase can be planned. Best practice is to coordinate this operation with all stakeholders and schedule a maintenance window during which user impact is acceptable. The cutover process follows a sequence similar to testing: selecting servers, marking them as “Ready for cutover,” then launching the cutover instances. The critical difference is that these instances become the final production servers.
During cutover, Application Migration Service synchronizes the latest changes that occurred on the source server since the beginning of the operation. Thanks to the continuous replication already in place, this final synchronization generally takes only a few minutes. Once the cutover instances have been launched and validated, the “Finalize cutover” action officially completes the migration. The source servers can then be decommissioned according to the planned schedule.
Best practices during this phase include keeping the source server operational until the cutover has been fully finalized, constantly monitoring replication statuses to detect any anomaly, and documenting each step precisely to support any post-migration investigations. Mature DevOps organizations automate these workflows using scripts that rely on the AWS MGN API, enabling large-scale migrations with minimal manual intervention.
Toward a controlled cloud migration
AWS Application Migration Service turns what was once a complex and risky project into a standardized, repeatable process. The methodology presented in this guide—rigorous preparation, progressive installation, exhaustive testing, and controlled cutover—helps DevOps teams migrate their workloads to AWS with greater confidence and reduced risk.
Organizations that succeed in their migrations tend to share several characteristics. They invest time in the preparation phase, especially network and IAM configuration. They never skip the testing period, even under schedule pressure. They document each migration carefully to build on lessons learned. And they recognize when external expertise can accelerate the process while reducing risk.
Migrating to AWS is much more than a simple hosting change. It is an opportunity to modernize infrastructure, improve application resilience, and reduce operational costs over the long term. However, the technical complexity and business stakes involved make it essential to work with qualified experts who understand not only migration tools, but also the architectural subtleties of each AWS environment.
At Unicorne, we support Quebec companies in their cloud migration projects, with a focus on architectures that combine performance, security, and cost optimization. Our AWS migration expertise and pragmatic approach help turn technical projects into real business transformation levers.
Phase 1: IAM configuration and credentials
| Task | Description |
| Create the AWS Replication Agent IAM role | Create an IAM role with the AWSApplicationMigrationAgentInstallationPolicy policy named MGN_Agent_Installation_Role through the IAM console. |
| Generate temporary credentials | Use AWS CLI or CloudShell to run aws sts assume-role and obtain AccessKeyId, SecretAccessKey, and SessionToken values, which are valid for one hour. |
Phase 2: Service initialization and configuration
| Task | Description |
| Initialize Application Migration Service | Access the AWS console, select Application Migration Service, and click “Get started.” |
| Create and configure the Replication Settings template | Configure the staging subnet, replication instance type (t3.small), EBS volume type (gp3), EBS encryption, MGN security group, private IP for VPN/Direct Connect replication, and network throttling if needed. |
Phase 3: Agent installation and replication
| Task | Description |
| Prepare AWS credentials | Have the temporary credentials ready (AccessKeyId, SecretAccessKey, SessionToken) for agent installation. |
| Install the agent on Linux servers | Copy the installation command, connect to the Linux source servers, and run the installer with the credentials. |
| Install the agent on Windows servers | Download the installation file on each Windows server and run the installer with the credentials. |
| Wait for initial replication | Monitor the MGN console until the servers appear with the “Data replication status: Healthy” status. |
Phase 4: Launch settings configuration
| Task | Description |
| Specify server details | Go to the “Source servers” section and select a server to access its details. |
| Configure Launch Settings | In the “Launch settings” tab, configure the EC2 instance type, security group, subnet, EC2 launch template, and storage options. |
Phase 5: Testing and validation
| Task | Description |
| Launch test instances | Verify that “Migration lifecycle” = “Ready for testing” and “Data replication status” = “Healthy,” then select the servers and click “Launch Test Instance.” |
| Confirm successful test launch | Confirm that the “Alerts” status displays “Launched” for each server. |
| Perform application testing | Run user acceptance testing (UAT): functionality, performance, network connectivity, and integration. A minimum of two weeks is recommended. |
Phase 6: Cutover and finalization
| Task | Description |
| Plan the cutover window | Coordinate with all relevant teams to define an appropriate maintenance window. |
| Execute the cutover | Select the servers, click “Mark as ‘Ready for cutover,’” verify the status, then click “Launch cutover instances.” |
| Confirm successful cutover | Confirm that the “Alerts” status displays “Launched” for all cutover servers. |
| Test the cutover server | Perform validation tests to confirm proper operation in production. |
| Finalize the cutover | Click “Finalize cutover” to officially complete the migration process. |
For more information
- AWS Prescriptive Guidance – “Migrate an on-premises VM to Amazon EC2 by using AWS Application Migration Service”
- AWS Application Migration Service User Guide
- AWS – “AWS Application Migration Service”
- Amazon EC2 FAQs
FAQs
How do you migrate a virtual machine to AWS EC2 with AWS Application Migration Service?
To migrate a virtual machine to AWS EC2 with AWS Application Migration Service, also known as AWS MGN, you first configure the required IAM role and replication settings, then install the AWS Replication Agent on the source server. AWS MGN continuously replicates the server to a staging area in AWS. Once replication is healthy, you can launch test instances, validate the environment, plan the cutover, and finalize the migration to production on Amazon EC2.
What is AWS Application Migration Service used for in a lift-and-shift migration?
AWS Application Migration Service is used to rehost physical, virtual, or cloud-based servers on AWS without making major application changes. In a lift-and-shift migration, AWS MGN replicates source servers at the block level, keeps them synchronized with the AWS target environment, and launches them as Amazon EC2 instances for testing and production. This helps DevOps teams move workloads to AWS while reducing manual provisioning and reconfiguration.
How does AWS MGN reduce downtime during a VM migration to AWS?
AWS MGN reduces downtime by using continuous block-level replication before the final cutover. Instead of waiting until the migration window to copy the full server, AWS Application Migration Service keeps the source server and AWS staging environment synchronized throughout the process. During cutover, only the most recent changes need to be synchronized, which can significantly shorten the interruption window for production workloads.
What should DevOps teams configure before migrating servers with AWS MGN?
Before migrating servers with AWS MGN, DevOps teams should configure network connectivity, IAM permissions, temporary AWS credentials, and the replication settings template. Key configuration elements include the staging subnet, replication instance type, EBS volume type, EBS encryption, security groups, bandwidth throttling, and private IP replication when using VPN or AWS Direct Connect. Getting these settings right early helps prevent replication failures and cutover delays.
What is the difference between the AWS MGN staging area and the final EC2 instances?
The AWS MGN staging area is a temporary environment used to receive and manage replicated data from the source servers. It contains replication resources that support the migration process. The final EC2 instances are the actual migrated servers launched from that replicated data for testing and, later, production. Keeping staging resources separate from production instances allows DevOps teams to validate the migration before committing to the final cutover.
How do you test a migrated VM before cutover in AWS Application Migration Service?
To test a migrated VM before cutover, DevOps teams can launch test instances directly from AWS Application Migration Service once the source server shows a healthy replication status and is ready for testing. These EC2 test instances contain a replica of the source server data and allow teams to validate application functionality, performance, network connectivity, security groups, integrations, and launch settings before switching production traffic to AWS.
What happens during the final cutover in an AWS MGN migration?
During the final cutover, AWS MGN synchronizes the latest changes from the source server, launches the cutover EC2 instances, and allows the team to validate the production environment. Once the migrated servers are confirmed to be working properly, the cutover is finalized in Application Migration Service. The original source servers can then be decommissioned according to the organization’s planned schedule.
Can AWS MGN be used for large-scale server migrations?
Yes. AWS MGN can be used for individual server migrations as well as larger migration programs involving many virtual machines. For large-scale migrations, DevOps teams should standardize replication settings, automate agent installation, monitor replication health, and use scripts or the AWS MGN API to manage testing and cutover workflows. This makes the migration process more repeatable and reduces the risk of manual errors.
What are the most common issues during an AWS MGN migration?
Common issues during an AWS MGN migration include expired temporary credentials, firewall rules blocking required communication, insufficient bandwidth, incorrect security group settings, poorly configured launch settings, and replication statuses that are not healthy before testing or cutover. DevOps teams should monitor the Data replication status field closely and resolve issues before moving to the next migration phase.
When should a company use AWS MGN instead of rebuilding applications on AWS?
A company should use AWS MGN when the priority is to move existing servers to AWS quickly, with minimal application changes and reduced downtime. This is especially useful for rehosting legacy applications, moving workloads out of an on-premises data center, or creating a first cloud migration phase before deeper modernization. Rebuilding or refactoring may come later, but AWS MGN helps organizations get workloads onto Amazon EC2 with a controlled lift-and-shift approach.