Amazon DMS (Database Migration Service) drastically simplifies the work of migrating existing databases to the AWS Cloud. Amazon claims that more than 55,000 databases have been migrated via DMS, which promises little or no downtime and requires only a few minutes worth of setup. 

DMS handles the heavy lifting of exporting and importing data from the old database to the new and can monitor the original database for changes made during the process so that no data is lost in the midst of the migration. DMS also supports a wide range of source databases, including MySQL, PostgreSQL, Amazon Aurora, Oracle, SQL Server, MongoDB, MariaDB, and SAP ASE, and can facilitate most transitions between one database type and another.

Using Amazon DMS efficiently comes down to following three steps. I’ll demonstrate these by detailing the following example migration: moving a 13 GB MySQL database from a Los Angeles data center to an empty new Amazon RDS instance in the cloud.

1. Establish a DMS Replication Instance

Begin the process by creating a replication instance, which you’ll use to connect to both databases and perform the migration. The setup for this is straightforward and requires a sparse amount of information (as shown here).

If needed, advanced options enable other configurations for storage allocations, security groups, the preferred availability zone, the KMS master key for encrypted data-at-rest on the replication instance, and more.

At the end of this step, the replication instance shows an “available” status, and can now accept tasks.

2. Configure the Source and Target Endpoints

DMS uses endpoints that you set up to connect to the database server, and then import and export data between your old database and the new one. This quick setup just requires inputting the requisite information that will tell DMS how to make these connections.

One source endpoint and one target endpoint are required for the migration, but combining multiple for each is an option – and just as simple. If your needs call for uniting different databases across multiple servers into a single RDS instance, go ahead and do so. Note that some options and information requirements will vary based on the database you use: for SQL Server, you must provide a database name, and the options for SSL mode are database-dependent.

This step is complete once at least two endpoints are created, with one pointing to the source database at the data center and one pointing to the new RDS instance.

At this stage, you’ll want to dig a little deeper to test your endpoint connection and refresh the schemas.

The top of the endpoint page includes a Test connection button that can be used at any time. It brings up a display enabling you to test your connection; you’ll either see it was successful or receive an explanation for why it failed.

Refreshing the schemas will happen automatically when DMS begins working on a migration task. However, I recommend doing so manually since it’ll be valuable for confirming that the schemas can be viewed correctly.

3. Configure a Migration Task and Then Start It

The final step instructs the replication instance as to what data should be moved (and to where). To do so, you’ll need a source endpoint and target endpoint, as well as some additional details on how to migrate this data.

Telling DMS what data to migrate is achieved using Table mappings. This can be completed using the tool’s Guided tab, or by providing JSON information.

Table mappings can be defined broadly or narrowly. It’s possible to include all schemas, select any to exclude from the migration, or choose only one or more specific schemas out of the gate. In this example, two table mappings are included in order to migrate two schemas.

From this point, it’s possible to create the task and proceed with the migration. However, one option available before doing so is to use transformation rules to convert the data, as needed, for each schema, table, or even database column.

Transformation rules make it possible to change column names to lowercase, add prefixes to table names, and complete other alterations that can be critical when switching databases and preparing for how different engines process these details. In this example, we create rules to add the prefix snc_ to each table name.

With all preferred settings and rules in place, it’s time to create the task and watch it run.

There’s no need for further action at this point; DMS will go to work and do the rest automatically. In my example, DMS needs about 20 minutes to complete the full migration — your particular migration time will depend on database size, the instance class of the migration instance, the connection speed for the source database, and other factors.

Once the initial data load is migrated, DMS will perform an ongoing replication to apply any further changes to the new database, allowing for a seamless migration from the user perspective. Logging into the RDS with a command line tool, you can then verify that the two schemas have been successfully moved and renamed, and include the correct number of rows.

The migration is now complete and has been confirmed. The new cloud database is ready for use, and the DMS instance can be terminated.

There are cases where using Amazon DMS can include a few wrinkles, most of which are possible to troubleshoot without too much difficulty. That said, DMS is a simple, powerful tool that makes migrating databases to the cloud much easier.

Michael Erick is a Cloud Engineer at Reliam, a managed services provider for public cloud platforms including AWS, Azure, and Google Cloud Platform.