Migrations & Upgrades
The cluster keeps serving while it moves.
Version upgrades and platform moves are where Cassandra teams most often want outside help — the procedures are well-understood but unforgiving, and most teams run them rarely enough that nobody remembers the sharp edges. We run them often.
Major-version upgrades
Cassandra 3.x to 4.x to 5, sequenced correctly: pre-flight checks (SSTable formats, deprecated settings, driver compatibility), rolling node-by-node upgrades under quorum, upgradesstables scheduling that doesn't starve compaction, and rollback criteria agreed before the first node moves. Cassandra 4 and 5 bring real operational wins — faster streaming, better repair, native vector types on 5 — and we make sure you land on them without a read-availability dip.
DSE and open-source moves
Moves between DataStax Enterprise and open-source Cassandra in either direction: feature-dependency audit first (search, analytics, graph, advanced security), then a node-replacement or datacenter-swap plan that respects the compatibility matrix between DSE releases and Apache versions.
Self-managed to Astra DB
For teams done with running their own nodes: schema translation and validation against Astra's guardrails, data movement sized to your change rate, and driver cutover with credentials and connection changes rehearsed in staging.
Zero-downtime dual-write cutovers
When the data cannot stop moving, we run the dual-write pattern properly: writes mirrored to the target, historical backfill, continuous reconciliation with checksummed row counts, a read-shadowing phase to prove the target under production load, and only then the read cutover — with the old path kept warm until the agreed soak period ends. No big-bang weekend migrations.
What you get
A written migration plan with rollback points at every phase, executed with your team by the hour — or handed over as a runbook your team executes with us on call.