AWS MGN: The Ultimate Lift-and-Shift Migration Solution

Cloud migrations are a critical aspect of modern IT infrastructure, ensuring scalability, reliability, and cost optimization. Whether you're transitioning workloads across AWS regions for disaster recovery, performance optimization, or compliance, AWS Application Migration Service (AWS MGN) simplifies the process with minimal downtime.

In this article, I will explain a structured and efficient approach to migrating an AWS EC2 instance from one region to another using AWS MGN. Let’s get started!

AWS MGN Architecture:

Link: https://docs.aws.amazon.com/mgn/latest/ug/mgn-connector-architecture.html

Step 1: Setup AWS?MGN

·?? Login to AWS and go to AWS MGN service.

·?? Choose Get Started and select the target AWS Region where you want to migrate your workloads.

·?? Create a Replication Settings Template:

·?? Select a staging area subnet (used to temporarily store data).

·?? Choose the instance type for replication servers (default: t3.small).

·?? Enable encryption for security.

·?? Click Create Template.

Step 2: Add Source Servers for Migration

1. Install AWS MGN Replication Agent on your existing servers:

·?????? In AWS MGN, select Add Servers.

·?????? Provide the OS type, IAM credentials, and Replication preferences.

·?????? Copy the installation command and run it on your source server.

·?????? The source server appears in AWS MGN once the installation is complete.

2. Monitor the replication:

·?????? AWS MGN will start syncing data.

·?????? Wait until 100% replication is completed.

As part of the proof of concept (POC), I provisioned a server in the North Virginia (us-east-1) region, utilizing the specified AMI. The instance was launched in a public subnet, with a security group configured to permit incoming HTTP traffic over TCP port 80.

First, create an IAM user with the below permissions: Create a New User:

??? Click IAM Users → Add users.

??? Enter Username: AWS-MGN-Migration

??? Select Access Key - Programmatic Access (needed for AWS CLI/SDK)

Set Permissions:

??? Choose to Attach policies directly.

??? Add the following AWS Managed Policies:

?????????????????????? AWSApplicationMigrationFullAccess

?????????????????????? IAMFullAccess

?????????????????????? EC2FullAccess

?????????????????????? S3FullAccess (for storing logs)

?????????????????????? CloudWatchLogsFullAccess (for monitoring logs)

Generate IAM Access Key & Secret Key

1.???? Go to IAM Console → Users.

2.???? Select AWS-MGN-Migration user.

3.???? Navigate to the Security Credentials tab.

4.???? Click Create Access Key

5.???? Select Use Case: Choose Programmatic access.

6.???? Copy & Save the Access Key ID and Secret Key

Download the .csv file (IMPORTANT: You won’t see the secret key again)

Go to the target region MGN, and select the source server (Add server option)

Create Role for EC2 and attach to ec2 source server: Attach AWS Managed Policies

Attach the following AWS Managed Policies for AWS MGN:

??? AWSApplicationMigrationFullAccess

??? AmazonSSMManagedInstanceCore (For SSH via AWS Systems Manager)

??? AmazonEC2FullAccess

After running command 1:

If the role is attached to ec2 use the below command, Your AWS Access Key and Secret Key should never be exposed in plain text. Instead, use IAM Roles attached to EC2, so you don’t need to pass credentials manually.

Check if the ec2 role is attached by running this command:? curl https://169.254.169.254/latest/meta-data/iam/security-credentials/

If yes then run the below command:

sudo chmod +x aws-replication-installer-init

sudo ./aws-replication-installer-init --region ap-southeast-1 --no-prompt

Source EBS attached to the replication server.

Target region MGN: During Initial Sync, the service will perform various actions:

· Creating Firewall Rules

· Spinning Up the Replication Server

· Authenticating with AWS MGN

· Downloading Replication Software

· Creating Staging Volumes

· Establishing Communication between Agent & Replication Server

1. After installing the agent, the source server will appear in the AWS MGN console but will initially be marked as not ready.

2. During this phase, the source server begins its initial synchronization with the replication server in AWS.

3. Once replication is complete, the server’s status will update to ready for testing.

4. At this stage, testing can be performed to ensure the server functions as expected.

5. If testing is unsuccessful, you can either reset the server to ready for testing or proceed by marking it as ready for cutover.

6. Marking the server as ready for cutover will move it to the next phase, where you can follow similar steps to finalize the cutover process.

7. When finalizing the cutover, AWS MGN will remove the replication agent from the source server and delete any temporary AWS resources, including EBS snapshots and volumes, that were used during migration.

Step 3: Configure and Launch a Test Migration

1. Set up a?Launch Template: Go to?Launch Settings. Modify the?EC2 launch template?(change instance type, security groups, key pair, etc.). Save the?default launch template.

2.?Launch a Test Instance:In AWS MGN, choose?Launch Test Instances.Confirm that the test instance is?running properly.SSH/RDP into the test instance and?validate the setup.If everything works fine,?terminate the test instance?and mark the source server as?Ready for Cutover.

Note:You must configure your launch settings before launching test/cutover instances.You can alter launch settings after launching a test/cutover instance but you must launch a new instance for these settings to take effect.

EC2 Launch template: Best Practice: Select "Don't Include AMI" ?

• AWS MGN automatically generates an AMI for the migrated instance.
• Including an AMI in the launch template may cause conflicts because AWS MGN already captures the source system state.
• The AWS MGN-created AMI includes the exact disk image and system settings from the source EC2.

