AWS Database Migration Service (DMS)
AWS Database Migration Service migrates relational databases, data warehouses, NoSQL databases and other data stores into AWS, out of AWS, and between stores inside it. Its distinguishing feature is that it can keep replicating changes from the source while the source stays in production, so the cutover window is a switch of connection strings rather than an outage long enough to copy the data.
Key features
Section titled “Key features”- Migrations into AWS, out of AWS, and between AWS data stores. At least one endpoint must be in AWS.
- One-time migration or continuous replication.
- Heterogeneous migrations, where the source and target run different database engines.
- Sources and targets on Amazon RDS, Aurora, Amazon Redshift, self-managed databases on EC2 or on-premises, and data held in S3.
How it works
Section titled “How it works”A replication instance runs the migration tasks. The source and target data stores are configured as endpoints; DMS reads from one and writes to the other. DMS can create the target tables and primary keys itself, or they can be created in advance — usually the better choice, because the tables DMS creates carry no secondary indexes, constraints or storage parameters.
Migration types
Section titled “Migration types”| Type | What it does | When to use it |
|---|---|---|
| Full load | Copies existing data from source to target, tables in parallel | The source can tolerate an outage, or the data is static |
| Full load + CDC | Full load, then applies changes captured during and after it | Near-zero-downtime cutover of a live database |
| CDC only | Applies ongoing changes to a target seeded some other way | The bulk was moved by backup/restore, snapshot or another tool |
Change data capture reads the source’s transaction logs, which is why CDC preserves transactional integrity on the target and why the source’s log retention has to be long enough to cover the whole full-load phase.
Schema conversion
Section titled “Schema conversion”A heterogeneous migration needs the schema translated before the data can land. DMS Schema Conversion is the managed feature that does this: it reads the source metadata, produces an assessment report showing what converts automatically and what needs manual work, converts tables, views, stored procedures and functions, and either applies the result or exports it as SQL scripts. It is built on the engine of the downloadable AWS Schema Conversion Tool (AWS SCT), which is the name older material uses.
Common paths include Oracle and SQL Server to Aurora or RDS for PostgreSQL and MySQL, Db2 to PostgreSQL, SAP ASE to PostgreSQL, and Oracle to Amazon Redshift.
Networking
Section titled “Networking”DMS does not require a VPN. The replication instance lives in a VPC, and the connection to an on-premises source can be made over Direct Connect, a Site-to-Site VPN, or the public internet via a public replication instance behind an internet gateway. Connections to AWS services such as S3 and Secrets Manager can go over VPC endpoints instead of the internet. Pick whichever the security posture and available bandwidth justify, rather than assuming a VPN is a prerequisite.
Large data stores
Section titled “Large data stores”For a source too large to copy over the available bandwidth, the historical pattern was to seed the target from an offline transfer and let CDC catch up. The Snow Family devices that used to serve that pattern are closed to new customers; the current equivalents are a Direct Connect hosted connection procured for the duration of the project, AWS DataSync for the bulk file copy, or a backup restored into the target followed by CDC-only replication.
Going further
Section titled “Going further”Operational runbooks for real Oracle-to-PostgreSQL migrations — CDC checkpoint behaviour, recovery after a failed task, reloading a specific time window — are in the DMS section.