AWS Transform MGN (formerly Application Migration Service): the lift-and-shift engine, and who runs it.
AWS Transform MGN, formerly AWS Application Migration Service, 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 large fleet without hundreds of maintenance nights. Each source server gets 2,160 free hours of MGN use, and for a qualifying migration a matched AWS partner can file MAP funding.
- AWS Transform MGN (formerly AWS Application Migration Service, and before that CloudEndure Migration) is AWS’s primary rehost ("lift-and-shift") tool. You install a lightweight agent on each source server; MGN continuously replicates the whole disk at the block level into a low-cost staging area in your AWS account, then converts and boots the replica as an EC2 instance. Cutover downtime is just the final sync + boot: minutes, not the hours a manual re-image takes.
- The workflow is always the same four moves: install agent → continuous replication stays current → launch test instances (isolated subnet, repeatable, zero impact on the source) → cutover (final sync, boot production, repoint DNS). Test and cutover use the same blueprint; cutover is the only step that stops replication and bills the running instance. Always test before you cut.
- AWS gives each source server 2,160 free hours of MGN use (90 days of continuous replication); you still pay for the staging EBS, snapshots, replication-server EC2 and data transfer underneath. MGN moves servers: the OS, apps and files. For engine-changing database moves (Oracle→Aurora, SQL Server→PostgreSQL) you want DMS + the Schema Conversion Tool. For a qualifying migration, an AWS partner can file MAP funding: typically $50K to $150K for startups. Depends on the workload; AWS approves.
IWhat AWS Transform MGN actually is
MGN is the AWS-recommended service for rehosting servers onto AWS with minimal downtime. AWS now calls it <a href="https://aws.amazon.com/application-migration-service/">AWS Transform MGN</a> (formerly AWS Application Migration Service); it replaced 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.
IIThe four moves: agent → replication → test → cutover
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.
Stage 1 — Install the replication agent
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.
Stage 2 — Continuous, block-level replication
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.
Stage 3 — Launch test instances
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.
Stage 4 — Cutover
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.
IIITest instances vs cutover instances — the same blueprint, two intents
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.
IVMGN vs DMS — pick the right tool, or run both
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).
VMGN for VMware, Hyper-V, and on-prem fleets
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.
VIRunning a large fleet: waves, groups, and automation
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 |
VIIPost-launch modernization: rehost first, then improve
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.
VIIIWhat MGN costs, and when AWS funding applies
MGN has a founder-friendly pricing model. Separately, AWS can fund a qualifying migration through MAP.
AWS's MGN FAQ says each source server gets a free period of 2,160 hours (90 days when used continuously), starting when you install the replication agent; after that, replication is billed per hour. During and after the free period you pay for the AWS infrastructure underneath: staging EBS volumes and snapshots, the small replication-server EC2 instances, and resources for test and cutover instances. After cutover you pay for production EC2 and EBS, your normal AWS bill.
The AWS Migration Acceleration Program (MAP) is how AWS funds qualifying migrations, structured in three phases: Assess, Mobilize and Migrate & Modernize. An AWS partner files MAP funding for the migration, and AWS decides. For startups, partner-filed funding is typically $50K to $150K. Depends on the workload; AWS approves.
MAP is not a blank check: the migration has to qualify. Where it does not, you still get a vetted partner who runs the cutover, rather than learning MGN on your production estate.
CloudRoute matches you with one vetted AWS partner who runs the MGN migration end to end and files MAP funding when the move qualifies. CloudRoute is free for startups; partners pay CloudRoute a monthly membership plus 10% of AWS-approved funding. Start at CloudRoute for migrations.
MGN vs manual rehost vs DMS — when each is the right tool
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 | 2,160 free hours per server (+ underlying infra) | $0 tooling, high labor + downtime cost | Pay for replication instance + target; SCT free |
How a match works (example)
- You tell us about the work
You fill in a short form: what you run today, what you want to move, test or build, your stage and your region.
- We pick one partner
We read your answers and pick one vetted AWS consulting partner that fits the work, the stack and the region. We reply within 24 hours; your matched partner reaches out within 5 business days.
- The partner checks MAP funding
Your matched partner scopes the migration with you. Then it checks whether the move qualifies for MAP (Migration Acceleration Program) funding. MAP is for teams that are not on AWS yet.
- The partner files, AWS decides
If the work qualifies, the partner files the funding request with AWS. AWS reviews it and decides. The amount depends on the workload.
- You pay nothing
CloudRoute is free for startups. Partners pay CloudRoute a monthly membership plus 10% of AWS-approved funding.
AWS Activate credits are separate, and you apply for them yourself. Use Activate Founders if no investor backs you. Use Activate Portfolio with the Org ID or invite from your VC, accelerator, incubator or angel group if it is an Activate Provider. A consulting partner cannot apply for Activate on your behalf.
Common questions
What is the difference between AWS Transform MGN, Application Migration Service and CloudEndure Migration?
How much downtime does an MGN cutover actually cause?
When should I use DMS instead of MGN?
Can MGN migrate VMware and physical (bare-metal) servers?
How much does AWS MGN cost, and can AWS fund the migration?
How do I run MGN across hundreds of servers without a huge maintenance schedule?
Want your servers on AWS, with the migration run for you?
CloudRoute matches you with one vetted AWS partner who runs the MGN wave: agent rollout, test instances, cutover and post-launch baseline. For a qualifying migration the partner files MAP funding: typically $50K to $150K for startups. Depends on the workload; AWS approves. CloudRoute is free for startups.