Migration from Cassandra

Because the data model, CQL and wire protocol match, applications usually connect unchanged. The work is in moving the data and re-verifying operations.

Assess first

• Feature parity. List what you depend on — materialized views, secondary indexes, specific CQL functions, CDC, UDFs — and confirm each against the exact ScyllaDB version.
• Tooling. Anything built on JMX must be rewritten against the Prometheus endpoint. Backup, repair scheduling and dashboards all change.
• Driver. Moving to a shard-aware driver is what delivers much of the benefit.
• Node sizing. Fewer, larger nodes is the usual target shape; plan replication factor and rack placement for the new topology rather than copying the old one.

Migration paths

SSTable loading. ScyllaDB can read Cassandra SSTables. Snapshot the source, copy the files, and stream them in:

# On the source, per node.
nodetool snapshot -t migration shop
 
# On the target cluster.
sstableloader -d 10.30.1.10,10.30.1.11 /backups/shop/events_by_user

sstableloader handles a changed topology, so the node counts and token assignments do not need to match.

ScyllaDB Migrator. A Spark-based tool that reads from Cassandra and writes to ScyllaDB, with support for validation and resumable transfers. The better choice for very large datasets or when transformation is needed.

Dual write. The application writes to both clusters during a transition window, with a backfill of historical data. The most control and the most application work; it is the only path that keeps both systems continuously current for an unbounded period.

Procedure

1. Build the ScyllaDB cluster and create the schema from DESCRIBE SCHEMA output, adjusting compaction strategies and any unsupported options.
2. Migrate historical data with one of the paths above.
3. Keep the target current — dual write, or repeated incremental transfers.
4. Verify: row counts per table where feasible, targeted partition reads for known keys, and a sample of application queries run against both clusters and compared.
5. Load-test the target with production-shaped traffic. This is where shard imbalance from an inadequate partition key becomes visible.
6. Cut reads over gradually, then writes.
7. Keep the Cassandra cluster intact and restorable until a full business cycle has passed.