MGN is the AWS-native, agent-based replication service that lifts physical, VMware, Hyper-V, and other-cloud servers into EC2 with cutover windows measured in minutes. This is the senior-engineer walkthrough: block-level continuous replication, the install-agent → test → cutover sequence, MGN vs DMS, and running a 200-server fleet without a 200-night maintenance schedule. MGN is free for a 90-day migration window per server — and a vetted CloudRoute partner can run the whole wave under AWS Migration Acceleration Program (MAP) funding, so qualifying migrations land at little-to-no cost.
MGN is the AWS-recommended service for rehosting servers onto AWS with minimal downtime. It replaces the older CloudEndure Migration and is the default "Rehost" tool in the 7 Rs playbook — the one most fleets start with before selectively replatforming or refactoring.
Mechanically, MGN does one thing extremely well: it makes a continuously-updated, bootable copy of a running server inside your AWS account, without disrupting the source. You install a small agent on the source; it reads the disks at the block level (not file-by-file) and streams every changed block to a lightweight replication server MGN runs in a staging subnet. Because it is block-level and continuous, the AWS-side copy stays within seconds-to-minutes of the source. When you are ready, MGN converts that replica — injecting the right drivers, bootloader, and agents — so a server that ran on VMware or bare metal boots cleanly as a native EC2 instance.
The headline benefit is the cutover window. A traditional re-image or backup-and-restore migration costs downtime equal to copying the entire machine plus rebuilding it — frequently many hours for a multi-hundred-GB server. With MGN, the bulk copy already happened in the background days ago and has stayed current, so cutover is just a final incremental sync and a boot — typically minutes. MGN is also source-agnostic — it rehosts physical servers, VMware and Hyper-V VMs, and other-cloud instances into EC2 alike (section V) — making it the workhorse for on-prem exits and cloud-to-cloud rehosts.
Be clear about what MGN is not: it migrates the server, but it is not a database-replatforming or refactoring tool. If your goal is Oracle → Aurora PostgreSQL, or converting a monolith into containers on EKS, MGN is the wrong instrument (see section IV). Its sweet spot is "get this machine onto AWS, as-is, with almost no downtime" — then modernize from a stable footing once you are in.
Every MGN migration, whether one server or a thousand, runs the same four-stage loop. Knowing what each stage bills, risks, and lets you reverse is the difference between a clean cutover and a rollback.
The stages are sequential per server but overlap across a fleet — while server A is in cutover, servers B through Z can be mid-replication — and the MGN console (with Migration Hub) tracks each source server’s state through the lifecycle.
You run the AWS Replication Agent installer on each source server (one command on Linux or Windows; it needs outbound connectivity to the staging subnet, typically over TCP 1500, plus access to the MGN/S3 endpoints). The agent identifies the disks and MGN registers the machine as a "source server." For large estates you script this via existing config-management (Ansible, SSM, GPO) so a wave of 50–200 servers onboards in an afternoon — and this is where partners earn their fee, since connectivity, proxy, and least-privilege IAM are where most first-time MGN projects stall.
Once the agent is live, MGN performs an initial sync — copying every block of every disk into staging EBS volumes (sync time is governed by total disk size and bandwidth; a 500 GB server over 200 Mbps is hours, a multi-TB fleet is the thing you size for up front). After that the agent switches to continuous replication: only changed blocks ship, keeping the AWS copy current with a lag usually measured in seconds. Replication runs with no reboot and negligible impact — production keeps serving traffic throughout. The staging area is deliberately cheap (low-cost EBS plus a small, auto-managed replication-server instance per few source servers), so you can leave servers replicating for days while you schedule and test, which is how you de-risk the cutover.
The step inexperienced teams skip and experienced teams never do. From the current replicated state, MGN launches a test instance into an isolated test subnet using your launch template (instance type, subnet, security groups, IAM role, tags); you boot the real server in AWS and validate that the app starts, services bind, licenses activate, and dependencies resolve. Test instances are safe for two reasons: launching one has zero impact on the source, and replication keeps running underneath so the source stays the source of truth. Launch, throw away, fix the launch template, and re-launch as many times as needed until the boot is clean — so you walk into cutover having already seen this exact machine boot in AWS.
When tests pass and the window opens, you run a cutover: MGN performs a final incremental sync (so the copy is byte-current), then launches the production instance from the same blueprint you validated. You stop application traffic on the source, let the final sync finish, boot production, and repoint DNS / load balancers / VPN routes to AWS — user-facing downtime is the final-sync-plus-boot, minutes for most servers. Afterward you mark the server "cutover complete," which tells MGN to stop replication and decommission that machine’s staging resources. Until you do that, keep the source available — it is your rollback; MGN never deletes it, so if something is wrong you repoint DNS back and re-cut later. Disciplined teams keep the source powered (but isolated) for a few days before formally retiring it.
Test instances are free insurance; cutover is the only billable, traffic-affecting step. Launching a test instance never touches the source and never stops replication — so never cut over a server you have not already booted and validated as a test instance.
A recurring confusion: test and cutover instances launch from the identical launch template. The difference is not the machine — it is what MGN does to replication and billing around it.
A test instance is a dress rehearsal: MGN boots a copy from the current replication state into your test subnet, leaves continuous replication running, and does not change the source’s lifecycle beyond "ready for testing." Stand one up Tuesday, validate, terminate, fix the launch template, stand up another Wednesday — repeated freely, nothing irreversible. A cutover instance is the real thing: MGN runs a final sync, launches production, and once you confirm cutover, stops replication and tears down that server’s staging footprint — so the moment for final validation is before you finalize, not after.
The practical fleet pattern: run a test wave across a migration group first and fix every launch-template issue (wrong instance family, missing security group, a service needing a post-boot script), then schedule the cutover wave. By then every launch template is known-good and the change window is boring — which is the goal.
The most common MGN mistake is trying to migrate a database with it (or an app server with DMS). They solve different problems — and on most migrations you use both: MGN for the app/web tier, DMS for the data tier.
MGN migrates servers. It replicates whole disks block-by-block, carrying everything on the machine as-is: the OS, the app, config, and incidentally any database files on those disks. That makes it perfect for app servers, web servers, batch and license boxes, and "homogeneous" database moves where you keep the same engine and just want the box on EC2. What MGN does not do is change the data: same engine, same version, same schema.
DMS (AWS Database Migration Service) migrates data between database engines, including heterogeneously, with the source online. Paired with the Schema Conversion Tool (SCT), it converts schema and code objects from source to target — Oracle → Aurora PostgreSQL, SQL Server → Aurora MySQL — then migrates the rows and can keep change-data-capture (CDC) running so source and target stay in sync until the application cuts over. DMS lands data into a managed service (RDS, Aurora, Redshift, DynamoDB), not onto a server you then have to patch.
The decision rule is blunt: are you keeping the database engine, or changing it? Keeping it (and you want the box on EC2): MGN, the whole server comes along. Changing engines, or moving onto a managed service like Aurora or RDS: DMS + SCT, because only DMS knows how to translate and replicate the data itself. A typical three-tier migration runs MGN on the web/app servers and DMS on the database in parallel, then cuts both over together.
Server (OS + app + files), stack as-is → MGN. Database with an engine change or a move onto a managed service (Aurora / RDS / Redshift) → DMS + SCT. Most migrations use both. See the sibling guide: AWS Database Migration Service (DMS).
MGN’s agent-based, source-agnostic design is what makes it the default tool for data-center exits and VMware estates — you need outbound connectivity and the agent, not matching infrastructure on AWS.
Because MGN reads block devices via an agent in the guest OS, it does not care whether those blocks live on a VMware vSphere datastore, a Hyper-V virtual disk, a bare-metal SAN LUN, or another cloud’s volume — the same agent and test/cutover workflow apply in every case. For VMware specifically, you can rehost individual VMs into native EC2 without first standing up VMware Cloud on AWS — MGN takes the guest, not the hypervisor.
That said, there is a fork for VMware shops. To exit VMware entirely and run on native EC2 (often to drop licensing), MGN is the path — rehost guest-by-guest. To keep operating in VMware for a period (same vCenter, same tooling, least re-training), VMware Cloud on AWS — or AWS Outposts for an on-prem-with-AWS-control-plane footprint — is the relocate play, and MGN is not involved. Partners scope this in the assessment, since licensing math and operational comfort usually decide it.
For on-prem fleets the gating factor is bandwidth, not the tool. Initial replication of a large estate over a constrained link is the long pole; partners provision a Direct Connect or temporary high-bandwidth path, stage replication in waves so the link never saturates, and use AWS DataSync or Snowball for cold bulk data. That is the standard runbook — see the sibling guide: on-premise to AWS.
Migrating five servers with MGN is a console exercise; migrating five hundred is a program — and MGN has the constructs to run it without a five-hundred-night maintenance schedule.
The organizing primitives are applications and waves: you group source servers into applications (the three boxes behind "Billing," the four behind "Customer Portal"), then group applications into waves you migrate together — so you cut over an entire dependency set in one window (app server, worker, and cache together) instead of orphaning a server whose database has not moved. At scale you drive the launches through launch templates (encoding target instance type, subnet, security groups, IAM profile, and tags so a 200-server wave launches consistently) and post-launch actions (SSM automations that, after each boot, install the CloudWatch/SSM agents, join the domain, harden, and fire a validation test) — turning "rehost" into "rehost-and-baseline" with no human touching each box. AWS Migration Hub ties it together with portfolio-level tracking and Application Discovery Service dependency mapping.
Right-sizing is the other scale lever. MGN can launch the target matching the source, but sources are frequently over-provisioned, so launch right-sized from observed utilization — fed by Migration Hub and Compute Optimizer — rather than importing years of waste into your AWS bill on day one. See the AWS landing zone guide for the account/network foundation a wave lands into.
| Construct | What it does | Why it matters for a large fleet |
|---|---|---|
| Application | A group of servers that move together | Cut over a dependency set in one window, not piecemeal |
| Wave | A group of applications scheduled together | Sequences the program into manageable maintenance windows |
| Launch template | Target instance type, subnet, SGs, IAM, tags | Consistent, right-sized launches across hundreds of servers |
| Post-launch actions | SSM automations run after each boot | Agents, domain-join, hardening, validation — no manual touch |
| Migration Hub | Portfolio view + discovery + tracking | Sizing, dependency mapping, and status across the whole estate |
MGN gets you onto AWS as-is; the value comes from what you do next. The honest sequencing is rehost first (fast, low-risk, stops the data-center bleed), then modernize selectively from a stable base.
Once a server is a native EC2 instance, the full AWS toolbox opens — much of it without re-architecting anything. The immediate, low-effort wins are operational and can be applied via post-launch actions: enroll the instance in SSM for patching and shell-free access, ship logs/metrics to CloudWatch, schedule AWS Backup, and bring it under the same landing-zone guardrails (SCPs, GuardDuty, centralized logging) as the rest of your accounts — so "rehosted" and "compliant + observable" happen in one motion.
The deeper modernization — the "replatform" and "refactor" Rs — is where you choose your battles. Common selective moves after a rehost: lift a self-managed database onto RDS or Aurora (via DMS) to shed patching toil; move a stateless web tier behind an ALB + Auto Scaling group or into containers on ECS / App Runner; replace cron boxes with EventBridge + Lambda. The point is you do this after you are on AWS and stable — not as a precondition for migrating, which is how migrations slip a year. And because MAP funds both the migrate phase and subsequent modernization, this partner-led optimization is part of the same funded engagement, not a separate budget line.
MGN has an unusually founder-friendly pricing model, and it stacks with AWS’s migration funding — so a qualifying migration can land at little-to-no net cost.
The MGN service itself is free for a 90-day migration window per source server — no per-server license fee within that window. You pay only for the ordinary AWS infrastructure underneath: the low-cost staging EBS volumes and snapshots, the small replication-server EC2 instances, and data transfer in. These are real but modest, and they fall away once you finalize cutover and MGN releases the staging footprint; after cutover you pay only for the production EC2 instances and their EBS — your normal AWS bill.
Layered on top is the funding mechanism that changes the economics. The AWS Migration Acceleration Program (MAP) runs in three phases — Assess (a TCO/readiness analysis, frequently free), Mobilize (pilot + landing zone), and Migrate & Modernize (production waves) — with AWS providing partner-delivered funding scaled to the migration size. The partner is paid through MAP and a meaningful share of the migration/modernization cost is credited back, so a qualifying customer migrates at little-to-no out-of-pocket cost. MAP ties directly to the broader AWS credits picture — see the cornerstone reads below.
The honest framing matters. MAP funding applies to qualifying migrations — typically those with a meaningful post-migration AWS-spend commitment — not every workload. Where it applies, CloudRoute routes you to a partner who runs the wave under MAP funding and you pay little-to-nothing; where it does not, you still get a vetted partner who runs the cutover, rather than learning MGN on your production estate.
CloudRoute routes you to a vetted AWS partner who runs the MGN migration end-to-end; for qualifying migrations MAP funds the engagement so the customer pays little-to-no cost. The partner is paid through MAP and pays CloudRoute a commission — you don’t see an invoice. Start at CloudRoute for migrations.
These three get conflated constantly. MGN and a manual rehost solve the same problem (move a server) very differently; DMS solves a different problem (move data between engines):
| Variable | AWS MGN (Application Migration Service) | Manual rehost (image / backup-restore) | AWS DMS (+ SCT) |
|---|---|---|---|
| What it moves | Whole servers (OS + app + files), block-level | Whole servers, copied/rebuilt by hand | Data between databases (incl. across engines) |
| Cutover downtime | Minutes (final incremental sync + boot) | Hours+ (full copy + rebuild during the window) | Near-zero with CDC keeping target in sync |
| Source impact during prep | None — agent replicates with no reboot | Varies; often needs source quiesced to image | Low — reads source DB online |
| Test before cutover | Yes — unlimited throwaway test instances | Hard — usually one shot in the window | Yes — validate target DB before app cutover |
| Heterogeneous DB (engine change) | No (carries DB as-is, same engine) | No | Yes — SCT converts schema, DMS migrates + CDC |
| Rollback | Repoint to still-running source | Difficult once the window is consumed | App stays on source until you cut over |
| Best for | Lift-and-shift of physical / VMware / cloud servers, large fleets | A handful of simple, low-risk servers; one-offs | Oracle→Aurora, SQL Server→Postgres, managed-DB moves |
| Service cost | $0 for a 90-day window/server (+ underlying infra) | $0 tooling, high labor + downtime cost | Pay for replication instance + target; SCT free |
Situation: A hard deadline (colo lease expiry in ~5 months) forced a data-center exit, but the team had never run an AWS migration and could not absorb a 140-night maintenance schedule. The estate mixed Windows and Linux app/web servers plus three self-managed SQL Server databases. Leadership wanted off VMware entirely (to drop licensing) but was nervous about cutover risk on round-the-clock production logistics systems.
What CloudRoute did: Routed within 24 hours to an AWS Advanced-tier partner with a MAP track record. The partner ran an AWS-funded MAP Assess (TCO + Application Discovery Service dependency mapping), then a Mobilize phase standing up a landing zone and pilot wave. They installed the MGN agent fleet-wide via SSM/GPO, grouped the 140 servers into 9 applications across 4 waves, and ran a full test-instance pass per wave to fix launch templates before any cutover. The three SQL Server databases moved via DMS + SCT (kept on SQL Server, onto RDS) in parallel, so each wave cut app servers and their database together. The whole engagement ran under MAP funding.
Outcome: All 140 servers cut over across 4 weekend windows; per-server downtime averaged under 10 minutes. Zero rollbacks — sources were kept isolated-but-available for 5 days as insurance, then retired. The expiring colo was evacuated 6 weeks ahead of lease expiry. MAP funding covered the partner-led engagement and credited a large share of the migration + initial modernization spend, so the customer’s net out-of-pocket was effectively $0. CloudRoute’s commission was paid by the partner from MAP engagement funding.
fleet: 140 servers · waves: 4 · avg cutover downtime: <10 min · rollbacks: 0 · colo exit: 6 weeks early · net cost to customer: ~$0 (MAP-funded)
CloudRoute routes you to a vetted AWS partner who runs the entire MGN wave: agent rollout, test instances, cutover, and post-launch baseline. For qualifying migrations, AWS MAP funds it and the customer pays little-to-nothing. No 2 a.m. solo cutover.