Lift-and-shift migrations are never glamorous. But they’re often the right first step — get out of the datacenter, then modernize in the cloud where iteration is cheap.
AWS Application Migration Service (MGN) handles the replication mechanics. Your job is making sure the environment is ready on both sides. I’ve done enough of these to know where the time actually goes — and it’s rarely in the tool itself. Here’s the checklist.
Watch the 30-second summary
Auto-generated summary — read the full article below for details.
The Global Workflow
The overall process is simple in theory:
- Open required ports
- Install MGN agent (or go agentless)
- Wait for initial sync
- Test
- Cut over
In practice, each of these hides a dozen sub-tasks.
Phase A: Prepare the AWS Account
- A1: Set up IAM roles and policies required for AWS MGN
- A2: Configure VPC, subnets, and security groups for the target environment
- A3: Set up route tables to ensure proper network segmentation and routing
- A4: Define security group rules allowing necessary traffic: HTTP, HTTPS, RDP, and replication traffic (TCP 1500)
- A5: Enable AWS Application Migration Service in the target region
Phase B: Prepare the On-Premise Environment
- B1: Ensure the VMware environment is ready for migration
- B2: Install the AWS MGN vCenter Client on the vCenter Server (for agentless replication)
- B3: Ensure network connectivity between on-premise and AWS — VPN or AWS Direct Connect
- B4: Configure firewall rules to allow traffic to AWS:
- TCP 443 (HTTPS to MGN endpoint)
- TCP 1500 (replication data)
- TCP 443 to S3 endpoint (for staging area)
Phase C: Migration Process
Agent Installation
- C1: Install the AWS Replication Agent on the source Windows VM
- C2: Decision: agent-based or agentless replication?
- Agentless: Add source servers using the AWS MGN vCenter Client
- Agent-based: Continue with the installed replication agent
Initial Sync
- C3: Wait for the initial sync to complete (this can take hours or days depending on disk size and bandwidth)
Testing
- C4: Launch test instances to verify the migration
- C5: Perform acceptance tests on test instances with a pre-established smoke test plan:
- Application starts correctly
- Network connectivity works
- DNS resolution is correct
- Storage mounts are accessible
- Services are running
- Application responds on expected ports
Post-Launch Configuration
- C6: Configure any necessary post-launch actions:
- Domain rejoining
- Agent installations (monitoring, security)
- Service account updates
- Scheduled tasks verification
Cutover
- C7: Wait for the scheduled cutover window
- C8: Confirm there is no replication lag between source and target
- C9: Stop all operational services on the source server
- C10: Launch the cutover instance
- C11: Confirm the cutover instance is functioning correctly (same smoke tests as C5)
- C12: Finalize the cutover (point DNS, update load balancers, confirm clients connect to new instance)
- C13: Archive the source server after successful migration (keep it around for 7–14 days as rollback)
Common Pitfalls
| Pitfall | Mitigation |
|---|---|
| Replication agent can’t reach AWS | Check firewall rules for TCP 1500 and TCP 443 |
| Initial sync takes forever | Verify bandwidth; consider Direct Connect for large disks |
| Test instance boots but app fails | Usually DNS or domain trust issues — check post-launch config |
| Cutover lag appears at the last minute | Stop non-essential disk I/O on source before cutover window |
| Windows activation fails post-migration | Use AWS-provided KMS server for Windows licensing |
| Security groups too restrictive | Start permissive for testing, tighten after cutover |
Key Takeaways
- MGN is a replication tool, not a migration strategy — you still own the planning
- Always test with a launched instance before scheduling cutover
- The smoke test plan must exist before the migration starts, not during
- Budget for DNS propagation and domain trust issues — they always take longer than expected
- Keep the source server running for at least a week post-cutover as a rollback option
- Automate post-launch configuration — if it’s manual, it’ll be forgotten on server #3
Any opinions in this article are my own.