AWS Database Migration Service FAQs

AWS Database Migration Service (DMS) supports a range of homogeneous and heterogeneous data replications.

Either the source or the target database (or both) need to reside in RDS or on EC2. Replication between on-premises to on-premises databases is not supported.

• Supported DMS sources
• Supported DMS targets

AWS DMS Serverless supports popular databases and analytics services, such as Oracle, Microsoft SQL Server, PostgreSQL, MySQL, Amazon Redshift, Amazon RDS, Amazon Aurora, and more. See the full list of supported engines.

AWS DMS Schema Conversion supports a range of popular databases, which are listed  here.

AWS Schema Conversion Tool (AWS SCT) supports a range of database and data warehouse conversions, which are listed  here.

See the full list of supported engines for AWS DMS homogeneous data migrations, including PostgreSQL and MySQL.

Yes, part of the AWS Database Migration Service is AWS DMS Schema Conversion (DMS SC) which automates the conversion of Oracle PL/SQL and SQL Server T-SQL code to equivalent code in the Amazon RDS for MySQL dialect of SQL or the equivalent PL/pgSQL code in PostgreSQL.

When a code fragment cannot be automatically converted to the target language, DMS SC will clearly document the locations that require manual input from the application developer. A downloadable version, called AWS Schema Conversion Tool (AWS SCT), is also available.

Yes, when you need to use a more customizable schema migration process (for example, when you are migrating your production database and need to move your stored procedures and secondary database objects), you can use the built-in Schema Conversion feature of AWS DMS for heterogeneous migrations. Alternative options include downloading AWS Schema Conversion Tool or using the schema export tools native to the source engine, if you are doing homogeneous migrations such as:

1. SQL Server Management Studio's Import and Export Wizard.
2. Oracle's SQL Developer Database Export tool or script the export using the dbms_metadata package.
3. MySQL's Workbench Migration Wizard.

AWS DMS and AWS SCT work in conjunction to both migrate databases and support ongoing replication for a variety of uses such as populating data lakes and warehouses, synchronizing systems, and so on. AWS SCT can copy database schemas for homogeneous migrations and convert them for heterogeneous migrations. The schemas can be between databases (for example, Oracle to PostgreSQL), or between data warehouses (for example, Netezza to Amazon Redshift).

Once a schema has been created on an empty target, depending on the volume of data and/or supported engines, either AWS DMS or AWS SCT are then used to move the data. AWS DMS traditionally moves smaller relational workloads (<10 TB), whereas AWS SCT is primarily used to migrate large data warehouse workloads. AWS DMS supports ongoing replication to keep the target in sync with the source; AWS SCT does not.

AWS Database Migration Service (AWS DMS) Serverless automatically provisions, monitors, and scales resources to make database and analytics migrations to AWS easier and more cost effective. With AWS DMS Serverless, you no longer have to overprovision migration resources or manually monitor and scale resources for continuous data replication. AWS DMS Serverless optimizes resources to meet demand, so you’re only paying for the resources used. This makes it helpful for popular use cases such as continuous data replication, as well as complex heterogeneous migrations between different source and target engines.

Yes, AWS DMS Serverless can be used for continuous replication. DMS Serverless supports both Single-AZ and Multi-AZ deployment options.

For homogeneous migrations, we recommend using DMS built-in native tooling for supported engines, due to its familiarity and seamless migration. You do not need to provision or monitor the migration, and you only pay for the hours used during the migration. To check supported engines, go to DMS documentation page.

For heterogeneous migrations or continuous data replications with data fluctuations, we recommend using AWS DMS Serverless as it automatically monitors and scales resources to meet demand without manual intervention or over provisioning resources, saving you time and cost. On-demand instances, on the other hand, are good for predictable, stable data transfers, as they can be rightsized for performance and cost. See AWS DMS Serverless documentation for supported engines.

Yes, AWS DMS built-in native tooling for homogeneous data migration is serverless. It does not use replication instances and will automatically monitor and scale migration resources as needed to provide a seamless migration.

AWS DMS Fleet Advisor is a free, fully managed capability of AWS Database Migration Service (AWS DMS). It automates migration planning and helps you migrate database and analytics fleets to the cloud at scale with minimal effort. For discovery of on-premises databases, you can use a standalone AWS DMS Fleet Advisor collector or the database and analytics collection module of the AWS Application Discovery Service (ADS) Agentless Collector.

