Skip to content
AxonOps Documentation

AxonOps — AI-Native Control Plane for Open Source Data Platforms

Phase 5: DSE Migration Cutover & Decommission

Cutover finalises the migration: reads switch to the target, all user traffic moves to the new cluster, the proxy leaves the query path, and DSE is decommissioned. This phase applies to the CDM + ZDM Proxy path. On the second-datacenter path, cutover is the decommission of the DSE datacenter described on that page.

Steps

Section titled “Steps”
  1. Switch reads to the target via the ZDM Proxy configuration. Writes are already dual-written; this moves the read path to the new cluster.
  2. Validate consistency one more time between source and target using CDM's validation mode.
  3. Confirm all user reads are hitting the target. Verify through proxy and cluster metrics that non-system reads are served by the new cluster.
  4. Point clients directly at the new cluster and remove the ZDM Proxy. Once confirmed, update the application contact points to the target cluster and take the proxy out of the path.

Decommissioning the source cluster is irreversible

Decommissioning permanently removes the DSE origin; rollback to the source is then impossible. Before proceeding, confirm:

  • no application traffic reaches the DSE nodes (all reads and writes are served by the target);
  • a verified, restorable backup of the source exists;
  • validation (Phase 4) and operational setup (Phase 6) are complete.
  1. Decommission the DSE cluster.

System-table reads stay on the source: this is expected

For as long as the ZDM Proxy remains in the query path, it will always route system table reads to the source (DSE) cluster. This is normal behaviour and not a sign of an incomplete migration. Once all non-system reads are confirmed to hit the target, point clients directly at the new cluster and remove the proxy, at which point system reads move to the target as well.

Go / No-Go

Section titled “Go / No-Go”

Go: all activity is solely on the new cluster, and there is no activity on the DSE cluster.

Rollback

Section titled “Rollback”

Reverse migration is not well-tested: treat it as a known risk

Once reads have been directed to the target, the only rollback is to reverse the ZDM/CDM configuration, designating the Apache Cassandra cluster as the origin and the DSE cluster as the target, then re-running data migration back to DSE. Neither ZDM Proxy nor CDM was designed for this direction, so this reverse path is not well-tested and must be surfaced as a known risk in the migration plan. The practical mitigation is to be rigorous in Validation (Phase 4): do not switch reads until validation has genuinely passed.

Next: Phase 6: Cassandra day-2 operations.