Explain how AWS Database Migration Service works and when you would use it. What are its capabilities and limitations for different migration scenarios?

Question

Accepted Answer

AWS Database Migration Service is a managed service that helps migrate databases to AWS quickly and securely while the source database remains fully operational during the migration. It supports both homogeneous migrations like MySQL to MySQL and heterogeneous migrations like Oracle to PostgreSQL, making it versatile for many migration scenarios.

DMS works by creating a replication instance, which is a managed EC2 instance that runs the migration software. You define source and target endpoints specifying connection details for each database. A migration task defines what data to migrate and how. The task performs an initial full load of existing data followed by ongoing Change Data Capture that replicates changes made to the source database after the full load began. This allows you to migrate with minimal downtime because the source database remains operational throughout the process and the target stays synchronized until you are ready to cut over.

The full load phase reads data from the source tables and writes it to the target tables in parallel. You can configure how many tables load in parallel and the batch size. For large tables, DMS can use multiple threads to accelerate the load. The CDC phase captures changes using the source database's transaction log. For Oracle, it reads the redo log. For SQL Server, it uses the transaction log. For PostgreSQL, it uses logical replication slots. For MySQL, it reads the binary log. These changes are applied to the target in near real-time, typically with seconds of lag.

For heterogeneous migrations, DMS handles basic data type mapping between platforms. However, it does not migrate stored procedures, triggers, views, or other schema objects. For those, the AWS Schema Conversion Tool is a complementary service that analyzes the source schema, identifies conversion issues, and generates equivalent code for the target platform. SCT provides an assessment report showing what percentage of the schema can be converted automatically and what requires manual intervention.

DMS capabilities include table-level selection where you can choose specific tables or schemas to migrate. Data transformation rules can filter rows, rename tables or columns, and add columns during migration. Validation compares source and target data to verify migration accuracy. Monitoring through CloudWatch provides visibility into replication latency, throughput, and errors.

Limitations are important to understand. DMS does not migrate secondary objects like stored procedures, triggers, sequences, or indexes. You must handle these separately using SCT or manual scripts. Large Object columns and certain data types may require special handling. Performance depends on the replication instance size, network bandwidth, and source database load. Complex schemas with circular foreign key dependencies can cause ordering challenges during full load.

I recommend DMS for production migrations where minimizing downtime is critical, for ongoing replication between on-premises and cloud databases during a transition period, and for consolidating multiple source databases into a single target. For simple migrations of small databases or development environments, native backup and restore tools are often faster and simpler. For very large databases exceeding tens of terabytes, a combination of physical backup shipping for the initial load and DMS for CDC during cutover can be more efficient than DMS alone.