AWS DMS Fleet Advisor is intended for users looking to migrate a large number of database and analytics servers to AWS. When you are ready to migrate your database and analytics workloads to target services in AWS, you should use AWS DMS Fleet Advisor to discover and analyze your Online Transaction Processing (OLTP) and Online Analytical Processing (OLAP) database workloads. Fleet Advisor allows you to build a customized migration plan by determining the complexity of migrating your source databases to target services in AWS.

The AWS Application Discovery Service (ADS) and Migration Evaluator are targeted for broad-based compute and attached block storage discovery. The Migration Evaluator is used by customers starting their migration journey who are looking for a data-driven business case for AWS. ADS is used to feed the AWS Migration Hub to visualize server to server dependencies, create application groups, and track migration progress.

For most customers, we recommend using the AWS Application Discovery Service (ADS) Agentless Collector in regions where available, as it supports server migration through AWS Migration Hub as well as allows you to discover on-premises databases. For all other regions, we recommend using the AWS DMS Fleet Advisor collector. Database metadata and utilization metrics collected from both the standalone AWS DMS Fleet Advisor collector and the AWS ADS Agentless Collector will be available in AWS DMS Fleet Advisor.

Use the AWS ADS Agentless Collector if you have a VMware vCenter Server environment, otherwise the AWS DMS Fleet Advisor collector can be installed on a Microsoft Windows Server 2012 or higher.

The AWS DMS support lifecycle policy specifies how long support will be available for each DMS version, from when a version is released to when it is no longer supported.  

The support lifecycle policy aims to provide predictable and consistent guidelines for support for each AWS DMS version release. The guidelines will benefit customers to strategically plan their migration and upgrades.

The end of support date for each DMS version release will start 18 months after its initial release. For the latest schedule of all existing DMS versions, please go to the new section "Support lifecycle policy" from your DMS console. 

Support timelines for each AWS DMS version release will be included in the associated DMS Release Notes, as well as in the new “Support lifecycle policy” section in your DMS console. If you are using any versions that will reach end of support within 90 days you will see an alert next to the Engine Version under "Replication Instance". In addition, AWS will send DMS instance owners a quarterly email reminder if they are running a release that will no longer be supported in the following quarter.

The policy went into effect on January 1st, 2023. All instances that have reached the end of support date of 18 months after release will be automatically upgraded to the latest preferred DMS version regardless of the automatic upgrade setting.

The DMS service designates one of the newest releases of DMS as the preferred version. This preferred version is the version that will be used for automatic upgrades and is the default choice for customers creating a new DMS instance.

New DMS versions are only released after extensive testing. After the release of a new  version, the DMS service team closely monitors reliability metrics and customer feedback. Once we are confident that there are no significant issues with the new release, we will mark that release as the new preferred version which you can find when selecting the version upon creation of the replication instance.

AWS DMS does not differentiate between a major and minor version release, and does not plan to have a different support policy. 

If you enable auto upgrade, your replication instance will be automatically updated to the latest preferred version as it becomes available. If you opt out of the auto-upgrade, AWS DMS will update your instances to the latest preferred version once the end-of-life date has been reached, which will be communicated via email and console notification prior to upgrade. You can learn more about how to upgrade the DMS engine version using the AWS Console or AWS CLI in this DMS User Guide.

The auto upgrade setting in your replication instance is turned on by default. To check or make any modification to this setting using AWS CLI, DMS API, or console you can use  this Modifying a Replication Instance guide.

If the tables in the migration task are in the replicating ongoing changes phase (CDC), AWS DMS pauses the task while the patch is applied. The migration then continues from where it was left off when the patch was applied.

If AWS DMS is running a full load operation when the patch is applied, AWS DMS restarts the migration for the table. These upgrades will occur during the maintenance window specified for the replication instance. You can find more details on Working with the AWS DMS Maintenance Window guide.

After the end of life date for a DMS version has passed, AWS DMS may remove the release version from the console and upgrade your replication instance to the latest preferred version in order to continue providing support. We recommend you to upgrade to the latest AWS DMS release as soon as possible.

You can reach out to AWS Developer Support for more information.