Database Migration Services

Move to open source Apache Cassandra with zero downtime.

Reduce operational risk and reduce costs

Migrate to our fully managed service for open source technologies.

We can help with one of the biggest challenges in adopting a new database technology.  Let our operational and production experience help you with no downtime migrations.

Whether you currently use Cassandra in-house, DataStax Enterprise or a database with a completely different data model we can provide advice and assistance to ensure your migration is as smooth as possible with little to no disruption to your user base.

Using Instaclustr to plan your open source Apache Cassandra migration will ensure you minimise implementation risk and ensure you start receiving the maximum return on investment for your Cassandra cluster.

We also have experience in moving Cassandra and other data loads between different networking environments. We can help you migrate under the following scenarios.

Let us help!

Other Databases

We have helped several customers move from database technologies including DataStax Enterprise, DynamoDB and MongoDB.

Migrate to open source Apache Cassandra today.

Private to Cloud

We have helped a number of customers migrate from managing their own Cassandra clusters in a private datacenter to public cloud environments.

Cloud to Cloud

We have moved many of our existing customers from self-managed implementations into our service all with zero downtime.

Zero Downtime Migration to Instaclustr Managed Cassandra

1. Prepare the existing environment

Ensure that the app is using a DC aware load balancing policy and LOCAL_*. Ensure that all keyspaces to be copied to the new cluster are using the NetworkTopologyStrategy replication strategy (if not currently set up this way, changing might be tricky – we recommend using this strategy for all keyspaces when you create them).


2. Create the new cluster

Create a new cluster using the Instaclustr console. Ensure the Cassandra version and cluster name are the same as the existing cluster and the data center name is different from the existing data center.


3. Join the clusters

We will make necessary firewall rule changes (some may also be required on the source cluster side) and then change seed nodes in the new cluster and start the nodes so the new cluster becomes a second data center in the existing cluster.



4. Change replication settings

In the existing cluster, the replication settings for keyspaces to be copied will be updated to specify that data should be replicated to the newly added data center.


5. Copy data to the new cluster

Once the cluster are joined, Cassandra will start replicating writes to the new cluster. However, existing data will need to be copied across to the existing cluster by using the nodetool rebuild We will typically execute this one or two nodes at a time on the new cluster to limit the streaming load on the existing cluster.

6. Cutover the application

Once the rebuilds are complete, both cluster will have a complete copy of the data that Cassandra is automatically keeping in synch. At this point, the initial connection points for the application can be changed from nodes in the old cluster to node is the new cluster. The new cluster will serve all reads and writes will go to the new cluster first before being replicated to the old cluster. At this point we will typically run a repair operation across the cluster to fully verify that all data from the existing cluster is successfully replicated.

7. Decommission existing cluster

Connectivity from the existing cluster to the existing cluster is severed by changing firewall rules, replication settings are updated in the new cluster to stop replicating data to the old cluster and the old cluster can be shut down.