Business systems no longer have quiet weekends. E-commerce, payments, logistics and SaaS platforms serve customers around the clock across time zones, and a migration plan that begins with “take the system offline for twelve hours” is increasingly unacceptable. At the same time, migrations are more frequent than ever: from on-premises Oracle and SQL Server to managed cloud databases, between clouds, from self-managed PostgreSQL to managed services, and from legacy engines to modern ones as licensing and support terms change.
Change data capture (CDC) makes it possible to move a live database with only a brief pause in writes. But “zero downtime” is a marketing phrase, not an engineering target. A useful 2026 guide on cross-cloud migration argues that teams should aim for a measured, short write pause and call the result near-zero downtime, because promising none at all encourages unsafe shortcuts. This playbook follows that philosophy: it explains how to plan, execute and validate a CDC-based migration so the pause is predictable, short and reversible.
Define the Contract Before the Technology
The most common reason migrations overrun is that nobody agreed what “success” meant. Before choosing tools, write down a short migration contract with business and technical owners:
- Write-pause budget. The maximum time writes may be paused during cutover, for example five minutes in a low-traffic window.
- Read availability. Whether reads must continue during cutover, and from which system.
- Recovery point objective. How much data loss, if any, is acceptable if the cutover must be aborted after the target is promoted.
- Rollback window. How long after cutover you retain the ability to return to the source.
- Decision rights. Who can pause writes, promote the target, abort the cutover or accept an exception.
This contract drives every technical choice that follows. A five-minute pause with no data loss on rollback requires reverse replication; a thirty-minute pause with fix-forward accepted is far simpler.
How CDC-Based Migration Works
A CDC migration has three overlapping stages. First, an initial load copies the existing data to the target from a consistent point in the source’s transaction log. Second, change data capture reads every insert, update and delete committed after that point and applies it to the target, so the target converges on the source and stays close behind it. Third, cutover briefly stops writes to the source, lets the target apply the final changes, and switches applications to the target.
The main tool families in 2026 are well established:
- Native replication. PostgreSQL logical replication, MySQL binlog replication and similar features work well for homogeneous moves between compatible versions.
- Cloud migration services. AWS Database Migration Service, Google Database Migration Service and Azure’s migration services handle initial load and CDC as managed offerings. AWS DMS Schema Conversion can now also be driven by AI coding agents through the AWS MCP Server, which helps with heterogeneous schema and code conversion.
- Open-source CDC platforms. Debezium streams changes from many databases into Kafka or directly to targets, and supports incremental snapshots that load existing data in chunks while streaming continues, using watermarks to avoid duplicates.
- Commercial replication tools. Products such as Oracle GoldenGate and other enterprise replication suites remain common for complex Oracle estates and bidirectional replication.
The goal is not zero downtime; it is a short, measured, rehearsed write pause with a tested way back. Promise that, and deliver it.
The Phased Playbook
Phase 1: Assess compatibility and risk
Build an exact source-to-target compatibility matrix: versions, data types, character sets and collations, time zones, extensions, partitioning, large objects and features such as sequences, triggers and stored procedures. Identify every table without a primary key or replica identity, because CDC tools need a way to locate rows for updates and deletes. Measure the source’s peak change rate, since the target must apply changes faster than the source produces them, or replication lag will never converge.
Phase 2: Prepare the target and schema
Create the target schema, converting it if the engines differ. Load data before creating most secondary indexes and enabling foreign keys where the tool allows, then add them before CDC catch-up to keep apply performance predictable. Decide how DDL will be handled during the migration; the safest policy is a schema freeze, or a strictly coordinated process where every change is applied to both sides deliberately.
Phase 3: Initial load from a consistent position
Seed the target from a known log position so CDC can start exactly where the load ended. Watch the source closely during this phase: long-running snapshots can hold back log cleanup, inflate replication slots and consume I/O. For very large tables, chunked or parallel loading and incremental snapshots reduce the impact.
Phase 4: Run CDC and converge
Start change capture and monitor lag continuously. Lag should fall steadily to seconds and stay there under peak load. If it does not, fix apply throughput before going further: tune batch sizes, parallelism and target resources, or reduce index overhead. Keep a single writer, the source, throughout this phase.
Instrument the pipeline so the whole team can see its health at a glance: replication lag in seconds and in log position, apply throughput, error and retry counts, source log retention, and target resource usage. Set alerts on lag thresholds and on any error that the tool records but skips, because silently skipped rows are a classic source of post-cutover discrepancies. Review these metrics daily during convergence, and make the dashboard part of the go or no-go decision on cutover day.
Phase 5: Validate continuously
Do not rely on the replication tool’s status page. Run independent comparisons of row counts, aggregates, checksums or hashes, null counts, uniqueness and constraints, starting during the initial load and continuing until cutover. Pay particular attention to data types that commonly diverge: timestamps with time zones, floating-point and decimal precision, character encoding and empty-string versus null semantics.
Phase 6: Rehearse the cutover
Run at least one full rehearsal against a production-shaped environment, and one deliberately aborted cutover, before the real event. Time each step, record surprises and update the runbook. Rehearsals are where you discover that a connection pool caches DNS for an hour, or that a batch job writes directly to the database outside the application.
Use a configuration-controlled endpoint, such as a service discovery entry or a proxy, rather than relying on DNS changes alone, and plan to recycle application instances after draining so that no client keeps a connection to the old host. Agree on communication during the rehearsal too: who announces each step, where status is posted and how business stakeholders are informed. A cutover that is technically perfect but leaves customer support uninformed still feels like an outage to customers.
The Cutover Sequence
A cutover is a checklist, executed calmly in order, with a named person confirming each step:
- Announce the window and freeze deployments and schema changes.
- Confirm replication lag is near zero and validation is green.
- Set the source to read-only and fence all writers, including batch jobs and integrations.
- Drain application connections and record the final source log position.
- Confirm the target has applied changes up to that position.
- Run final validation on critical tables.
- Synchronize sequences and identity columns on the target beyond the highest used values.
- Promote the target and switch application configuration or endpoints.
- Perform a canary write and read through the application, then reopen traffic.
- Keep the source fenced and monitor for any stray writes.
Sequence synchronization deserves emphasis. Logical replication typically does not carry sequence state, so if you forget this step, the first inserts on the target can collide with existing keys. Set each sequence beyond all used values, allowing for cache sizes and any application-side ID allocation.
Heterogeneous Migrations: What Changes
Moving between different engines, such as Oracle to PostgreSQL or SQL Server to a cloud-native database, adds a layer of work on top of the CDC mechanics. The data must be transformed in flight, and the application must be changed to work with the new engine. Plan for these additional activities:
- Schema and code conversion. Tables, views, stored procedures, triggers and functions must be translated. Tools such as AWS DMS Schema Conversion automate much of this and, since 2026, can be driven by AI agents, but converted code still needs review and testing.
- Type mapping decisions. Numeric precision, date and time types, Boolean representations, character lengths and binary data rarely map one to one. Document each decision and test it with real values, including extremes.
- Behavioral differences. Transaction isolation defaults, locking behavior, case sensitivity, null ordering and empty-string handling differ between engines and can change application results in subtle ways.
- Application changes. Queries, drivers, connection strings and ORM configurations must be updated and regression-tested against the target before cutover, ideally by running the test suite against a CDC-fed copy.
- Performance tuning. Query plans differ. Capture the most frequent and most expensive production queries and benchmark them on the target with realistic data volumes.
Because these changes take time, heterogeneous migrations benefit most from a long CDC phase: the target stays current for weeks while application teams test against real, continuously updated data, and cutover happens only when both data and application are ready.
Rollback and Fix-Forward Strategies
Decide before cutover what happens if something goes wrong after the target is promoted. Options include:
- Reverse replication. CDC from the new target back to the old source, started at promotion, allows returning without data loss. It is the most robust option and the most work to set up.
- Replayable change stream. Capture post-cutover changes in a durable log that can be replayed to the source if needed.
- Documented RPO exception. Accept that changes after cutover may be lost or re-entered manually if a rollback is required.
- Fix-forward. Commit to resolving issues on the target, with the source retained only for reference.
Whatever you choose, test it. An untested rollback plan is a hope, not a plan.
A Worked Example: Moving an Order Database Between Clouds
Consider a subscription business moving its PostgreSQL order database from one cloud provider to another to consolidate infrastructure. The database serves customers worldwide, so there is no true off-peak period, but traffic is lowest for a few hours on Sunday morning in its largest market.
The migration contract sets a write-pause budget of ten minutes, continuous reads from the source during the pause, and reverse replication for 72 hours after cutover. Assessment finds three tables without primary keys, which the team fixes in the source first, and a large-object column that native logical replication will not carry, so they move those objects to object storage as part of the project.
The initial load runs over several days from a consistent position, with CDC streaming throughout. Lag stabilizes at a few seconds even at weekday peaks. Nightly validation compares row counts and hashes per partition and highlights one mismatch caused by a time zone conversion in a reporting view, which is corrected before cutover.
Two rehearsals reveal that a nightly export job connects directly to the database with a hard-coded hostname, and that one service’s connection pool ignores DNS changes. Both are fixed. On cutover day, the team completes the checklist in under eight minutes, the canary order succeeds and reverse replication starts immediately. After 72 hours without issues, reverse replication is stopped and the source is decommissioned on schedule.
Pitfalls to Avoid
- Dual writes from the application. Writing to both databases at once risks duplicates, reordering and inconsistent states when one write succeeds and the other’s outcome is unknown. Prefer a single writer and CDC.
- Unconverging lag. If apply throughput is lower than the source change rate, the cutover can never be scheduled safely.
- Forgotten writers. Batch jobs, integrations and administrative scripts that bypass the application must be fenced too.
- Source-only schema changes. An application release that alters the source schema mid-migration can break replication.
- Trusting tool status. Independent validation catches errors the tool cannot see.
- Skipping the abort rehearsal. Knowing how to stop safely is as important as knowing how to finish.
Conclusion
CDC has turned live database migration from a high-stakes gamble into a repeatable engineering process, and in 2026 the tooling, from cloud migration services and Debezium to AI-assisted schema conversion, is mature. What separates smooth migrations from painful ones is discipline: an explicit contract, a compatibility assessment, continuous independent validation, rehearsed cutovers and a tested rollback path. Aim for a short, measured write pause rather than a mythical zero, and the business will barely notice the move.
How Hanoi Technology Can Help
Hanoi Technology plans and executes CDC-based database migrations with continuous validation and rehearsed cutovers, as projects or dedicated teams.