Skip to main content
A rollback plan defines how you will undo or recover from a failed migration. A clear rollback strategy limits risk during migration, minimizes business impact, and preserves data integrity so that you can retry the migration with confidence. This page explains common rollback options, their trade-offs, and how the MOLT toolkit supports each approach. In general:
  • Manual reconciliation is sufficient for low-risk systems or low-complexity migrations where automated rollback is not necessary.
  • Utilize failback replication to maintain synchronization between the CockroachDB cluster and the original source database after cutover to CockroachDB.
  • Utilize bidirectional replication (simultaneous forward and failback replication) to maximize database synchronization without requiring app changes, accepting the operational overhead of running two replication streams.
  • Choose a dual-write strategy for the fastest rollback with minimal orchestration, accepting higher application complexity during the trial window.

​
Why plan for rollback

Many things can go wrong during a migration. Performance issues may surface under production load that didn’t appear in testing. Application compatibility problems might emerge that require additional code changes. Data discrepancies could be discovered that necessitate investigation and remediation. In any of these scenarios, the ability to quickly and safely return to the source database is critical to minimizing business impact. Your rollback strategy should align with your migration’s risk profile, downtime tolerance, and operational capabilities. High-stakes production migrations typically require faster rollback paths with minimal data loss, while test environments or low-traffic systems can tolerate simpler manual approaches.

​
Failback replication

, which serves to minimize downtime windows, keeps two databases in sync by replicating changes from the source to the target. In contrast, failback replication synchronizes data in the opposite direction, from the target back to the source. Failback replication is useful for rollback because it keeps the source database synchronized with writes that occur on CockroachDB after cutover. If problems emerge during your trial period and you need to roll back, the source database already has all the data that was written to CockroachDB. This enables a quick rollback without data loss. Failback and forward replication can be used simultaneously (bidirectional replication). This is especially useful if the source and the target databases can receive simultaneous, but disparate write traffic. In that case, bidirectional replication is necessary to ensure that both databases stay in sync. It’s also useful if downtime windows are long or if cutover is gradual, increasing the likelihood that the two databases receive independent writes.

​
Dual-write

Failback replication requires an external replication system (like ) to keep two databases synchronized. Alternatively, you can modify the application code itself to enable dual-writes, wherein the application writes to both the source database and CockroachDB during a trial window. If rollback is needed, you can then redirect traffic to the source without additional data movement. This enables faster rollback, but increases application complexity as you need to manage two write paths.

​
Decision framework

Use these questions to guide your rollback strategy: How quickly do you need to roll back if problems occur? If you need immediate rollback, choose dual-write or bidirectional replication. If you can tolerate some delay to activate failback replication, one-way, on-demand failback replication is sufficient. For low-risk migrations with generous time windows, manual reconciliation may be acceptable. How much data can you afford to lose during rollback? If you cannot lose any data written after cutover, choose bidirectional replication or on-demand failback (both preserve all writes). Dual-write can also preserve data if implemented carefully. Manual reconciliation typically accepts some data loss. Will writes occur to both databases during the trial period? If traffic might split between source and target (e.g., during gradual cutover or in multi-region scenarios), bidirectional replication keeps both databases synchronized. If traffic cleanly shifts from source to target, on-demand failback or dual-write is sufficient. Can you modify the application code? If application changes are expensive or risky, use database-level replication (bidirectional or on-demand failback) instead of dual-write. What is your team’s operational capacity? Bidirectional replication requires monitoring and managing two active replication streams. On-demand failback requires a tested runbook for activating failback quickly. Dual-write requires application-layer resilience and observability. Manual reconciliation has the lowest operational complexity. What are your database capabilities? Ensure your source database supports the change data capture requirements for the migration window. Verify that CockroachDB changefeeds can provide the necessary failback support for your environment.

​
MOLT toolkit support

uses change data to stream changes from one database to another. It’s used for both and failback replication. To use MOLT Replicator in failback mode, run the command with its various . When enabling failback replication, the original source database becomes the replication target, and the original target CockroachDB cluster becomes the replication source. Use the flag to indicate the CockroachDB cluster, and use the flag to indicate the PostgreSQL, MySQL, or Oracle database from which data is being migrated. MOLT Replicator can be stopped after cutover, or it can remain online to continue streaming changes indefinitely. Rollback plans that do not utilize failback replication will require external tooling, or in the case of a dual-write strategy, changes to application code. You can still use to ensure parity between the two databases.

​
See also