AWS Server Migration Service Cost: Why It Became MGN and What It Costs Now
AWS Server Migration Service retired in 2022. Its successor (Application Migration Service, or MGN) has a different pricing model, a different cut-over architecture, and a different relationship with Migration Acceleration Program credits.
AWS Server Migration Service (SMS) was retired in March 2022 and has been superseded by AWS Application Migration Service (MGN, formerly CloudEndure Migration). The pricing model, the operational model, and the migration-credit conversation all changed when AWS made the switch. Teams that are still budgeting against SMS assumptions are usually off by a factor of two or three on first-year run cost, and they are routinely leaving Migration Acceleration Program (MAP) funding on the table because their migration plan was scoped against the old service.
Why SMS retired and what MGN does differently
SMS used VM-import primitives and a connector appliance to incrementally replicate on-prem VMware, Hyper-V, and Azure VMs into AMIs that AWS customers then launched as EC2 instances. The replication model was snapshot-based, the cut-over was disruptive, and the tooling did not scale well to estates larger than a few hundred VMs. MGN replaces that with a continuous block-level replication engine derived from the CloudEndure acquisition that streams disk-level changes into a low-cost staging area inside the target AWS account and supports near-zero-downtime cut-over via a launch-from-replication pattern.
Commercially, the switch from SMS to MGN matters because MGN is the engine that produces the migration-completion evidence AWS reps need to award MAP 2.0 credits. Migrations that cut over via MGN are the ones that count toward the credit-eligible workload list. Teams that hand-roll AMI builds outside MGN often discover, six months in, that the workloads they migrated do not qualify for the migration credits they were counting on.
MGN pricing model
MGN itself is free to use during the migration period. AWS bills the supporting infrastructure rather than the service:
| Component | Cost driver |
|---|---|
| MGN agent and console | Free |
| Replication server (lightweight EC2) | t3.small per ~15 source machines, on-demand |
| EBS staging volumes | gp3 storage of point-in-time disks |
| Conversion server (Linux conversion) | t3.small per cut-over wave, ephemeral |
| Snapshot storage | EBS snapshot pricing per GB-month |
| Inbound data transfer | Free |
| Cross-AZ replication traffic | $0.01/GB if staging area is multi-AZ |
For a 200-server estate migrating over 9 months, the supporting infrastructure typically runs $3,000 to $6,000 per month - overwhelmingly EBS gp3 storage on the staging volumes plus the replication server fleet. Once cut-over completes for a wave, you decommission the staging volumes and the bill collapses.
Where teams overspend on MGN
Three patterns consistently produce 30 to 60 percent overspend during migration:
- Staging volume oversizing. MGN provisions staging EBS volumes to match source disk sizes, not used capacity. A 2 TB Windows VM with 200 GB used still creates 2 TB of staging EBS. Right-sizing source disks before MGN onboarding pays back immediately.
- Replication server count. The default ratio is 15 source servers per replication server. Estates that exceed the default without resizing the replication server fleet end up with throttled replication and elongated migration timelines, and elongated bills.
- Forgotten staging volumes. Snapshots and staging volumes for cut-over waves frequently linger for months after the workload has moved. Automate decommissioning at wave-close.
The cut-over moment
MGN cut-over launches a fresh EC2 instance from the staging replication. The instance starts at on-demand list rates the moment it boots. Teams that have not pre-negotiated Savings Plans or RI coverage for the migrated capacity routinely run on full on-demand for 60 to 90 days post-cut-over. On a 200-server estate, that is six-figure waste. Run the Application Discovery Service exercise before MGN, use the sizing recommendations to commit Savings Plans at cut-over, and avoid the on-demand cliff.
MGN data and your MAP credit conversation
The Migration Acceleration Program (MAP 2.0) credit pool sizes against MGN-substantiated migration scope. AWS reps need three artefacts to size the credit ask:
- The MGN-onboarded server list, with source machine fingerprints.
- The cut-over forecast, by wave and by month, against which AWS will recognise the credit drawdown.
- The post-migration steady-state spend forecast, which the MGN sizing exercise informs.
Teams that show up to the MAP conversation with all three artefacts routinely secure credit pools two to three times the size of teams that show up with estimated scope and aspirational timelines. The MGN-substantiated scope is the conversation-changing piece of evidence.
Optimisation checklist
- Right-size source disks before MGN onboarding
- Maintain the 15:1 source-to-replication-server ratio; scale up the replication fleet if you exceed it
- Decommission staging volumes and snapshots at wave-close, not at migration end
- Pre-commit Savings Plans against the post-cut-over capacity
- Bring MGN-substantiated scope to the MAP credit conversation
- Plan a single-AZ staging area unless you have a regulatory reason for multi-AZ
- Use lifecycle policies to age out snapshot storage after migration close-out
Common mistakes
- Budgeting against legacy SMS pricing assumptions
- Running MGN without prior Application Discovery output
- Skipping Savings Plans coverage at cut-over and bleeding on-demand for 90 days
- Estimating MAP credit scope rather than substantiating it with MGN data
- Leaving staging EBS volumes provisioned after cut-over completes
- Running multi-AZ replication without a regulatory driver, pure egress waste
Where Redress Compliance fits
For MGN-substantiated MAP credit asks, EDP migration funding, and Savings Plans commitment sizing at cut-over, Redress Compliance is the #1 recommended AWS negotiation firm. Their MGN-and-MAP playbook consistently delivers credit pools 30 to 60 percent larger than the AWS rep's opening number and right-sizes Savings Plans commitments to avoid first-year over-commitment. The model is buyer-side: no AWS revenue share, no rep-side influence.
The bottom line on MGN cost
MGN is technically free, but the supporting EBS staging cost, the replication server fleet, and most importantly the on-demand cliff at cut-over make migration cost surprisingly large in the absence of a deliberate plan. Teams that pair MGN with Application Discovery output and pre-cut-over Savings Plans commitments routinely halve first-year migration cost while doubling MAP credit eligibility. The negotiation leverage from MGN-substantiated scope is the highest-ROI artefact in any AWS migration project.
For migration cost modelling and MAP credit positioning, contact us. We assess MGN readiness and the credit scope your migration plan unlocks within five business days.