Phase 0: Assess a DSE Cluster Before Migration

Assessment is purely analytical: no changes are made to the running cluster. The goal is to establish the scope of the migration: which DSE version is in use, which proprietary components are actively used, what DSE-specific syntax exists in the schema, and therefore which migration path applies.

Bring in an AxonOps expert

AxonOps has assessed and migrated many DataStax Enterprise estates, and the assessment is where the awkward cases surface: proprietary components still in use, Transparent Data Encryption, DSE-specific schema, or an uncertain migration path. A no-obligation session with the AxonOps team can validate the findings and work through the options before any change is made: book an expert session.

All commands on this page are read-only and safe to run against a production cluster. Capture the output of every command: the results form the factual baseline for the migration plan, and several outputs (schema, roles, and topology) are required again when the target cluster is built.

Step 1: DSE feature inventory

For each proprietary component, determine whether it is actively used. See DSE proprietary features for the full component list and replacements.

# DSE distribution version (governs SSTable/protocol compatibility)
dse -v

# Ring view: datacenters, racks, load, ownership
nodetool status

# Cluster identity: name, snitch, partitioner, schema agreement
nodetool describecluster

Check whether the optional components are present:

# DSE Search indexes (in cqlsh)
DESCRIBE SEARCH INDICES;

# Graph keyspaces
cqlsh -e "DESCRIBE KEYSPACES" | grep -i graph

# Evidence of Gremlin / TinkerPop activity in logs
grep -ri "Gremlin\|TinkerPop\|graph" /var/log/cassandra/

# Spark / DSE Analytics usage (check for running Spark master/workers and job history)
dse client-tool spark master-address 2>/dev/null

DSE installations may write logs to /var/log/dse/ or another path rather than /var/log/cassandra/; confirm the actual log path before running the grep (check dse.yaml or the systemd unit's StandardOutput/StandardError directives). For the Spark command, 2>/dev/null suppresses stderr; a non-zero exit indicates that Spark is not configured or not reachable on that node, which is distinct from Spark being absent from the cluster. Verify against the DSE node configuration before concluding Spark is not in use.

If a component shows no schema and no activity, it is not in use and its replacement can be skipped entirely.

Step 2: Version and SSTable compatibility

Use the DSE version from Step 1 with the SSTable compatibility table to confirm the migration path:

• DSE 5.1 and earlier (4.x, 5.0, 5.1) are wire- and SSTable-compatible with their underlying Apache Cassandra version, so both paths are available: the CDM + ZDM Proxy path, or the second-datacenter path (after the proprietary classes are remediated), joining an open-source datacenter at the matching Cassandra version and upgrading to 5.0 afterwards.
• DSE 6.0+: EverywhereStrategy system keyspaces and the BTI SSTable format mean open-source nodes do not join the ring out of the box. The CDM + ZDM Proxy path is the safest and recommended approach; a second-datacenter migration is expert-only and must be PoC-proven.

Step 3: Schema audit

DSE extends standard CQL with proprietary syntax. Export the full schema and search it for DSE-specific elements so each one can be mapped to an open-source equivalent before migration.

# Export the complete schema
cqlsh -e "DESCRIBE FULL SCHEMA" > schema_export.cql

# DSE-specific geospatial and date-range data types (no OSS equivalent)
grep -i "PointType\|LineStringType\|PolygonType\|DateRangeType" schema_export.cql

# DSE-specific table/keyspace options and replication strategies
grep -i "nodesync\|TieredCompactionStrategy\|MemoryOnlyStrategy\|EverywhereStrategy" schema_export.cql

# DSE Search indexes
grep -i "SEARCH INDEX\|Cql3SolrSecondaryIndex" schema_export.cql

# DSE Graph schemas (Classic and Core engine)
grep -i "CREATE GRAPH\|system_graphs\|VERTEX LABEL\|EDGE LABEL\|graph_engine" schema_export.cql

# DSE-specific UDF extensions
grep -i "DETERMINISTIC\|MONOTONIC" schema_export.cql

Document every match, along with the open-source replacement strategy from Component Migration.

Step 4: Authentication, security, and configuration audit

These settings must be reproduced (or deliberately replaced) on the target, and on the DSE 5.1 path some proprietary classes must be remediated before an open-source node can join the ring.

# Authentication stack (DSE uses proprietary Dse* classes)
grep -E "^authenticator|^authorizer|^role_manager" /etc/dse/cassandra/cassandra.yaml

# DSE reads a second config file (dse.yaml) that OSS Cassandra does not
grep -A 15 "authentication_options" /etc/dse/cassandra/dse.yaml

# Transparent Data Encryption status (a hard prerequisite to confirm)
grep -A 10 "transparent_data_encryption_options" /etc/dse/cassandra/dse.yaml

# Keyspace replication strategies (look for EverywhereStrategy on dse_* keyspaces)
cqlsh -e "SELECT keyspace_name, replication FROM system_schema.keyspaces;"

Confirm Transparent Data Encryption (TDE) before migrating

If TDE was ever enabled, on-disk data is encrypted with keys held in a DSE-only system keyspace that is readable only inside DSE. TDE status must be established during assessment: if it is in use, the encrypted bytes cannot be read by an open-source node or recovered from a DSE-era backup. TDE-encrypted data must be decrypted (or the encryption layer removed) as part of the migration plan before any SSTable-level movement to the target cluster. Contact AxonOps for guidance on structuring this step.

Step 5: Application and driver inventory

Search the application codebase for DSE-specific driver artifacts and imports (com.datastax.dse, dse-driver, dse-java-driver, dse-python-driver, and so on). DSE also registers a proprietary query handler that enables DSE-only protocol versions (DSE_V1, DSE_V2) and continuous paging; drivers that negotiated those features will not work against open-source nodes. Driver migration is covered in Component Migration.

Discovery checklist

Use this checklist to structure the assessment across teams (infrastructure, DBA, application, security, networking). Where an answer differs per cluster, record it per cluster.

• DSE version (dse -v) for every cluster, production and non-production
• Cluster topology: node count, datacenters, racks, replication factors
• num_tokens / vnode configuration
• Snitch and partitioner
• Which proprietary components are in use (Search, Analytics, Graph)
• DSE-specific CQL in the schema (from Step 3)
• Authentication, authorization, and role-management configuration
• TDE status and, if enabled, scope
• Client encryption (client-to-node, node-to-node)
• Driver artifacts and versions per application
• NodeSync usage and current repair configuration
• OpsCenter usage: dashboards, alerts, backup, repair schedules in place
• Data volume per cluster (drives migration duration)
• Network and firewall constraints between source, target, and tooling

Go / No-Go

Go: every DSE feature is inventoried with a documented replacement strategy, the migration path is chosen, and no unknown dependencies remain.

Rollback: none required, as no changes have been made.

AxonOps monitors DSE and open-source Cassandra with the same tooling, so installing monitoring at this stage (the next phase) provides an accurate, continuously updated inventory of tables, keyspaces, and workload characteristics against which to validate the assessment. See AxonOps for Cassandra.

---

Next: Phase 1: Monitor DSE and capture a baseline.