Zero Downtime Migration (ZDM) means the ability for you to reliably migrate client applications and data between CQL clusters with no interruption of service.

ZDM lets you accomplish migrations without the need to change your client application code, and with only minimal configuration changes. While in some cases you may need to make some minor changes at the client application level, these changes will be minimal and non-invasive, especially if your client application uses an externalized property configuration for contact points.

The suite of ZDM tools enables you to migrate the real-time activity generated by your client applications, as well as transfer your existing data, always with a simple rollback strategy that does not require any downtime.

It is important to note that the Zero Downtime Migration process requires you to be able to perform rolling restarts of your client applications during the migration.

See the diagrams of the ZDM migration phases.

Yes! Here’s a fun way to learn.

Now that you’ve seen a conceptual overview of the process, let’s put what you learned into practice.

We’ve built a complementary learning resource that is a companion to this comprehensive ZDM documentation. It’s the Zero Downtime Migration Interactive Lab.

We encourage you to explore this free hands-on interactive lab from DataStax Academy. It’s an excellent, detailed view of the migration process. The lab describes and demonstrates all the steps and automation performed to prepare for, and complete, a migration from any Cassandra/DSE/Astra DB database to another Cassandra/DSE/Astra DB database across clusters.

The interactive lab spans the pre-migration prerequisites and each of the five key migration phases.

DataStax Zero Downtime Migration includes the following:

ZDM Proxy is a component designed to seamlessly handle the real-time client application activity while a migration is in progress. See here for an overview.

Migrating client applications between clusters is a need that arises in many scenarios. For example, you may want to:

Bottom line: You want to migrate your critical database infrastructure without risk or concern that your users' experiences will be affected.

Overall, you can use ZDM Proxy to migrate:

There are many reasons why you may decide to migrate your data and client applications from one cluster to another, for example:

Here are just a few examples of migration scenarios that are supported when moving from one type of CQL-based database to another:

ZDM does not migrate clusters. With ZDM, we are migrating data and applications between clusters. At the end of the migration, your application will be running on your new cluster, which will have been populated with all the relevant data.

Before DataStax Zero Downtime Migration was available, migrating client applications between clusters involved granular and intrusive client application code changes, extensive migration preparation, and a window of downtime to the client application’s end users.

ZDM allows you to leverage mature migration tools that have been used with large scale enterprises and applications to make migrations easy and transparent to end users.

The suite of Zero Downtime Migration tools from DataStax is free and open-sourced.

ZDM Proxy and related software tools in the migration suite include technical assistance by DataStax Support for DSE and Luna subscribers, and Astra DB users who are on an Enterprise plan. Free and Pay As You Go plan users do not have support access and must raise questions in the Astra Portal chat. Luna is a subscription to the Apache Cassandra support and expertise at DataStax.

For any observed problems with the ZDM Proxy, submit a GitHub Issue in the ZDM Proxy GitHub repo.

Additional examples serve as templates, from which you can learn about migrations. DataStax does not assume responsibility for making the templates work for specific use cases.

All the DataStax Zero Downtime Migration GitHub repos are public and open source. You are welcome to read the code and submit feedback via GitHub Issues per repo. In addition to sending feedback, you may submit Pull Requests (PRs) for potential inclusion.

To submit PRs, you must for first agree to the DataStax Contribution License Agreement (CLA).

Yes, and here’s a summary:

For TLS details, see Configure Transport Layer Security (TLS).

ZDM Proxy handles LWTs as write operations. The proxy sends the LWT to Origin and Target clusters concurrently, and waits for a response from both. ZDM Proxy will return a success status to the client if both Origin and Target send successful acknowledgements, or otherwise will return a failure status if one or both do not return an acknowledgement.

What sets LWTs apart from regular writes is that they are conditional. For important details, including the client context for a returned applied flag, see Lightweight Transactions and the applied flag.

ZDM Proxy should not be deployed as a sidecar.

ZDM Proxy was designed to mimic a Cassandra cluster. For this reason, we recommend deploying multiple ZDM Proxy instances, each running on a dedicated machine, instance, or VM.

For best performance, this deployment should be close to the client applications (ideally on the same local network) but not co-deployed on the same machines as the client applications.

This way, each client application instance can connect to all ZDM Proxy instances, just as it would connect to all nodes in a Cassandra cluster (or datacenter).

This deployment model gives maximum resilience and failure tolerance guarantees and allows the client application driver to continue using the same load balancing and retry mechanisms that it would normally use.

Conversely, deploying a single ZDM Proxy instance would undermine this resilience mechanism and create a single point of failure, which could affect the client applications if one or more nodes of the underlying clusters (Origin or Target) go offline. In a sidecar deployment, each client application instance would be connecting to a single ZDM Proxy instance, and would therefore be exposed to this risk.

For more information, see Choosing where to deploy the proxy.

When moving your client applications and data from on-premise Cassandra Query Language (CQL) based data stores (Cassandra or DSE) to a cloud-native database (CNDB) like Astra DB, it’s important to acknowledge the fundamental differences ahead.

With on-premise infrastructure, you have total control of the datacenter’s physical infrastructure, software configurations, and your custom procedures. At the same time, with on-premise clusters you take on the cost of infrastructure resources, maintenance, operations, and personnel.

Ranging from large enterprises to small teams, IT managers, operators, and developers are realizing that the Total Cost of Ownership (TCO) with cloud solutions is much lower than continuing to run on-prem physical data centers.

A CNDB like Astra DB is a different environment. Running on proven cloud providers like AWS, Google Cloud, and Azure, Astra DB greatly reduces complexity and increases convenience by surfacing a subset of configurable settings, providing a well-designed UI known as Astra Portal, plus a set of APIs and commands to interact with your Astra DB organizations and databases.