Near-zero-downtime database migration to cloud

WHAT THIS TESTS This evaluates whether you can sequence a migration that protects a mission-critical system, rather than naively exporting and importing during a long outage.

A GOOD ANSWER COVERS Start with assessment: inventory schema, stored procedures, data types, extensions, and application dependencies, and choose a homogeneous or heterogeneous path. Provision and size the target managed instance. Use a full load to seed the target, then enable change data capture so writes that happen during and after the load replicate continuously, keeping source and target in sync. AWS Database Migration Service handles both the initial load and ongoing CDC; the Schema Conversion Tool helps for engine changes. Validate continuously by comparing row counts, checksums, and running the application read-only against the target. When lag is near zero, cut over in a brief window by repointing the application, ideally with replication still flowing backward so you can roll back.

MAJOR RISKS Data drift if CDC misses changes, unsupported or silently coerced data types, replication lag never converging under heavy write load, large objects and sequences not migrating cleanly, and a cutover that strands in-flight transactions. Always rehearse the cutover in staging.

LIKELY FOLLOW-UPS How does CDC capture changes. How do you validate data parity at scale. How do you handle the cutover for sequences and auto-increment. What is your rollback trigger.

ONE CONCRETE EXAMPLE A bank moves a 4 TB Oracle database to Aurora PostgreSQL. They convert schema with SCT, run a DMS full load over a weekend, leave CDC replicating for two weeks while validating reports, then cut the application over during a five-minute maintenance window, keeping the source live for a day as a fallback.