Database Migration Service (DMS) and Schema Conversion Tool

AWS Database Migration Service (DMS) migrates databases to AWS with minimal downtime. It supports homogeneous migrations (e.g., Oracle to Oracle, MySQL to MySQL) and heterogeneous migrations (e.g., Oracle to Aurora PostgreSQL, SQL Server to MySQL). DMS uses a replication instance that reads from the source, optionally transforms data, and writes to the target. You pay only for the replication instance runtime.

DMS has three key components. Source Endpoints define the source database connection (JDBC URL, credentials, TLS). Target Endpoints define the destination database. The Replication Instance is an EC2-based managed server that DMS provisions in your VPC to run the migration workload. Choose the replication instance size based on how much data needs to be migrated and whether you want multi-AZ for the replication instance itself.

DMS supports two migration modes. Full Load copies all existing data from source to target — suitable when you can afford downtime or the source is read-only during migration. Change Data Capture (CDC) captures ongoing changes from the source transaction log after the full load completes, keeping source and target in sync. A combined Full Load + CDC migration minimises downtime: migrate data while the source stays live, then cut over when the target is caught up.

The AWS Schema Conversion Tool (SCT) is a free downloadable application that automatically converts the source database schema (DDL) to a format compatible with the target database engine. It handles table definitions, views, stored procedures, functions, and triggers. For heterogeneous migrations (e.g., Oracle to PostgreSQL), SCT converts the majority of objects automatically and flags items that require manual review due to unsupported syntax differences.

For homogeneous migrations (same engine, e.g., MySQL on-premises to RDS for MySQL), SCT is usually not needed — the schema is directly compatible. DMS can run Full Load + CDC immediately. For heterogeneous migrations (different engines), SCT must convert the schema first, DMS handles the data migration, and you may need to manually rewrite stored procedures and triggers that have no equivalent in the target engine.

DMS supports a wide range of sources: Oracle, SQL Server, MySQL, MariaDB, PostgreSQL, SAP ASE, MongoDB, IBM Db2, and S3. Supported targets include all of the above plus Amazon Redshift, DynamoDB, Kinesis Data Streams, and Kafka. This makes DMS useful not just for relational migrations but also for streaming relational change events into a data lake or event-driven architecture using CDC to Kinesis.

DMS uses table mapping rules (JSON) to control which schemas and tables to include or exclude, and to apply data transformations. You can rename schemas or tables, convert column values (e.g., uppercase all strings), add derived columns, or filter rows. This is useful when migrating to a target with different naming conventions or when you want to migrate only a subset of tables.

DMS publishes metrics to CloudWatch: FullLoadThroughputRowsSource (rows per second loaded), CDCLatencySource (lag between source transaction log and DMS reading it), and CDCLatencyTarget (lag between DMS reading and writing to target). Monitor CDCLatencyTarget closely during the sync phase — when it drops to near zero, the target has caught up to the source and you are ready for cutover.

DMS Serverless automatically provisions and scales the replication capacity based on the migration workload, eliminating the need to choose and manage a replication instance size. You specify minimum and maximum DMS capacity units (DCUs) and DMS auto-scales within that range. This is ideal for migrations with variable load or when you want to avoid the risk of under-sizing the replication instance during peak migration load.

After migration, validate data completeness using DMS Data Validation. Enable it in the task settings and DMS compares row counts and checksums between source and target tables, reporting mismatches to a separate validation table. For heterogeneous migrations, also run application-level smoke tests. Never cut over until validation shows zero discrepancies — reconciling data after a flawed cutover is far more costly than taking extra time to validate.

For the SAA-C03 exam, DMS appears in scenarios requiring database migration with minimal downtime. Key signals: 'migrate database with ongoing replication' → DMS Full Load + CDC. 'heterogeneous engine change' → SCT first, then DMS. 'replicate changes in near real time to a data lake' → DMS CDC to Kinesis or S3. 'consolidate multiple source databases into one target' → multiple DMS tasks to one target endpoint. DMS is specifically for database migration — for server migration use MGN, for bulk data transfer use DataSync or Snowball.

Test your understanding of AWS Solutions Architect (SAA-C03) concepts from this lesson.

In this lesson you learned: DMS supports both homogeneous and heterogeneous database migrations using Full Load and CDC modes, SCT automates schema conversion for engine-change migrations and flags manual review items, and DMS Serverless auto-scales replication capacity eliminating instance sizing decisions. Next up we explore Amazon EventBridge for event-driven routing and bus architecture.