AWS Application Migration Service (MGN)

Automated lift-and-shift service that replicates whole servers into AWS and relaunches them as EC2 instances.

Verified against AWS documentation · 2026-09-09

Key facts

01Rehost, don't rewrite — an agent copies each disk block-by-block into a staging area, then MGN converts the replica into a bootable EC2 instance
02The source server keeps running the whole time; replication is continuous, so cutover is a final sync and a DNS switch — minutes, not a lost weekend
03Test instances launch from the replica as often as you like without touching the source, which stays live as your rollback
04Limits: free for 2,160 replication-hours (~90 days) per server, 150 concurrently replicating servers by default, x86 Windows/Linux only
05Reality check: AWS renamed this "AWS Transform MGN" in 2026 — same API, same service. The CLF-C02 exam guide still calls it AWS Application Migration Service

Phrases and scenarios that point here.

"Lift and shift", "rehost", "migrate as-is", "no application changes", "minimal downtime"
Physical servers, VMware, Hyper-V, or another cloud need to become EC2 instances → MGN
Data center lease expiring, hundreds of mixed servers, no time to re-architect → MGN
Must prove the app runs on AWS before committing → MGN test instances, then cutover

Moving database contents, or switching engines (Oracle → Aurora) → DMS
Only tracking migration progress across tools and teams → Migration Hub
Inventorying and dependency-mapping the data center first → Application Discovery Service
Copying files or objects rather than whole servers → DataSync, or Snow Family when the pipe is too slow
Keeping a warm standby for disaster recovery instead of a one-way move → Elastic Disaster Recovery (DRS)

01Data center lease ends in six months and 300 mixed Windows/Linux VMs have to be on EC2 before the doors close — no budget to rewrite any of them
02A vendor application nobody has the source code for, built by people who left years ago; the running server is the only documentation, so you move the server itself
03Leaving another cloud provider — replicate the VMs into AWS while they keep serving live traffic, then cut over on a quiet Sunday night
04Post-acquisition consolidation: moving EC2 instances between Regions or into the parent company's account using the same agent-based flow
05Rehearsing the cutover — launch test instances, let the app team log in and break things, delete them, repeat, all without the source server noticing

01Free per source server for 2,160 replication-hours (~90 days continuous); the clock starts when the agent is installed, not when you first log in
02Past the free window you pay per replication-hour per server still replicating — so it's slow migrations that cost money, not big ones
03The staging area is never free: the lightweight replication EC2 instances and the EBS volumes holding the replica bill at normal rates from day one, free period included
04Test and cutover instances are ordinary EC2 + EBS charges — a long test phase means paying for two copies of the fleet at once
05Finalizing cutover stops replication and deletes staging resources; the classic surprise bill is forgetting to finalize servers you already migrated