AWS Database Migration Service Cutover Checklist for a Low-Downtime Database Move

Each task can be processing a different source transaction point. The correct approach is to set a commit stop time so every task processes all transactions committed on or before that timestamp, verify CDC lag and error counts, and define rollback eligibility before the first write lands on the target.

Decide whether DMS fits the source and destination

AWS Database Migration Service offers three task types: full load, CDC, and full load with CDC. A reduced-downtime migration uses full load with CDC or a two-phase approach that runs full load first and then starts a CDC-only task. Both keep the source database operational while the service replicates changes. After the full load completes, the target stays synchronized with the source for as long as you choose, and you switch applications at a time you select.

Aurora PostgreSQL 3.4 with PostgreSQL 11.9 compatibility or higher supports DMS CDC. Amazon RDS for PostgreSQL requires PostgreSQL 11.x or higher. DMS uses logical replication slots to retain write-ahead logs (WAL) until they are decoded. The test_decoding plugin decodes all schema table updates, while pglogical decodes only the tables in the replication scope. When you replicate every table, test_decoding is simpler; when you replicate a subset, pglogical consumes less bandwidth, CPU, and I/O.

DMS supports CDC for PostgreSQL tables with primary keys. If a table doesn't have a primary key, the write-ahead logs don't include a prior image of the database row, and DMS ignores DELETE and UPDATE record operations for that table during ongoing replication. You can use the table-level parameter replica identity as a workaround.

Prepare access, backups and a rollback point

You enable logical replication by setting rds.logical_replication to 1 in the custom parameter group. This static parameter requires a writer instance reboot. You then create a PostgreSQL replication slot using the test_decoding plugin for each database that requires ongoing replication. Create the slot during low traffic because the source database generates WAL logs for all changes, and those logs take up storage until replication starts.

For the initial load, the documented cross-account Aurora PostgreSQL example uses Aurora cloning for Aurora PostgreSQL and DB snapshot restore for Amazon RDS for PostgreSQL. You share the source DB cluster with the target account using AWS Resource Access Manager and share the AWS KMS customer managed key used to encrypt the cluster. The target account accepts the invitation and creates a clone. While the clone is being created, you capture the LSN of the source database using the aurora_volume_logical_start_lsn() function for Aurora PostgreSQL or pg_current_wal_lsn() for Amazon RDS for PostgreSQL. You record the LSN immediately after the clone or snapshot starts to ensure no transactions are missed.

Before you start, decide which rollback strategy fits your migration and whether target-side writes may be lost, regenerated, or copied back. AWS documents four strategies: basic fallback, fall forward, dual write, and bidirectional replication. Basic fallback points the application back to the original source and ignores or accepts the loss of any transactions consumed on the new target. This works for read-only systems, batch systems that haven't applied transactions to the target, or logging systems where target-side transactions can be regenerated or are not required after rollback.

Fall forward creates a third database that is a replica of the original source. You replicate from source A to target B, and from B to a replica of A called A'. At cutover, applications write to B, and the replication stream from B to A' keeps A' synchronized. If you must abandon the migration, you stop writing to B and point applications to A', which has consumed any transactions written to B. This approach allows end-to-end testing, is appropriate for heterogeneous migrations, and ensures the rollback system remains in sync with the target. Dual write modifies the application to write transactions to both databases simultaneously.

Confirm that recovery-point backups exist for both source and target before you start the CDC task.

Configure and record the example migration

You configure the DMS replication instance, source endpoint, and target endpoint in the target account. The source endpoint uses the source cluster writer endpoint, and the target endpoint uses the target cluster writer endpoint. You create a CDC-only migration task, set the CDC start position to the recorded LSN, and define table mappings. The task starts replicating changes from the recorded LSN forward.

The documented cross-account example runs on PostgreSQL 13.7, uses AWS DMS 3.4.7, and requires VPC peering or AWS Transit Gateway connectivity between accounts. The source and target security groups must permit the documented DMS connections. The source and target DB clusters must use an AWS KMS customer managed key for encryption to support cross-account cloning and DB snapshot sharing; the default Amazon RDS AWS KMS key (aws/rds) is not supported.

