AWS Database Migration Service (AWS DMS)

Separate moving data from converting database structure

AWS Database Migration Service (AWS DMS) moves data between supported databases, data warehouses, NoSQL stores, and other data stores. A migration defines the source and target and then uses a DMS migration/replication mechanism to move selected data. DMS is commonly used to reduce migration downtime because it can load existing data and then continue applying changes made at the source while the application remains in service.

For heterogeneous migrations, moving rows is only one part of the problem. Database engines can differ in data types, SQL dialects, stored procedures, functions, and other schema objects. DMS Schema Conversion assesses and converts supported schema and code objects toward the target engine. The distinction is important: schema conversion transforms database structure/code; DMS data migration transfers the data.

Full load and CDC solve different phases

A full-load task copies the existing source data. A full-load-and-CDC workflow also captures ongoing source changes so the target can continue catching up while the application still writes to the source. CDC-only mode starts from a source position/time appropriate to the engine and replicates ongoing changes when the target already has the initial dataset. The correct mode follows whether historical data, ongoing changes, or both need to be transferred.

For full-load-and-CDC tasks, DMS can cache source changes that occur while tables are being initially loaded and then apply those changes as the task transitions toward ongoing replication. This is why CDC is central to low-downtime migration planning. A cutover should be based on measured replication state and application coordination rather than assuming that a task being 'running' means the target has no lag.

• Full load: copy the existing dataset.
• Full load + CDC: copy existing data and then keep applying ongoing changes.
• CDC only: replicate ongoing changes when the target's starting data/state is already established appropriately.
• Table mapping/selection rules determine which schemas, tables, or views participate in supported migrations.

A migration is complete only after validation and cutover planning

Database migration needs validation. DMS provides data-validation capabilities for supported task types, but teams should also test application semantics, permissions, indexes, stored code, performance, and engine-specific behavior on the target. A technically successful row transfer does not prove that the application behaves identically on a different engine or database version.

Observability should include task state, table statistics, latency/CDC lag, errors, and target performance. Before cutover, the team must decide how to quiesce or redirect writes, allow the target to catch up, verify final state, and switch connection configuration. A rollback plan matters because the operational risk is at the application/database boundary, not only inside DMS.