Skip to main content

AWS’s Database Migration Service (DMS) is a managed service to help migrate existing data and replicate changes from on-premise databases to AWS’s Relational Database Service (RDS). DMS supports homogenous database engine migrations for many platforms and also heterogeneous migrations to convert database engines or versions using the AWS Schema Conversion Tool. The Database Migration Service can be used to support: simple migrations to AWS RDS, continuous data replication for cloud based failover, migrating to open source solutions, database consolidation, and data warehouse size processing. This guide will cover the requirements, configurations, migration preparation, and deployment.


Database Platforms & Versions

DMS supports multiple source and target database engines. Migrating between on-premise to RDS can be homogenous (ie. Oracle to Oracle) or heterogenous (ie. Oracle to PostgreSQL) to support the needs of your organization. The following table has a list of options for support.

*Note on-premise to on-premise, EC2 to RDS, and RDS to RDS migrations available. See Source Migrations and Target Migrations.

List of Supported Database Engines



configuring network connections

For DMS replication, you will need to confirm or setup the proper IAM permissions, Security Group rules, on-premise database access, and VPC access for your network. The default DMS deployment should create the correct IAM permissions for your VPC cloud replication. Your on-premise database will need to accessible remotely by DMS and you may need to create IAM roles, Security Groups, and endpoint access depending on your cloud infrastructure.


The IAM permissions will need to be set to allow DMS to deploy replication instances and endpoints. Depending on your cloud infrastructure, you will need to create an IAM group to allow DMS access. Go to IAM > Groups and click Create New Group name the group dms-group and click Next Step. Select the AmazonDMSVPCManagementRole from the AWS predefined policies and click Next Step. Before you click Create Group make sure it looks similar to this example review.









Depending on your target database, you will need to setup Security Group rules to allow access to the proper inbound database ports from DMS replication server IP Address or Security Group. From the AWS Console, go to EC2 > Security Groups and click Create Security Group. The following is an example configuration with a variety of default database ports.











The Virtual Private Cloud (VPC) which will contain your DMS and RDS instances must have a public endpoint or virtual private network (VPN) connection to access your on-premise database instance. To setup a new VPC from the AWS Console go to VPC and click Start VPC Wizard. Select VPC with Public and Private Subnets and Hardware VPN Access and click Select. Create the Public and Private Subnets According to your desired configuration.



















After configuring your subnets, click Next. Now configure your VPN connection with the correct IP address, names and routing (routing can be a dynamic or a static IP address). Click Create VPC to complete the creation.

*For more in depth documentation on configuring your migration network, refer the AWS documentation.


preparing the migration

Migrations using DMS can be homogeneous or heterogeneous. Homogeneous migrations require no schema conversion and your database tools can apply the source schema to the target. For heterogenous migrations, Amazon provides AWS Schema Conversion Tool to summarize, generate, and apply schema conversions from the source to the target. The schema conversion tool is stand alone application that must be downloaded and installed on a machine that can connect to the source and target databases. AWS provides a variety installations for Windows, Mac, Ubuntu, and Fedora with links to the supporting JDBC database drivers.


Migration planning is crucial to successfully migrate to RDS and many considerations should be considered. Some requirements you should consider are: why are you migrating to a new version or database engine, will your source database continue to be in use, will the source to target replication be a one time data export or continuing change replication, will the source need to be highly available, does all of the data need to be migrated, and what are the database, compute, and network constraints? A strong understanding of your source database, schema, and tables will help to make the migration a success.


DMS supports basic schema migration with the creation of tables, primary keys, and some unique indexes but does not automatically create secondary indexes, foreign keys, user accounts, and etc for the target database. Tools like Oracle SQL Developer, MySQL Workbench, or pgAdmin III can be used to convert or export schema for homogeneous migrations. The AWS Schema Conversion tool can generate schemas for tables, indexes, and views to the target database engine for heterogeneous migrations. For more information, reference the AWS Schema Conversion Tool user guide.


*The following example is migrating pagila sample database from PostgreSQL source to MySQL target. You can recreate this example migration by loading the pagila sample database into a source PostgreSQL database.


create a target rds database

