AWS Server Migration Service (SMS) used to be AWS’s agentless service for automating, scheduling and tracking incremental replications of on-premises server volumes so you could migrate to EC2 with less downtime. However, AWS has moved on — SMS (and CloudEndure Migration) have been superseded by AWS Application Migration Service (often called MGN). This guide explains what changed, which tool you should pick today, the pros/cons of SMS historically, the MGN alternative, migration stages, costs, and a practical decision checklist to help you decide. (Amazon Web Services, Inc.)
Important status update
AWS announced the sunsetting of CloudEndure Migration and AWS Server Migration Service and now recommends AWS Application Migration Service (MGN) for lift-and-shift migrations. If your content, playbooks or site still treat SMS as the default migration tool, update it to reference MGN. (Amazon Web Services, Inc.)
Short verdict up front
If you’re planning a new migration today, use AWS Application Migration Service (MGN). Keep SMS only for historical documentation or for explaining past projects — but do not choose SMS for a new project because it has been discontinued in favor of MGN.
What SMS used to do
SMS automated incremental replications of on-prem server volumes, created AMIs from replications and let teams orchestrate large migrations from the AWS Management Console. It was agentless for some hypervisors and useful for iterative testing with multiple replication runs. Older SMS documentation describes replication runs with intervals often between 12–24 hours and a per-server replication lifecycle (historically up to ~90 days unless extended). Those historical details are useful for context but are effectively legacy — migrate planning should use MGN specifics instead.
Why AWS moved to Application Migration Service (MGN)
AWS Application Migration Service (MGN) simplifies and automates lift-and-shift migrations more fully than legacy SMS. MGN continuously replicates source servers, converts them into cloud-native formats automatically, and reduces manual conversion steps. AWS also consolidated developer effort into one actively supported service (MGN), which receives continuous updates and feature improvements. If you need ongoing support and the most current features, MGN is the right choice.
What MGN gives you
- Automated, continuous block-level replication from physical, virtual (VMware, Hyper-V) or cloud sources.
- Automatic conversion of source servers to run natively on AWS (EBS/EC2) with minimal intervention.
- Built-in test launches and cutover workflows to validate migrations without impacting production.
- Free replication period per server for the initial migration phase (see pricing note below).
- Ongoing feature updates, dashboards, and integrations (import/export, metrics, post-launch actions).
Migration stages
Whether you work with legacy SMS or MGN, migrations follow a similar lifecycle — assessment, replication, testing, cutover and optimization. Here’s a practical breakdown that maps to MGN:
- Assessment & planning — inventory servers, dependencies, network, licensing and RTO/RPO targets.
- Pilot & replication setup — install replication agent (MGN agent), configure replication settings, choose AWS region and VPC.
- Continuous replication — source servers replicate to AWS (initial sync + incremental updates). Monitor replication health and bandwidth.
- Test launches — run non-production instances in AWS to validate functionality and performance.
- Cutover & finalization — schedule a cutover window, perform final sync and switch DNS/traffic.
- Post-migration optimization — rightsizing, reserved instances/savings plans, tagging and security hardening.
Pricing snapshot
MGN offers a free replication period for each source server (90 days / 2,160 hours when used continuously). After the free period, MGN charges an hourly rate per server; AWS’s public pricing page gives the current per-hour figure and lists additional infrastructure costs for test/cutover instances and storage. You also pay for S3/EBS and any EC2 instances launched during tests or cutover. Always check the official pricing page for your region before budgeting.
Where SMS still matters
If you’re supporting or documenting migrations done years ago with SMS, keep your historical notes, but clearly label them as legacy and provide a migration path or recommendation to re-run critical migrations using MGN when practical. For new migrations, do not start with SMS.
Pros & cons (current recommendation focused on MGN)
Pros (MGN / modern approach)
- Fully supported by AWS and actively enhanced.
- Easier conversion, testing and cutover automation.
- Predictable free trial period for initial migrations.
Cons / considerations
- You still bear charges for provisioned AWS resources during replication and testing (EBS, EC2, S3, data transfer). Plan for those costs.
Complex apps with high I/O or licensing constraints may need refactoring rather than straight lift-and-shift.
Technical checklist (pre-migration readiness)
Before you begin (quick checklist)
- Inventory: map all servers, apps, dependencies and storage requirements.
- Network: ensure VPN/Direct Connect and security groups are planned for cutover.
- Permissions: create IAM roles and service accounts with least privilege required for migration.
- Firewall rules: allow the agent to reach AWS endpoints (NTP, DNS, HTTPS etc.) — misconfigured firewalls block replication.
- Pilot: run a small pilot, test launches and perform performance and licensing checks.
- Backups: ensure you have a recovery plan and a backup prior to the first sync.
Decision checklist — do you need SMS/MGN?
Choose AWS MGN if:
- You need an actively supported lift-and-shift solution.
- You want automated conversion, testing and repeatable cutover workflows.
- You want to use the 90-day free replication window to lower migration costs during cutover.
Consider alternatives or professional help if:
- Your applications require refactoring (containerization, serverless) rather than rehosting.
- You need a hybrid approach requiring a long window of co-existence and complex networking.
- You prefer a multi-cloud migration factory or third-party migration partners with bespoke tooling.
