Most teams that ask us about Astra DB are not asking about Astra DB. They are asking whether they can stop carrying a cluster whose only two experts have left, without taking an outage and without betting the quarter on a one-shot cutover. That is a migration question, and the answer is a sequence, not a tool.
The sequence below works for self-managed Cassandra to Astra DB. With small changes it also works for DSE to open-source, open-source to DSE, or cluster-to-cluster moves within your own estate. The shape is the same: write to both, backfill the past, verify reads, shift traffic, keep the door open behind you.
Step 0: decide whether to move at all
We will say the unpopular thing first. Astra DB removes operational work — repairs, compaction tuning, node replacement, upgrades — and charges for it on a consumption model. That trade is good when your team's scarce resource is Cassandra operators, and bad when your scarce resource is budget and you already have competent operators.
Check three things before you plan anything:
- Feature surface. Astra DB is Cassandra-compatible, not Cassandra. Confirm the specifics your application depends on: custom compaction settings,
ALLOW FILTERINGhabits, UDFs, materialized views, batch sizes, any DSE-only feature (Search, Graph, Analytics) if you are leaving DSE. DSE Search in particular has no drop-in successor; that workload needs its own plan, possibly SAI or an external search index. - Cost at your real write volume. Price the consumption model against your actual write and read unit counts plus storage, not a rounded estimate. High-write telemetry workloads are exactly where the two models diverge most.
- Data residency and network path. Private endpoints, region placement, and latency from your application tier. An extra 15 ms per query on a read-heavy path is a design change, not a footnote.
If the answer is "stay self-managed and fix the operations," that is a legitimate outcome. We have written that recommendation more than once.
Step 1: model review before migration, not after
A migration is the last cheap moment to fix a data model, and the worst moment to discover one is broken. Before you move a byte, re-check the things that do not survive scale: partition sizing (aim well under 100 MB and under roughly 100,000 rows per partition), unbounded partitions that grow forever, secondary-index misuse, and tables whose delete patterns generate tombstones by design.
Migrating a bad model to a managed platform buys you a bad model that someone else reboots. Fix or at least document it now, and decide explicitly which fixes ride along with the migration and which are deferred — dual-write migrations can absorb a schema change, but only if you decided so deliberately.
Step 2: schema and driver parity
Export the keyspace schema (cqlsh -e "DESCRIBE KEYSPACE ks"), strip what Astra manages for you — replication settings, most compaction and GC-grace tuning — and apply the rest. Expect to reconcile a short list of rejected statements; that list is a useful inventory of your cluster's accumulated local tuning.
On the application side, point a second driver instance at Astra using the secure connect bundle. Keep the two client configurations side by side in code, not in branches. Consistency level mapping deserves a deliberate read: your LOCAL_QUORUM assumptions should be re-stated explicitly rather than inherited.
Step 3: dual writes
Turn on writes to both targets behind a flag, with the origin cluster still authoritative.
Three rules make this step safe:
- Origin first, and it owns the response. The write to Astra is secondary. If it fails, log it, count it, and do not fail the user request. Alert on the failure rate, not on individual failures.
- Same timestamps. Write with explicit client-side timestamps (
USING TIMESTAMP, or driver-level timestamp generation) so the backfill and the live stream converge on last-write-wins correctly. This is the single most common cause of "the data is subtly wrong" after a dual-write migration. - Idempotence and no
now()-style server values. Anything generated per-write must be generated once, in your application, and sent to both targets.
Run dual writes long enough to see a full traffic cycle — a weekday peak and a weekend, at minimum — before you trust them.
Step 4: backfill the history
With new writes flowing to both, copy the past. The DataStax Zero Downtime Migration toolkit (the proxy plus DSBulk-based loaders) is built for this and is worth using rather than writing your own; for smaller keyspaces, DSBulk unload/load is often enough.
The key property: because backfilled rows carry their original write timestamps, live dual-writes with correct timestamps always win over stale backfilled versions. That is what makes the two streams safe to run in either order. Verify this property on one table in staging before you run it on twenty tables in production.
Expect backfill to be the long pole — days to weeks for multi-terabyte keyspaces — and throttle it so it does not starve compaction or reads on the origin cluster.
Step 5: shadow reads and verification
Do not cut over on the strength of a row count. Row counts match while values are wrong.
Run shadow reads: serve the user from the origin, issue the same read against Astra, compare, and record mismatches with enough context to debug them. A small mismatch rate at first is normal — you are catching in-flight writes — and it should decay toward zero. If it plateaus, you have a real bug: usually timestamps, a null-versus-unset difference, or a code path that writes to only one target.
Add a sampled full-row comparison across partitions for the tables that matter most, and compare read latency distributions, not averages. p99 is where a change of network path shows up.
Step 6: cut over, reversibly
Flip reads first, service by service, starting with the one whose blast radius is smallest. Keep writing to both. This is the state you want to sit in for days: Astra authoritative for reads, origin still fully current, rollback available as a flag flip rather than a project.
Only after reads are stable across a full traffic cycle do you make Astra the authoritative write target. Keep dual writes running — now with origin as secondary — until you are confident. Then, and only then, retire the origin cluster, after a final snapshot you keep well past the point anyone will need it.
Step 7: the week after
The migration is not done when traffic moves. Re-baseline alerting against Astra's metrics, confirm your consumption costs match the model you priced, and remove the dual-write scaffolding from the code before it rots into something nobody dares delete.
The honest summary
Zero downtime is not achieved by a tool. It comes from an ordering that keeps a correct rollback available at every step, plus verification strong enough that you never have to use it. Every step above exists to catch a specific failure: wrong timestamps, an unmigrated code path, a model that was already broken, a cost model nobody priced.
If you are planning a move — to Astra DB, off DSE, or between clusters — and want a second pair of eyes on the sequence, that is the kind of engagement we take by the hour. Tell us the cluster size, the write rate, and the tables that worry you.