Understand the rollback options

At any point during the migration process until the very last phase, if you hit any unexpected issue and need to (in effect) "rollback" the migration, you can always easily revert your client applications to connect directly to the origin cluster.

The migration can be started from scratch once the issue has been addressed.

Migration phases from start to finish.

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