AWS Database Migration Service (DMS): What It Is and When to Use It

Definition

AWS Database Migration Service (DMS) is a managed service that migrates databases to AWS, from AWS, and between AWS services with minimal downtime. It supports homogeneous migrations (same engine to same engine, e.g., on-prem PostgreSQL → Aurora PostgreSQL) and heterogeneous migrations (different engines, e.g., Oracle → Aurora PostgreSQL) using continuous replication (CDC) so source databases stay online while the target catches up. For heterogeneous schemas, the AWS Schema Conversion Tool (SCT) converts DDL and procedural code, and DMS Serverless auto-scales replication capacity for hands-off migrations.

How It Works

A DMS migration has three moving parts:

1. Replication instance — a managed EC2 instance (or a Serverless equivalent) that runs the migration workload. You pick an instance class sized for the data volume and change rate. Can be Multi-AZ.
2. Source endpoint — connection details for the database you're migrating from. Supported sources include Oracle, SQL Server, MySQL, PostgreSQL, MariaDB, SAP ASE, IBM Db2, MongoDB, S3, Kafka, Kinesis, DocumentDB, Neptune, and more.
3. Target endpoint — where data lands. Targets include RDS, Aurora (MySQL/PostgreSQL), Redshift, S3, DynamoDB, OpenSearch, Kinesis, Kafka, DocumentDB, Neptune, Babelfish for Aurora PostgreSQL (for SQL Server source compatibility), and more.

On top of these, you define migration tasks in one of three modes:

• Full load — copy the existing data once.
• CDC-only — stream ongoing changes from the source transaction log.
• Full load + CDC — bulk-copy the dataset, then continuously apply changes until cutover.

DMS reads the source transaction log (redo log, binlog, WAL), translates changes, and applies them to the target. When caught up, you schedule a short cutover: stop writes to the source, drain remaining changes, and switch the application.

Schema Conversion Tool (SCT)

For heterogeneous migrations, SCT analyzes the source schema and procedural code (stored procedures, functions, views, triggers), converts what it can automatically, and produces an action-item report for the rest. It targets Aurora/RDS engines, Redshift, and more. SCT runs locally on a workstation or in AWS DMS Schema Conversion (the managed service).

DMS Serverless

DMS Serverless replaces the replication-instance class with an auto-scaling capacity model measured in DMS Capacity Units (DCUs). Capacity scales up and down with workload — useful for long-running CDC replication jobs where you'd otherwise overprovision.

Key Features and Limits

Source and target engines

Sources: Oracle, SQL Server, MySQL/MariaDB, PostgreSQL, SAP ASE, Db2, MongoDB, DocumentDB, S3, Kafka, Kinesis, Azure SQL, Google Cloud SQL.

Targets: RDS, Aurora MySQL/PostgreSQL, Redshift, S3 (Parquet/CSV/JSON), DynamoDB, DocumentDB, OpenSearch, Kinesis, Kafka, Neptune.

Migration modes

• Full load, CDC-only, Full load + CDC.
• Parallel load for large tables (partitioned by ranges).
• Table mapping rules with transformations (rename, filter, case changes).
• Validation — compare source and target rows after full load.

Reliability and limits

• Multi-AZ replication instances for HA during long-running migrations.
• Automatic task restart on failure; checkpoint/log retention to resume CDC.
• CloudWatch metrics for CDC latency, throughput, errors.
• Replication-instance classes range from dms.t3.micro to dms.r6i.24xlarge.
• Some source/target pairs have caveats (LOB handling, unsupported data types) — consult the DMS docs.

Common Use Cases

1. Oracle → Aurora PostgreSQL (or RDS PostgreSQL) — the flagship heterogeneous DMS migration, paired with SCT and often Babelfish for Aurora PostgreSQL to ease stored-procedure conversion.
2. SQL Server → Aurora MySQL/PostgreSQL — consolidate licensing costs and move to an open-source engine.
3. On-prem MySQL/PostgreSQL → Aurora — homogeneous lift with minimal downtime via CDC cutover.
4. RDS → Aurora — consolidate onto Aurora for higher throughput, more replicas, Global DB.
5. Cross-Region or cross-account database relocation — DMS replicates between two AWS databases as source and target.
6. Continuous CDC into a data lake / warehouse — target S3 (Parquet) for Athena/Redshift Spectrum, or Redshift directly.
7. Database consolidation — merge many small databases into a single larger Aurora cluster.

Pricing Model

