Phase 4: Astra Cutover and Drivers

Cutover is where traffic moves to the new cluster for good. By this point the data has been copied and validated, dual reads have been running cleanly, and the target is confirmed correct and performant. This page covers switching over and the one change specific to an Astra migration: replacing the Secure Connect Bundle in the application.

Dropping the Secure Connect Bundle

Applications connect to DataStax Astra DB through a Secure Connect Bundle (SCB): a bundle of mutual-TLS material and metadata that points the driver at the Astra endpoint, with an application token (or client ID and secret) for authentication. The driver is configured with the path to the SCB, not with a list of contact points.

Open-source Apache Cassandra does not use a Secure Connect Bundle. When repointing the application at the new cluster, remove the SCB entirely and connect the way any Cassandra cluster is reached:

• Contact points and port for the target cluster, in place of the SCB path.
• Authentication using the roles and passwords created on the target during the migration (recall that the copy tooling does not migrate credentials, so these were set up manually).
• TLS, if required, configured against the cluster's own certificates. The SCB's certificates are Astra-specific and do not apply to open-source clusters.

Remove every reference to the Secure Connect Bundle

A Secure Connect Bundle has no meaning against an open-source cluster. Before cutover, find every place the application and its deployment reference the SCB path or the Astra token: application code, config files, secrets stores, environment variables, CI/CD pipelines, and sidecars. Each one must be replaced with standard contact points and credentials. A missed reference will leave that component still pointing at Astra after cutover.

Example: the connection change

The exact API depends on the driver and language, but the shape of the change is the same everywhere: replace the Secure Connect Bundle with contact points. Using the Java driver as an illustration:

// Before: connecting to Astra with the Secure Connect Bundle
CqlSession session = CqlSession.builder()
    .withCloudSecureConnectBundle(Paths.get("/secure-connect-astra.zip"))
    .withAuthCredentials("token", "<application-token>")
    .withKeyspace("my_keyspace")
    .build();

// After: connecting to open-source Apache Cassandra with contact points
CqlSession session = CqlSession.builder()
    .addContactPoint(new InetSocketAddress("cass-node1", 9042))
    .addContactPoint(new InetSocketAddress("cass-node2", 9042))
    .withLocalDatacenter("dc1")
    .withAuthCredentials("app_user", "<password>")
    .withKeyspace("my_keyspace")
    .build();

Cutover steps

1. Switch reads to the target in the ZDM Proxy configuration, and confirm through the proxy and cluster metrics that user reads are being served by the new cluster.
2. Validate consistency one more time between Astra and the target using the copy tool's validation mode.
3. Repoint the application directly at the open-source cluster. Deploy the new connection configuration (contact points and credentials, no Secure Connect Bundle) and remove the ZDM Proxy from the path.
4. Retire the Astra database once all traffic is confirmed on the new cluster and backups and operations on it have been verified.

Retiring Astra is irreversible

Once the Astra database is retired, the source cluster is gone and rollback is no longer possible. Retire Astra only after the soak period has passed cleanly and a verified, restorable backup of the new cluster exists.

After reads have switched to the target, leave the proxy in place for a soak period so latency, error rates, and consistency can be observed under real load before repointing clients directly. Removing the proxy and retiring Astra are the irreversible steps; both should follow a clean soak period.

While the ZDM Proxy remains in the query path, system-table reads are routed to the origin (Astra). Once non-system reads are confirmed on the target, repoint clients directly at the new cluster and remove the proxy, at which point system-table reads also move to the target.

Rollback

Up to the point where reads are switched to the target, rollback is low-risk: reconfigure the proxy to route all traffic back to Astra. Once reads have been switched, rolling back means reversing the copy direction (treating the open-source cluster as the source and Astra as the target), which the migration tooling is not designed to do and is not well tested. Treat post-switch rollback as a known risk, and mitigate it by being rigorous in validation: do not switch reads until validation has genuinely passed.

After cutover

Astra handled repair, backup, alerting, and the rest as a managed service. On the new cluster those operations are now owned by the operator. Set them up as described in Post-Migration Operations before the migration is considered complete.