For the following example we will need to create a MySQL RDS instance. In the AWS Console, go to RDS dashboard and select Instances > Launch DB Instance > MySQL and click Select. Choose Dev/Test MySQL and click Next Step. Use the default settings and enter the DB Instance Identifier as “pagila”, Master Username as “pagila_user”, enter and confirm a password, and click Next Step.





















Configure the advanced settings. Use the default settings for the example migration. Name the database “pagila” and select Create New Security Group within the VPC Security Groups selection box. Click Launch DB Instance.


























Next, we will create and assign a new security group that will allow the schema conversion tool to connect to the RDS instance. Go to the EC2 dashboard, select Security Groups > Create Security Group. Name the security group as “rds-mysql”, add the MYSQL/Aurora rule and enter your custom IP Address or Security Group in the Source field and click Create.















Go to RDS > Instances and select the recently created “pagila” instance and click Instance Actions > Modify. In the Security Group field, select the “rds-mysql” security group, check the Apply Immediately checkbox at the bottom, and click Continue. You can review the settings and then click Modify DB Instance.


Using the schema conversion tool

-After successfully installing the AWS Schema Conversion Tool, it will be able to analyze, plan, and convert your source database. Open AWS Scheme Conversion Tool and go to File > New Project. Name project, set project location, set Source Database Engine to PostgreSQL, set Target Database Engine to Amazon RDS for MySQL and click OK.












Select Connect to PostgreSQL in the top toolbar and enter connection information (host, name, user, password) and click OK.


*Note: You will need to download the corresponding Java Database Connectivity (JDBC) drivers for your source and target database engines and load them into the conversion tool. Amazon’s list of JDBC drivers.















Once the source database has been loaded. Select Connect to Amazon RDS for MySQL in the top toolbar and enter the connection information from your earlier RDS deployment.













The schema conversion tool can now generate a summary report regarding the conversion. For example, select the Public schema from the source database and then in the top toolbar click Actions > Create Report. This report summarizes schema conversion statistics and possible issues regarding tables, views, data types, domains, indexes, triggers, etc.















The report has also created the schema conversion from the source to the target. Depending migration goals, the tool provides schema Mapping tools to convert specific subsets, tables, data types, functions, etc of the database. Now, you are able to create a new DMS replication instance to start migrations tasks.


migrating the data

AWS DMS will deploy a replication server to run migrations, create endpoints to connect to source and target databases, and create tasks to migrate data and tables.


deploying replication instance

Go to DMS dashboard > Replication Instance > Create Replication Instance. Add a name, description, instance type, and VPC and then click Create Replication Instance.























Depending on the size of your source database, you will want to choose the appropriate instance type and allocate the necessary storage space. DMS replication stores most of the conversion objects in RAM but will use disk storage for large transactions. Table sizes and data types will be a major determining factor.


Creating Source and Target Endpoints

Go to DMS Dashboard > Endpoints > Create Endpoint. Select Endpoint Type Source, enter an endpoint identifier name, the host, database type, and credentials for the example PostgreSQL instance. Click Run Test to verify connection then click Create Endpoint.

Repeat the last step but create an endpoint for the target MySQL RDS database.





















Creating and running the tasks

Go to DMS Dashboard > Tasks > Create Task. Name the task, specify the replication instance, enter the source and target endpoints, and migration type. DMS supports three migrations type: Migrate Existing Data, Migrate Existing Data and replicate ongoing changes, and Replicate ongoing changes. Click Create Task and by default DMS will start the selected migration on task create.






















Once the tasks complete. A report of the records migrated by schema and table can be found in the Table Statistics tab.








DMS also provides an Overview, Monitoring, and Logs to view CPU and disk storage and individual record conversions. After all tasks are complete, your RDS instance is now up to date.


final thoughts

Database migrations will have pain points and estimating completion time comes down to connectivity and machine resources. Conversions between database engines are always going to be more difficult and defining migration task scope will help to alleviate issues. You’ll be successful using DMS when you understand your source data, its constraints, and define attainable goals.


Additional Resources

AWS DMS Getting Started


User Guide

AWS Schema Conversion Tool


Comments are disabled for this guide.