AWS DMS Database Migration Guide

AWS DMS Database Migration Guide

AWS Database Migration Service (DMS) enables you to migrate databases to AWS with minimal downtime. It supports homogeneous migrations (Oracle to Oracle) and heterogeneous migrations (Oracle to PostgreSQL), with continuous data replication (CDC) for near-zero-downtime cutover.

DMS Architecture

Source Database → DMS Replication Instance → Target Database
                        ↓
                 Full Load + CDC (ongoing replication)
                        ↓
                 Cutover when caught up

Migration Types

• Full Load — Migrate all existing data in one batch. Suitable for small databases or when downtime is acceptable.
• Full Load + CDC — Migrate existing data, then continuously replicate changes. Enables near-zero-downtime cutover.
• CDC Only — Replicate only ongoing changes. Useful when full load was done via other means (pg_dump, native export).

Setup Steps

1. Create Replication Instance

aws dms create-replication-instance \
  --replication-instance-identifier prod-migration \
  --replication-instance-class dms.r5.xlarge \
  --allocated-storage 100 \
  --vpc-security-group-ids sg-xxx \
  --replication-subnet-group-identifier my-subnet-group

2. Create Source Endpoint

aws dms create-endpoint \
  --endpoint-identifier source-oracle \
  --endpoint-type source \
  --engine-name oracle \
  --server-name oracle.on-premises.com \
  --port 1521 \
  --username dms_user \
  --password 'xxx' \
  --database-name PRODDB

3. Create Target Endpoint

aws dms create-endpoint \
  --endpoint-identifier target-postgres \
  --endpoint-type target \
  --engine-name postgres \
  --server-name prod-db.xxx.rds.amazonaws.com \
  --port 5432 \
  --username dms_user \
  --password 'xxx' \
  --database-name proddb

4. Create and Start Migration Task

aws dms create-replication-task \
  --replication-task-identifier oracle-to-postgres \
  --source-endpoint-arn arn:aws:dms:...:source-oracle \
  --target-endpoint-arn arn:aws:dms:...:target-postgres \
  --replication-instance-arn arn:aws:dms:...:prod-migration \
  --migration-type full-load-and-cdc \
  --table-mappings file://table-mappings.json \
  --replication-task-settings file://task-settings.json

Schema Conversion (Heterogeneous)

For cross-engine migrations, use AWS Schema Conversion Tool (SCT) first:

# SCT converts:
# - Table definitions
# - Views
# - Stored procedures (with manual review)
# - Indexes and constraints
# - Data types (Oracle NUMBER → PostgreSQL NUMERIC)

# Typical conversion rate:
# - 80% automatic conversion
# - 20% requires manual review/rewrite

CDC Configuration

Requirements for source database CDC:

• Oracle: Enable supplemental logging and LogMiner/Binary Reader
• MySQL: Enable binary logging (binlog_format=ROW)
• PostgreSQL: Set wal_level=logical, install test_decoding plugin
• SQL Server: Enable MS-CDC on tables

Cutover Process

1. Monitor CDC lag — Wait until replication lag is under 1 minute
2. Stop application writes — Briefly pause the application
3. Wait for CDC to catch up — Verify zero lag (typically seconds)
4. Switch application connection — Point to the new database
5. Verify data integrity — Run validation queries
6. Resume application — Total downtime: typically 2-5 minutes

Validation

# DMS provides built-in data validation
"ValidationSettings": {
  "EnableValidation": true,
  "ValidationMode": "ROW_LEVEL",
  "ThreadCount": 8
}

Eazy SaaS Tip: We always run a full rehearsal migration before the production cutover. This identifies schema conversion issues, validates CDC performance, and gives the team confidence in the cutover process. Rehearsal typically reveals 3-5 issues that would have caused problems in production.