Home / AWS

AWSRunbookIntermediate

Transformation: rehost VMware and physical servers to AWS with Application Migration Service (MGN)

Run a wave-based lift-and-shift to EC2 with AWS Application Migration Service. Install replication agents, set launch templates, run test launches, cut over with minimal downtime and finalise, plus the post-migration clean-up most teams forget.

Deepak Bhardwaj2 min read

Applies toAWS Application Migration Service (MGN), AWS Migration Hub, Windows and Linux source servers (VMware, Hyper-V, physical, other clouds)

How MGN works

An agent on each source server does block-level continuous replication into a staging area subnet in your AWS account (small replication servers plus low-cost EBS). At test or cutover time, MGN converts the replicated disks and launches EC2 instances from them. Downtime is only the final cutover.

1. Prepare the account

  • Initialise MGN in the target region (creates IAM roles and the default replication template).
  • Create a staging subnet with outbound TCP 443 to MGN endpoints and inbound TCP 1500 from source servers for replication data.
  • Plan target VPCs, subnets and security groups per wave.
aws mgn initialize-service --region eu-west-1
aws mgn describe-replication-configuration-templates --region eu-west-1

2. Install the agent

Create an IAM user or role credentials with the AWSApplicationMigrationAgentInstallationPolicy, then on each source server:

# Linux
wget -O ./aws-replication-installer-init https://aws-application-migration-service-eu-west-1.s3.eu-west-1.amazonaws.com/latest/linux/aws-replication-installer-init
sudo chmod +x aws-replication-installer-init
sudo ./aws-replication-installer-init --region eu-west-1 --no-prompt
# Windows (download AwsReplicationWindowsInstaller.exe from the regional bucket first)
.\AwsReplicationWindowsInstaller.exe --region eu-west-1 --no-prompt

Initial sync time depends on disk size and bandwidth. Watch for Healthy data replication in the console.

Tip

Use temporary credentials for agent installation and delete them after the wave. They only need install permissions.

3. Launch settings

Per server, set the EC2 launch template: instance type (start with right-sizing recommendations), subnet, security groups, IAM instance profile (include SSM), tags, and licence handling (BYOL vs. AWS-provided Windows licences).

4. Test launch (every server)

  1. Launch test instances from the console or aws mgn start-test --source-server-ids s-abc123.
  2. Validate: boot, services, app smoke test, connectivity to dependencies.
  3. Mark as Ready for cutover; terminate test instances.

5. Cutover

  1. Agree the downtime window and stop the application on the source.
  2. Wait for replication lag to reach zero.
  3. aws mgn start-cutover --source-server-ids s-abc123
  4. Update DNS, load balancers, firewall rules; run the smoke test.
  5. Finalise cutover — this stops replication and removes staging resources for the server.

6. After migration

  • Archive source servers in MGN; decommission originals after the soak period.
  • Remove VMware Tools and old agents; install the CloudWatch agent and enable AWS Backup.
  • Right-size with Compute Optimizer after two to four weeks.
  • Use post-launch actions (SSM documents) to automate agent installs on future waves.

Checklist

  • Staging subnet ports (443 out, 1500 in) open
  • Waves grouped by application with owners and rollback (restart source)
  • Test launch passed for every server
  • Cutover finalised and staging resources cleaned
  • Backup, monitoring and patching on day one