Jul 08, 2020 | 3 min read

How to Get Your Database Migration Started with AWS DMS

By: Zachary Sersland

How to Get Your Database Migration Started with AWS DMS

Migrating your database from an on-premise server to an AWS Relational Database Service (RDS) instance can be a daunting task. Moving a production database with continually changing data requires plenty of effort - especially if you’re also switching database engines.

Fortunately, there’s an AWS service to help with this. Their Database Migrations Service (DMS) automates and saves migrations to make moving to the cloud much easier. It can perform one-time migrations, sync ongoing data changes, and even help you switch database engines. In this article, I’ll cover five of DMS’s core concepts that will help get your migration moving forward.

1. Set Up Source and Target Endpoints

The first step is to set up your source and target endpoints. The source, presumably, already exists, but there may be steps to take before the migration begins, especially if you’re syncing changes on an ongoing basis or changing database engines. Check the online DMS documentation for any setup tasks you need to complete first, which may include installing drivers or the Schema Conversion Tool (an application used to translate your current database onto a new engine).

Preparing your target database usually requires creating a user with the highest privileges and access to the database that AWS DMS can connect with. When the source and target are set up, create a Source Endpoint and a Target Endpoint through the AWS console in DMS.

2. Define Subnet Groups

Define what subnets are going to be used during your migration by setting up a subnet group. In the DMS section of the AWS console, navigate to the Subnet Group section to create a new one. Select the VPC the migration will take place in, and add some or all subnets in the VPC. This subnet group will then be added to your Replication Instance.

3. Create a Replication Instance

The Replication Instance performs the migration between the two endpoints. It can be difficult to determine how big the replication instance can be, but the size can easily be changed through the console. Monitoring can be set up through AWS CloudWatch to tell you how much of the instance’s CPU and network bandwidth is being used. When creating a replication instance, set it up in the same VPC as the source or target instance. And if either instance isn’t in the VPC, be sure to mark the replication instance as Publicly Accessible. 

4. Configure Migration Tasks

Migration Tasks define the migration itself – the source, replication instance, target, and various options. Most of the task fields are straightforward, but there are a few to look out for:

  • Include Binary Large Object (BLOB) columns in replication – BLOBs can be migrated using DMS, but the default cutoff size is 32 KB. Anything larger will be truncated. Review your database schema and values to check if this value needs to be adjusted.
  • Table Mappings – This section allows you to include or exclude tables based on selection rules, which is especially handy if you’re dividing a large database into smaller databases for microservices. Transformation rules are also useful for updating outdated table or column names.
  • Control Table Settings – Control tables provide information about the migration itself, including the replication status, tables that were suspended during the migration, and the replication history. Enable each table to help debug failed migrations.

5. Set Up Event Subscription Notifications

Event Subscriptions notify you when important events occur in your migration. The subscriptions can target email or SMS topics to alert you to events such as a replication instance failing or running low on storage, configuration changes, or tasks starting and stopping. Smaller migration tasks won’t need these subscriptions – you can simply monitor the progress through the console. But for larger migrations, especially those that replicate ongoing changes, event subscriptions let you know immediately if anything needs your attention.

To learn more about upgrading your systems, check out this Guide to Strategic Considerations for Managing Legacy Applications. If you have additional questions, don’t hesitate to reach out.

About Zachary Sersland

Zachary Sersland is a senior developer and team lead at DragonSpears. He earned his degree in computer science from Northwestern University and has been working in software development and consulting ever since. His focus is primarily in .Net and AWS, but he’s also taken on projects using Azure, PHP, and even Python. His favorite aspects of working at DragonSpears are the company’s development of leaders at every level and the opportunity to work with such talented teammates. He’s a movie fan, having seen every movie on the AFI and BFI Top 100 Films lists, and in high school, he earned money as a church organist.