Practical Lift-and-Shift Migration with AWS Application Migration Service (MGN)
A practical walkthrough of the lift-and-shift migration procedure, from agent installation to cutover. It also explains design considerations and network configuration.
How MGN Works and Its Benefits
AWS Application Migration Service (MGN) is a service for lift-and-shift migration of servers from on-premises or other clouds to AWS. Since June 8, 2026, it has been offered under the name AWS Transform MGN. When you install a lightweight replication agent on the source server, it keeps replicating the disk contents to AWS at the block level in real time. Because the source server keeps running normally during replication, the downtime caused by the migration is limited to a few minutes at cutover. Whereas the earlier Server Migration Service (SMS) used snapshot-based periodic synchronization, MGN brings the RPO close to zero through continuous replication.
Migration Steps - From Agent Installation to Cutover
The migration proceeds in four phases. The first phase is installing the agent. When you install the AWS Replication Agent on the source server, the server appears in the MGN console and the initial synchronization starts. The second phase is configuring the launch settings. In the launch template, you define the instance type, VPC, subnet, security groups, and IAM role. The third phase is the test launch. You launch a test EC2 instance and verify application behavior, network connectivity, and performance. If there are problems, you can fix the launch settings and test again. The fourth phase is the cutover. You run the final data synchronization and launch the production EC2 instance. You direct traffic to the new environment by switching DNS or changing the load balancer settings.
Design Considerations
Replication requires a stable network connection from the source server to AWS. As a bandwidth guideline, an initial synchronization of a 100 GB disk within 24 hours requires about 10 Mbps. A connection through Direct Connect or VPN is recommended. A lightweight EC2 instance (around t3.small) and EBS volumes are created automatically in the staging area for replication. This cost is around a few dollars per month per source server. In large-scale migrations, if you already use Migration Hub (which stopped accepting new customers on November 7, 2025), you can centrally manage migration progress, group servers by application, and cut over interdependent servers at the same time.
MGN Pricing
MGN itself is free to use, and no additional charges apply for installing the replication agent or for continuous replication. The cost is the charge for the staging area for replication (lightweight EC2 instances and EBS volumes). Launching test instances incurs EC2 charges at the target specifications, so you terminate them promptly once testing is complete. After cutover, you stop replication and delete the staging area resources to eliminate unnecessary costs.
Lift and Shift as a Strategy
Lift and shift is a migration strategy that moves servers to the cloud almost as they are, without significantly rebuilding them. Because it does not involve modifying applications, it can keep the risk and duration of the migration down, and it becomes the fastest way to reach the cloud. It is effective in situations such as when a data center contract is about to end or when you want to move to the cloud reliably first. Rebuilding for cloud native can be done step by step after the migration is complete and stable. The approach of prioritizing the move first and improving afterward, rather than aiming for perfect optimization from the start, makes a realistic migration possible.
Validation Through Test Launches
A major advantage of MGN is that you can verify behavior at the migration target before switching production. You launch a test instance from the replicated data and confirm that the application runs correctly on AWS. Because this validation can be done without affecting the source server, you can test repeatedly without stopping business operations. You check network connectivity, integration with dependent systems, performance, and so on by actually running them. By testing thoroughly before the production switchover, you can prevent unexpected trouble on the day of the switch and approach the cutover with confidence.
Cutover and Rollback
The switchover to production (cutover) is the climax of the migration. Because MGN continuously replicates the source data, you can migrate from a state synchronized up to just before the switch and keep downtime short. For the timing of the switch, you choose a time window with little impact on business. After the switch, you promptly check whether the application is working normally. In case a problem does occur, it is important to prepare a procedure that lets you return to the original environment. By putting in place a planned cutover and preparations for a rollback, you can complete the migration safely.
Modernization After Migration
Once the migration is complete through lift and shift, you use it as a foothold to draw out the benefits of the cloud. First, you rightsize instances based on actual usage to lower costs. Next, you proceed step by step, in order of priority, with modernization such as moving databases to managed services or replacing processing with containers or serverless. By starting with what has the greatest effect instead of rebuilding everything at once, you can keep risk down while continuously reducing operational burden and costs. It is important to position the migration not as the goal but as the starting point for optimization.
Summary
As the standard tool for lift-and-shift migration, MGN achieves migration with minimal downtime through agent-based continuous replication. Simply installing the agent on the source server starts block-level replication, and you run pre-migration behavior validation by launching test instances. Downtime at cutover is typically a few minutes, and it also supports large-scale migration projects.
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.
If this page and the official documentation disagree, treat the official documentation as authoritative.