Understand the rollback options

At any point from Phase 1 through Phase 4, if you encounter an unexpected issue and need to stop or roll back the migration, you can revert your client applications to connect directly to the origin cluster.

After addressing the issue, you can restart the migration from the beginning.

Migration phases from start to finish.

Phase 5 is the point of no return

After moving your client applications off the ZDM Proxy instances (Phase 5), writes are no longer sent to both the origin and target clusters. The data on origin cluster is no longer kept up-to-date, and you lose this seamless rollback option. This is the point at which you commit to using the target cluster permanently. The ZDM Proxy deployment can be destroyed, and the origin cluster is no longer needed by the client applications that have been migrated.

However, should you decide to move back to the origin cluster later, or if you want to move to a new cluster entirely, you can rerun the same migration process. In this case, you use your original target cluster as the new origin cluster, and you set the new target cluster to whatever cluster you want to migrate to (which could even be the original ancestor origin cluster).

Was this helpful?

Give Feedback

How can we improve the documentation?

© 2025 DataStax | Privacy policy | Terms of use | Manage Privacy Choices

Apache, Apache Cassandra, Cassandra, Apache Tomcat, Tomcat, Apache Lucene, Apache Solr, Apache Hadoop, Hadoop, Apache Pulsar, Pulsar, Apache Spark, Spark, Apache TinkerPop, TinkerPop, Apache Kafka and Kafka are either registered trademarks or trademarks of the Apache Software Foundation or its subsidiaries in Canada, the United States and/or other countries. Kubernetes is the registered trademark of the Linux Foundation.

General Inquiries: +1 (650) 389-6000, info@datastax.com