Migrate an OLTP database with minimal downtime

WHAT THIS TESTS This checks whether you can migrate a busy transactional database while keeping downtime to seconds or minutes, using continuous replication rather than a long outage.

A GOOD ANSWER COVERS A phased approach. First take an initial full load: a consistent snapshot of the source loaded into the cloud target. Because the source keeps changing, enable change data capture to read the database transaction log and stream every subsequent insert, update, and delete to the target, so it continuously catches up and then stays in near-real-time sync. While both run in parallel, validate with row counts, checksums, and ideally a read-traffic comparison. The cutover is a short, planned window: stop or quiesce writes to the source, let CDC drain the final changes so target equals source, repoint the application connection string or DNS to the cloud database, smoke-test, and resume writes. Crucially, keep the source intact and the replication reversible so you can roll back if the target misbehaves.

COMMON WRONG ANSWERS A stop-the-world export and import, causing hours of downtime unacceptable for high-uptime OLTP. No CDC, so changes during the long load are lost. No validation step. No rollback plan, so a bad cutover is irrecoverable. Forgetting to handle in-flight transactions and sequences.

LIKELY FOLLOW-UPS How does log-based CDC work? How do you verify data integrity? How do you handle schema differences? What is your rollback trigger and procedure?

ONE CONCRETE EXAMPLE Using AWS Database Migration Service, you run a full-load task into Aurora, then DMS switches to ongoing replication via CDC from the source transaction logs. You monitor replication lag near zero, validate with DMS data validation, then during a brief maintenance window pause application writes, confirm lag is zero, update the connection endpoint, and verify, keeping the on-premise database ready as a fallback.