Every time you change an EC2 Launch Template, a new version is created. In order for Application Migration Service to use the new version you created; you must mark it as "Default".

Now launch test server.

Conversion Instance is launched:

What is a Conversion Instance in AWS MGN?

A Conversion Instance in AWS Application Migration Service (AWS MGN) is a temporary EC2 instance used during the migration process to convert replicated source server data into a bootable Amazon Machine Image (AMI) before launching the final migrated instance in the target AWS environment.

Conversion server is terminated, and Migrated source server launched.

After your test instances has been launched, on the migration dashboard tab confirm the launch status reports?Succeeded. If testing was successful then choose Mark as “Ready for Cutover”.

Else Revert to “ready for testing” (this might include changing instance type or IP address configurations). After testing you can mark as ready for cutover.

Test server is terminated.

You may proceed with cutover if :?Migration lifecycle: Ready for cutover

Data replication status: Healthy

Launch Cutover Instance:

Step 4: Perform Final Migration (Cutover)

Launch Cutover Instance:

In AWS MGN, go to?Source Servers?>?Launch Cutover Instances.

AWS will create a copy of your servers in the?new AWS region.

Monitor the?cutover process.

2. Validate the Cutover:

Check if the instance?runs correctly?in the new AWS region.

Test application connectivity.

3. Finalize the Migration:

If everything is working, go to?AWS MGN?>?Finalize Cutover.

Once finalized, AWS?disconnects the old servers.

Cutover Instance launched:

For reference: Snapshot and volumes are getting created.

Note: How AWS MGN Creates Snapshots and Volumes & Uses Them for Cutover Instances

1?. Replication Phase:

AWS MGN Agent continuously replicates block-level data from the source server to the staging area in the target AWS Region.

The replicated data is stored in Amazon EBS volumes attached to a Replication Server.

2?. Snapshot Creation:

Once initial synchronisation is complete, AWS MGN automatically creates EBS snapshots from the replicated volume.

These snapshots are stored in Amazon S3 (as part of AWS’s snapshot storage system).

3?. Launch of Test or Cutover Instance:

When you launch a test or cutover instance, AWS MGN:

• Creates a new EBS volume from the latest snapshot.
• Attaches the volume to the new EC2 instance.
• Uses the volume as the root disk for the launched instance.

4?. Final Cutover:

After successful testing, AWS MGN launches the cutover instance using the latest replicated volume and snapshot.

The Replication Server is terminated as it is no longer needed.

The source server is disconnected from AWS MGN.

If cutover was successful then you may?Finalize cutover. Else you may Revert to?“Ready to cutover”?instead.

If cutover was successful, then you may?finalize cutover. Else you may revert to?“Ready to cutover”?instead.

Finalize cutover:

This will cause all replicated data to be discarded & all AWS resources used for data replication to be terminated.

5. Cleanup After Final Cutover

Now that you’ve cut over your source server, you must clean up the server from the console because no further actions are required.

You may find following indicators to take this ahead : Migration lifecycle: Cutover Complete

Data replication status : Disconnected

Next step : Mark as Archived

Replication server terminated, only source server in target region running.

Delete These AWS Resources to Avoid Charges After Migration with AWS MGN

1. Terminate Source Server from AWS MGN Console
2. Archive Source Server in AWS MGN
3. Delete Replication Servers (Staging area instances)
4. Delete Staging EBS Volumes & Snapshots
5. Delete Replication Settings in AWS MGN
6. Remove Old Security Groups, IAM Roles, and Policies (if not needed)
7. Detach & Delete Internet Gateway (IGW) if created for migration
8. Delete VPC & Subnets (only if not needed for other workloads)

Source server is running is source region:

To check on the migrated server. # OS Details Check

cat /etc/os-release

uname -r

uname -a

arch

lsb_release -a

?

# Network Checks

hostname -I

ip route show

nslookup google.com

dig google.com

ping -c 3 8.8.8.8

?

# Firewall & Security Group Checks

sudo iptables -L -n -v

?

# Storage & Disk Checks

lsblk

df -h

lsblk | grep disk

sudo fsck -y /dev/xvda1

df -h /

?

# Performance Monitoring

htop

top

ps aux --sort=-%cpu | head -10

sudo journalctl -xe

dmesg | tail -20

systemd-analyze blame

?

# Application & Service Checks

systemctl list-units --type=service --state=running

sudo tail -f /var/log/syslog

sudo cat /var/log/auth.log | grep sshd

sudo systemctl status mysql

sudo systemctl status apache2

?

# AWS Specific Checks

curl https://169.254.169.254/latest/meta-data/iam/security-credentials/

Source server:

Migrated server:

Now terminate the source and migrated server.

MGN: Mark source server as archive. What Does "Archive Source Server in AWS MGN" Mean?

In AWS Application Migration Service (MGN), archiving a source server means removing it from the MGN console after migration is complete. This prevents further replication and stops unnecessary charges.

Conclusion:

AWS MGN simplifies lift-and-shift migrations, ensuring seamless, automated, and low-downtime workload transitions across AWS regions. By automating replication, testing, and cutover, it minimizes complexity and enhances efficiency. Ideal for scalable, cost-effective cloud migrations, AWS MGN accelerates adoption while maintaining security and performance. Have you used AWS MGN? Share your thoughts!

Unlock expert cloud strategies at sagarcloudtech.com or read my latest insights on Medium.