Database migration
Moving databases to AWS with DMS full load and CDC, converting schemas for engine changes, using native tools, and keeping downtime short.
Exam tasks: 4.2 (select a database migration strategy and tools, plan for minimal downtime), 4.3
The decision: is the target the same engine or a different one, how big is the database, and how much downtime can the business accept at cutover?
Choosing an approach
| Method | Engine change | Downtime | Moves secondary objects | Best for |
|---|---|---|---|---|
| DMS full load + CDC | Yes | Minutes | No, only tables and data | Heterogeneous moves, near-zero downtime, many target types |
| DMS homogeneous data migrations | No | Minutes | Yes: indexes, views, procedures, triggers | MySQL, PostgreSQL and MongoDB to their RDS, Aurora or DocumentDB equivalents |
| Native dump and restore | No | Hours, grows with size | Yes | Small to medium DBs with a real outage window |
| Native backup to S3, then restore | No | Hours, plus CDC to shrink it | Yes | SQL Server .bak, Oracle Data Pump, MySQL XtraBackup to RDS or Aurora |
| Read replica promotion | No | About a minute | Yes | RDS MySQL or PostgreSQL to Aurora, or cross-Region moves |
AWS DMS
DMS reads from a source endpoint and writes to a target endpoint. It supports on-premises databases, EC2, RDS and Aurora, plus targets such as S3, Redshift, DynamoDB, OpenSearch, Kinesis and Kafka.
Migration types
- Full load: copies existing rows. Changes made during the copy aren't captured.
- Full load + CDC: copies existing rows while caching changes, applies the cached changes, then keeps replicating ongoing changes until you cut over. This is the default answer for minimal downtime.
- CDC only: replicates changes from a chosen start point, after the bulk data was loaded some other way.
CDC depends on the source's change log, so the source must be configured for it: row-format binary logging on MySQL, logical replication on PostgreSQL, supplemental logging on Oracle, MS-CDC or MS-Replication on SQL Server.
Capacity: instances or Serverless
| Replication instance | DMS Serverless | |
|---|---|---|
| Provisioning | You pick instance class, storage and Multi-AZ | You set minimum and maximum DMS capacity units |
| Scaling | Manual resize | Automatic within your limits |
| Fits | Steady, predictable tasks, fine-grained tuning | Variable loads, many migrations, no capacity planning |
Use Multi-AZ replication instances for long-running CDC tasks, so an AZ failure doesn't stop replication.
Validation and assessment
- Premigration assessments check for unsupported data types, missing primary keys, LOB settings and source configuration before you start.
- Data validation compares source and target rows during and after the load, and reports mismatches per table.
- Table mappings select tables and apply transformation rules such as renaming schemas or dropping columns.
DMS doesn't build your schema
Classic DMS tasks create only basic tables with primary keys. Secondary indexes, foreign keys, stored procedures, triggers and views don't come across. For an engine change, convert the schema first. For a same-engine move, use homogeneous data migrations or native tools.
Triggers and foreign keys during full load
Tables load in parallel, not in dependency order. Enabled foreign keys and triggers on the target cause failures or duplicated side effects. Disable them during the full load and turn them on at cutover.
Changing engines: schema conversion
| DMS Schema Conversion | AWS Schema Conversion Tool (SCT) | |
|---|---|---|
| Where it runs | Managed, in the DMS console | Desktop application you install |
| Does | Assesses complexity, converts schemas and code objects, with generative AI help for harder objects | The same, plus data extraction agents for data warehouses |
| Typical paths | Oracle or SQL Server to Aurora or RDS for PostgreSQL or MySQL | Also Teradata, Netezza, Greenplum and others to Redshift |
Both produce an assessment report showing what converts automatically and what needs manual work. That report is the input to your 7R decision: a database full of vendor-specific code may be better replatformed than converted.
Heterogeneous means two tools
An engine change is always two steps: schema conversion, with DMS Schema Conversion or SCT, then data movement with DMS. An answer offering only DMS for Oracle to PostgreSQL is missing the conversion step.
Native tools
- pg_dump and pg_restore, mysqldump: simple, and they carry every object, but downtime grows with size.
- Oracle Data Pump: export to a dump file, copy it to S3, and import into RDS for Oracle through S3 integration.
- SQL Server native backup and restore: restore a
.bakfile from S3 into RDS for SQL Server. - Percona XtraBackup: restore a physical MySQL backup from S3 into Aurora MySQL.
- Aurora read replica of an RDS instance: create an Aurora replica of RDS for MySQL or PostgreSQL, let it catch up, then promote it. Downtime is the promotion plus the endpoint change.
Large databases
When the database is too large to copy over the network in time:
Start CDC capture first, or note the log position, so no change made during the bulk copy is lost.
Move the bulk offline or natively. Use SCT data extraction agents to write to a Snowball Edge device, or take a native backup and send it over Direct Connect to S3.
Load the target from S3, using DMS or native restore.
Run a DMS CDC-only task from the recorded start point until lag is near zero, then cut over.
Keeping downtime short
- Replicate with CDC until the CDC latency metrics are near zero, then stop application writes.
- Lower the DNS TTL well before cutover so clients move to the new endpoint quickly.
- Run DMS validation and application smoke tests before reopening writes.
- Keep a rollback path: a reverse DMS task from the new target back to the old source, until you trust it.
Scenarios
An engine change needs schema conversion, then DMS full load plus CDC keeps downtime to minutes. Data Pump only works Oracle to Oracle, and Aurora read replicas can only follow RDS MySQL or PostgreSQL sources. A full load without CDC needs an outage far longer than 15 minutes for 6 TB.
An Aurora read replica of an RDS PostgreSQL instance replicates continuously. Promoting it takes about a minute, with no conversion needed. pg_dump means an outage that grows with size, SCT isn't needed for a same-engine move, and a cross-Region snapshot copy doesn't change the engine.
Classic DMS tasks move data and create basic tables only. Secondary indexes and code objects have to come from native tools, schema conversion, or DMS homogeneous data migrations, which do move secondary objects. Instance size affects load speed, not query speed afterwards. CDC affects ongoing changes, and Aurora MySQL supports stored procedures.
Further reading
Server migration
Rehosting servers with Application Migration Service, one-off image imports with VM Import/Export, and the options for VMware estates.
Modernization
Choosing target compute, storage and database platforms for existing workloads, and breaking up monoliths with strangler-fig routing and events.