• Replication instance-hours — per instance class, plus Multi-AZ surcharge.
• Storage — EBS volume attached to the replication instance (for CDC log staging), per GB-month.
• Data transfer — free into DMS from the same Region; standard AWS rates otherwise.
• DMS Serverless — per DCU-hour, auto-scaled.
• SCT — free to download and run; AWS DMS Schema Conversion (the managed service) charges for the assessment runtime.
• Validation — runs on the replication instance; no extra charge beyond instance time.

Pros and Cons

Pros

• Minimizes downtime via full-load-plus-CDC cutover.
• Supports an extremely broad matrix of sources and targets.
• SCT automates much of heterogeneous schema conversion.
• DMS Serverless removes capacity planning for long-running tasks.
• Validation catches data drift during and after migration.

Cons

• Heterogeneous migrations still require manual work for complex PL/SQL, triggers, custom types.
• Large-object (LOB) handling has well-known caveats — plan and test early.
• CDC lag can spike during DDL storms, massive bulk loads, or index rebuilds on the source.
• Post-migration application testing is often underestimated.
• Not a query offload tool — DMS is about moving data, not federated queries.

Comparison with Alternatives

| | DMS | Native logical replication | Aurora Blue/Green | Snow Family | | --- | --- | --- | --- | --- | | Use case | Hetero/homo DB migration, CDC | Same-engine replication | In-place Aurora upgrades | Offline bulk transfer | | Engines | 20+ sources, many targets | Engine-specific | Aurora MySQL/PostgreSQL only | Any large files | | Downtime | Minimal | Minimal | Seconds | Import window | | Best for | Most DB migrations | Same-engine online replica | Major version upgrades | Petabyte offline transfer |

Pick DMS for anything involving heterogeneous engines, CDC over the internet/Direct Connect, or unusual source/target combinations. Use Aurora Blue/Green for Aurora-to-Aurora upgrades. Use AWS Snow Family when the dataset is too large to migrate over the wire in a reasonable window.

Exam Relevance

• Solutions Architect Associate (SAA-C03) — "migrate Oracle to Aurora PostgreSQL with minimal downtime" → DMS + SCT + full-load-plus-CDC.
• Developer Associate (DVA-C02) — occasionally appears in deployment and migration scenarios.
• Database Specialty (DBS-C01) — heavy coverage: replication-instance sizing, CDC internals, LOB modes, validation, Multi-AZ, DMS Serverless, SCT assessment reports, migrating to/from Redshift and S3.
• Data Engineer Associate (DEA-C01) — DMS → S3 for data-lake hydration; DMS → Redshift patterns.

Exam trap: "heterogeneous migration, different engines" → DMS + SCT. "continuous replication for minimal downtime cutover" → DMS with full-load-plus-CDC. "Aurora major version upgrade with quick rollback" → Aurora Blue/Green, not DMS.

Frequently Asked Questions

Q: What's the difference between DMS and the Schema Conversion Tool (SCT)?

A: DMS moves data — bulk rows and ongoing transaction-log changes — between a source and target. SCT converts schema and procedural code (DDL, stored procedures, triggers, views) between different engines. In a typical heterogeneous migration, you run SCT first to create the target schema (and review action items for anything SCT couldn't convert automatically), then run DMS to migrate the data with full-load-plus-CDC. The two tools are complementary, not alternatives.

Q: How do I migrate with near-zero downtime using DMS?

A: Use the full-load-plus-CDC task mode. DMS first bulk-copies the existing data, then automatically switches to reading the source transaction log and applying changes to the target continuously. When the application is ready to cut over, you briefly stop writes on the source, wait a few seconds for DMS to drain the remaining changes (monitor CDCLatencyTarget), verify with DMS validation, repoint the application to the target, and resume traffic. Cutover windows of under a minute are typical for well-prepared migrations.

Q: When should I use DMS Serverless instead of a provisioned replication instance?

A: Use DMS Serverless when the migration workload is long-running, bursty, or hard to size — for example, ongoing CDC replication where the change rate varies throughout the day, or multi-task migrations where each task has different resource needs. Serverless scales capacity (DCUs) automatically, removing the risk of under-provisioning (causing CDC lag) or over-provisioning (paying for idle capacity). Stick with provisioned replication instances when you need specific networking configurations not yet supported on Serverless or when you require deterministic capacity.

---

This article reflects AWS features and pricing as of 2026. AWS services evolve rapidly — always verify against the official AWS DMS documentation before making production decisions.