These are not three current alternatives for the same job. AWS Database Migration Service (DMS) moves database data; AWS Server Migration Service (SMS) is out of support; and CloudEndure Migration was discontinued. For new whole-server lift-and-shift projects, AWS now recommends AWS Transform MGN, the current name for AWS Application Migration Service. Choose based on whether you are moving database contents or rehosting complete servers.
At a glance: which AWS migration tool fits?
| Tool | Migration unit | Current status and best framing | Key checks |
|---|---|---|---|
| AWS DMS | Database data between supported data stores | Use for database migration and, when needed, ongoing change replication. Schema and code conversion may require separate tooling. | Supported source and target engines and versions, migration mode, connectivity, object conversion, consistency, and cutover. |
| AWS SMS | Server migration (historically) | Support ended April 1, 2023; do not select it for a new migration. | Identify a currently supported successor and verify eligibility for the source environment. |
| CloudEndure Migration | Whole-machine rehosting (historically) | Discontinued. AWS identifies MGN as its successor path for lift-and-shift server migrations. | Check current MGN support for the source system, architecture, storage, and target region. |
| AWS Transform MGN | Whole-server rehosting | Current name, since June 2026, for AWS Application Migration Service; AWS recommends it for lift-and-shift server migrations. | Source OS and architecture, agent and network prerequisites, target constraints, test launch, and cutover. |
Lifecycle and product details can change. Confirm current compatibility and service availability in the relevant AWS DMS documentation and AWS Transform MGN release notes before implementation.
What AWS DMS does—and what it does not
DMS migrates data among supported relational databases, data warehouses, NoSQL stores, and other data stores, including on-premises and AWS environments. Depending on the supported source-target combination, a migration may keep the same database engine or move between different engines. AWS describes both one-time full-load migrations and full load followed by ongoing change data capture (CDC), which can keep changes flowing while you prepare a cutover. The right mode depends on how you plan to synchronize data and switch applications to the destination. See AWS’s DMS overview for service scope and current supported paths.
Data migration is not automatically a complete schema conversion
Do not assume DMS will convert every database object or application dependency. AWS’s traditional DMS walkthrough says DMS migrates data, tables, and primary keys, while other database elements are not migrated by DMS. For heterogeneous migrations, AWS Schema Conversion Tool or DMS Schema Conversion can assess and convert schemas and code objects; objects that cannot be converted automatically need manual work. AWS describes homogeneous DMS migrations using native database tools, but supported engines and limitations differ by path. Check the specific workflow rather than generalizing from another engine pair. See the DMS migration walkthrough and AWS guidance on database migrations.
Recommended Free Tools
#1 Best Overall
Decide on full load, ongoing changes, and cutover together
A one-time full load suits a migration where a snapshot is sufficient. Full load with CDC is relevant when source writes continue during migration and you need changes replicated before cutover. Neither mode eliminates the need to plan connectivity, verify consistency, account for objects outside DMS’s migration scope, and determine when applications stop using the source.
AWS SMS: a retired option, not a current recommendation
AWS lists Server Migration Service among services whose support ended on April 1, 2023, in its full shutdown services reference. AWS Prescriptive Guidance directs former SMS users to MGN for future migrations. SMS is useful context when assessing an existing migration plan or older documentation, but it should not be presented as an available choice for a new project.
CloudEndure Migration: what it did and what replaced it
CloudEndure Migration was an agent-based service for rehosting physical, virtual, and cloud-based source machines. AWS’s older guidance describes installing an agent, asynchronously replicating machine data at the block level to a staging area, testing a target instance, and then cutting over. That history can help explain legacy runbooks, but CloudEndure Migration is discontinued. AWS’s document history records the discontinuation in September 2022, and AWS Prescriptive Guidance identifies Application Migration Service (now AWS Transform MGN) as the successor/recommended path. See the AWS CloudEndure migration guide and its Cloud Migration Factory document history.
For new server rehosting, use AWS Transform MGN
AWS Application Migration Service was rebranded AWS Transform MGN in June 2026; AWS says its capabilities were unchanged by the name change. AWS describes it as the primary service recommended for lift-and-shift server migrations. The change in name does not turn MGN into a database schema-conversion service: it addresses rehosting servers. AWS Prescriptive Guidance’s statement that Application Migration Service is the primary lift-and-shift recommendation was last updated in January 2021, so read that wording in light of the later rebrand and check current documentation for present-day constraints.
Rank #3
Plan an MGN migration around the source environment and the launch and cutover process. Verify source operating system and architecture support, attached storage, agent and network prerequisites, destination region, and target constraints. Test-launch migrated servers before cutover. AWS’s current release notes are the appropriate starting point for changes to the service name and capabilities; consult current MGN setup documentation for exact eligibility and steps.
How to choose: database migration or server rehosting?
- Define what must move. If the scope is database contents, evaluate DMS. If the goal is to rehost complete machines, evaluate AWS Transform MGN.
- For databases, validate the exact path. Check source and target engine and version support, whether the migration is homogeneous or heterogeneous, required schema or code conversion, and whether full load alone or full load plus CDC fits the cutover.
- For servers, validate the source and destination. Check OS and architecture, storage, agent and network requirements, and target-region and launch constraints in current MGN documentation.
- Test the migration before production cutover. For DMS, validate migrated data and synchronization. For MGN, test-launch the server and validate its behavior. Set a cutover plan that accounts for application dependencies and the source workload.
- Remove retired services from the plan. Do not build a new migration around SMS or CloudEndure Migration; confirm that the currently recommended successor supports the specific workload.
DMS and MGN are not direct substitutes: one works at the database-data layer and the other rehosts servers. A larger project can involve both, but their roles, prerequisites, and validation steps remain distinct.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.What is established—and what is not
The AWS materials cited here establish the tools’ roles and lifecycle status, but do not provide a comparable market-adoption or performance statistic for DMS, SMS, and CloudEndure. They do not support a general claim that one tool is faster, cheaper, or guarantees a particular downtime outcome. Those results depend on the workload and migration design; assess them against the actual source, target, network, and cutover requirements rather than assuming a published comparative figure.
Quick Recap
Best Value
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
