Database migrations are among the highest-risk components of any cloud migration or modernisation project. Data is your most critical asset - errors, downtime, or data loss are business-critical events. This checklist covers assessment, tooling, schema conversion, validation, and cutover for successful database migration.
On this page
Migration Strategy Selection
| Strategy | Description | Downtime | Risk | When to Use |
|---|---|---|---|---|
| Dump and Restore | Export full backup, restore on target | Hours (downtime window) | Low (simple) | Small databases < 100GB, dev/test, same-engine migration |
| Log-Based Replication | Initial load + continuous CDC (Change Data Capture) | Minimal (minutes for cutover) | Medium | Production, large databases, minimum-downtime requirement |
| Use AWS DMS | AWS managed replication service | Minimal with CDC mode | Medium | AWS targets; supports 20+ source/target engine combinations |
| Schema Conversion (SCT) | Engine change (e.g. Oracle → Aurora PostgreSQL) | Depends on method above | High | Heterogeneous migration - changing database engine |
| Replica Promotion | Promote read replica to primary in cloud | Seconds (DNS change) | Low | MySQL, PostgreSQL - when you've been replicating from on-prem |
Dump and Restore
- Description
- Export full backup, restore on target
- Downtime
- Hours (downtime window)
- Risk
- Low (simple)
- When to Use
- Small databases < 100GB, dev/test, same-engine migration
Log-Based Replication
- Description
- Initial load + continuous CDC (Change Data Capture)
- Downtime
- Minimal (minutes for cutover)
- Risk
- Medium
- When to Use
- Production, large databases, minimum-downtime requirement
Use AWS DMS
- Description
- AWS managed replication service
- Downtime
- Minimal with CDC mode
- Risk
- Medium
- When to Use
- AWS targets; supports 20+ source/target engine combinations
Schema Conversion (SCT)
- Description
- Engine change (e.g. Oracle → Aurora PostgreSQL)
- Downtime
- Depends on method above
- Risk
- High
- When to Use
- Heterogeneous migration - changing database engine
Replica Promotion
- Description
- Promote read replica to primary in cloud
- Downtime
- Seconds (DNS change)
- Risk
- Low
- When to Use
- MySQL, PostgreSQL - when you've been replicating from on-prem
Pre-Migration Assessment Checklist
Cutover Planning & Execution
- 1
Establish a maintenance window
Define the cutover window with business stakeholders. Communicate well in advance. Smaller windows require CDC replication to be running.
- 2
Put application in maintenance mode / stop writes
Halt all write traffic to the source database. For web applications, display a maintenance page. For APIs, return 503.
- 3
Wait for replication lag to reach zero
Monitor DMS task lag. Only proceed when lag reads 0 rows behind. Any remaining lag means data loss.
- 4
Run final data validation queries
Execute your row count and checksum validation queries on both source and target. Must match exactly.
- 5
Update application endpoints to point to new database
Update connection strings in application config, secrets manager, and environment variables.
- 6
Restart applications and run smoke tests
Verify critical application functionality against the new database. All write operations, lookups, and joins.
- 7
Keep source database live as read-only standby for 48–72 hours
Do not decommission the source DB immediately. Maintain it as a rollback option while you verify production stability.
What’s next?