Data Migration Services

Change Data Capture reads the database's transaction log (binary log on MySQL, WAL on PostgreSQL) and streams every insert, update, and delete as an event in real time, with the exact data that changed. For zero-downtime migration: the initial data load copies all existing data to the target database. Once the initial load completes, CDC streams every subsequent change from the source to the target keeping the target in near-real-time sync while the source remains live. When the target has caught up (replication lag < 1 second), the application is cut over to the target database typically a few seconds of read-only mode or a brief maintenance window to ensure the final transactions are applied. After cutover, the source is kept in read-only mode for a parallel running period to validate data consistency. AWS DMS implements CDC for supported source databases (MySQL, PostgreSQL, Oracle, SQL Server, MongoDB). Debezium is the open-source alternative for teams managing their own CDC infrastructure.

Every migration has a tested rollback path. Pre-migration snapshot: full RDS snapshot taken immediately before migration start restores the original state in 10-20 minutes if the migration fails catastrophically. Dual-write rollback: while in dual-write mode, reverting to the old database requires only changing the feature flag or application configuration no data reconstruction. Post-cutover rollback window: for 24-48 hours after cutover, the old database remains in read-only mode rollback requires switching the connection string back, then replaying any writes that occurred on the new database against the old one (requires CDC capture of post-cutover writes). ClickMasters documents rollback procedures, tests them in staging, and includes them in the cutover runbook. The rule: a migration without a tested rollback plan is not a migration it's a gamble.