DMS uses exponential backoff for recoverable errors. With default settings, RecoverableErrorThrottlingMax allows an individual wait between retry attempts to grow to 1,800 seconds (30 minutes). The documented fail-fast configuration sets RecoverableErrorCount to 5, RecoverableErrorInterval to 15 seconds, RecoverableErrorThrottling to true, RecoverableErrorThrottlingMax to 180 seconds, and RecoverableErrorStopRetryAfterThrottlingMax to true. The task retries at 15s, 30s, 60s, and 120s, then stops before the next interval would reach 180 seconds. Total observed time before the task stopped was approximately 225 seconds in a PostgreSQL test using DMS 3.5.x. This surfaces failures in three to four minutes instead of allowing silent retries to stretch over half an hour. Neither the documented example nor the fail-fast test establishes a guaranteed failure time or a universal lag threshold.

Validate data and replication before cutover

Change data capture latency (CDCLatencyTarget) and task status tell you whether the target is catching up. A CDC task in the "running" state does not guarantee the target is current. Replication lag measures how far behind the task is processing source transactions. The CDCLatencyTarget CloudWatch metric reports the gap in seconds between the source transaction commit time and the time DMS applies that transaction to the target. You set a CloudWatch alarm on that metric and watch for sustained increases. Define acceptable latency and zero-error thresholds for your workload; the sources supply no universal numeric thresholds for CDC lag, outage, data loss, or rollback deadline.

When you split a high-transaction database into multiple CDC tasks to reduce replication latency, each task can reach a different source transaction point. Stopping the tasks independently does not guarantee the target is consistent. DMS commit stop time solves this: you provide a source commit timestamp, and every task continues until it processes all transactions committed on or before that time, then stops.

To set commit stop time via the AWS DMS console, open your migration task, choose Modify on the Actions menu, select Specify commit stop time, enter your desired stop time, and start the migration task. The task automatically stops when it reaches the transaction point corresponding to the specified date. To set commit stop time with the AWS CLI, use:

aws dms modify-replication-task --replication-task-arn <task_arn> --cdc-stop-position commit_time:<yyyy-MM-dd'T'HH:mm:ss>

Data validation compares row counts, checks for missing or extra rows, and confirms that replicated rows match the source. DMS offers a built-in validation feature that runs validation queries on tables with a primary key or unique key. You enable validation in the task settings and review the validation state on the table statistics page. The documented example does not provide specific row-level or aggregate validation queries or application smoke tests. When CDC latency drops to a workload-appropriate range and error counts remain at zero, the target is ready for your chosen validation.

Cut over or roll back

Cutover requires stopping writes to the source, waiting for CDC latency to reach zero, stopping the DMS task, redirecting the application to the target, and confirming the application functions correctly. If you use sequences, you update the NEXTVAL of each sequence in the target database to match the source because DMS does not advance sequences during replication. After cutover, the source database remains available for rollback if needed. The sources do not establish a universal application connection and write-pause sequence.

Document the rollback trigger: what error, performance threshold, or data inconsistency will force a rollback. Do not accept the first write on the target until the rollback plan is documented and the rollback system (the original source, A' in a fall-forward architecture, or the dual-write application) is confirmed ready.

Verification status: Supported by official documentation only under the conditions below; not reproduced in a test environment by IGPROD. Checked 2026-10-24.

Conditions:

• The documented cross-account example focuses on Aurora PostgreSQL-Compatible Edition, with differences for Amazon RDS for PostgreSQL.
• For that example, the source and target accounts need VPC peering or AWS Transit Gateway connectivity.
• For that example, source and target security groups must permit the documented DMS connections.
• The multiple-task consistency guidance applies when separate CDC tasks can reach different source transaction points.
• Basic fallback to the original source is suitable only when target-side transactions can be lost, regenerated, or copied back.

Related guides

• One-click container database export: a quick dump of a database that runs in Docker.

Sources:

• Cloud Database Migration (aws.amazon.com)
• Database Migrations on AWS (aws.amazon.com)
• AWS Database Migration Service Documentation (aws.amazon.com)
• Detect CDC failures faster with AWS DMS | AWS Database Blog (aws.amazon.com)
• Rolling back from a migration with AWS DMS | AWS Database Blog (aws.amazon.com)
• Achieve transaction consistency on your target database when using multiple tasks with AWS DMS repl…
• Cross-account Amazon Aurora PostgreSQL and Amazon RDS for PostgreSQL migration with reduced downtim…