Phase 2: Replace DSE Search, Analytics, Graph & Security

In this phase, each proprietary DSE component identified in Assessment is replaced with its open-source equivalent. Each replacement should be deployed and validated independently in a staging environment before moving to data migration, so that component issues are isolated from the data-migration work. Replacing DSE Search with OpenSearch, for example, can be designed, deployed, and tested while the DSE cluster continues to serve production traffic unchanged.

Skip any component confirmed to be unused. Many DSE deployments license Search, Analytics, or Graph but never run them in production.

---

Replacing DSE Search with OpenSearch

DSE Search is a modified Apache Solr 6.0.1 (released 2016) with proprietary enhancements. The recommended open-source replacement is OpenSearch, a community-driven, Apache-2.0-licensed search and analytics engine.

A key architectural change is that OpenSearch runs as a dedicated search cluster rather than co-located inside the Cassandra data layer. This separates search scaling from database scaling and removes the resource coupling that DSE Search imposes.

Migration steps

1. Inventory existing DSE Search indexes. For each indexed table, document the indexed columns, analyzers, and query patterns:

   cqlsh -e "DESCRIBE SEARCH INDEX ON keyspace_name.table_name"

2. Deploy an OpenSearch cluster, sized for the search workload. OpenSearch can run on-premises, in a cloud account, or as a managed service.
3. Design OpenSearch index mappings that reproduce the DSE Search schema: field types, analyzers, and keyword vs. text distinctions.
4. Set up data synchronisation to keep OpenSearch current with Cassandra (see below).
5. Translate query patterns from Solr-syntax-via-CQL to the OpenSearch Query DSL.
6. Update application code to call OpenSearch client libraries instead of issuing CQL search queries.
7. Validate by comparing query results between DSE Search and OpenSearch for parity before cutover.

Keeping OpenSearch in sync with Cassandra

Strategy	Best for	Latency	Complexity
Change Data Capture (CDC) → Kafka → OpenSearch sink connector	Real-time sync, high throughput	Sub-second	Medium
Application-level dual writes	Simple architectures, low volume	Immediate	Low
Spark batch jobs	Initial load and periodic full re-sync	Minutes to hours	Low

For most production deployments, a CDC + Kafka pipeline gives the best balance of reliability and latency. Change Data Capture (CDC) was introduced in Cassandra 3.8 (CASSANDRA-8844). Application dual-writes are simpler but introduce a consistency risk if one write fails.

Operating a CDC + Kafka synchronisation pipeline reliably in production is a non-trivial undertaking. Where Kafka is also part of the stack, AxonOps monitors it alongside Cassandra from a single operational view. Contact AxonOps for help designing and operating the synchronisation layer.

---

Replacing DSE Analytics with Apache Spark

DSE Analytics co-locates Spark executors on the same nodes as Cassandra. The open-source approach separates them: Cassandra nodes run the database, and a standalone Spark cluster connects over the network using the open-source spark-cassandra-connector. Co-location is a common source of GC pressure and latency spikes under analytical load; a separate Spark cluster gives independent scaling and resource isolation.

Deployment options

Aspect	Standalone Spark	Spark on Kubernetes (Spark Operator)
Best for	Steady, predictable workloads	Bursty or on-demand workloads
Resource model	Always-on worker pool	On-demand executor pods
Prerequisite	VM or bare-metal Spark cluster	Existing Kubernetes cluster
Scaling	Manual or external automation	Native Kubernetes autoscaling
Isolation	Shared cluster resources	Per-job isolation via pods

Both use the same Apache Spark and spark-cassandra-connector; the difference is purely how Spark is deployed.

Version targets

Regardless of which Spark version DSE bundled (Spark 2.0 to 2.4, all end-of-life), migrate directly to Apache Spark 3.x with spark-cassandra-connector 3.x. The spark-cassandra-connector 3.x supports a range of Cassandra versions including 3.11 and later. For older DSE versions whose underlying Cassandra is in the 2.x line, the connector minor-version compatibility should be confirmed against the project’s compatibility matrix before selecting a connector release.

Migration steps

1. Inventory Spark jobs, including schedules, input/output tables, and resource requirements (executor memory, cores, parallelism).
2. Deploy a standalone Spark cluster on separate hardware, sized from the current DSE Analytics resource usage.
3. Replace DSE-specific imports with open-source connector equivalents. For example, the DSE-specific configuration helper and dse:// master URL are replaced with a standard SparkConf pointing at the Spark master and the Cassandra contact points:

   // Open-source Spark + Spark-Cassandra Connector
   import com.datastax.spark.connector._
   
   val conf = new SparkConf()
       .setAppName("MyApp")
       .setMaster("spark://spark-master:7077")
       .set("spark.cassandra.connection.host", "cass-node1,cass-node2,cass-node3")
       .set("spark.cassandra.auth.username", "user")
       .set("spark.cassandra.auth.password", "pass")

4. Add the connector dependency to the build, or pass it to spark-submit:

   spark-submit \
       --packages com.datastax.spark:spark-cassandra-connector_2.12:3.5.1 \
       --conf spark.cassandra.connection.host=cass-node1,cass-node2,cass-node3 \
       application.jar

5. Plan resources using dedicated Spark workers (for example, 2 to 4 nodes with 32 to 64 GB RAM and fast local SSD/NVMe for shuffle data) on a low-latency network to the Cassandra nodes.
6. Test each migrated job against the same data and verify output consistency before decommissioning DSE Analytics.

For high-throughput bulk reads, writes, or ETL, Apache Cassandra Spark Bulk Analytics (CEP-28, CASSANDRA-16222) is worth evaluating as an alternative. It operates at the SSTable storage layer rather than through the CQL path: the Bulk Reader reads point-in-time snapshots directly, and the Bulk Writer generates SSTables in Spark executors and imports them via the Cassandra Sidecar, avoiding competition with production traffic for coordinator resources. It supports Cassandra 4.0 and 5.0 on Spark 3.x and is actively developed but still pre-1.0.

---

Replacing DSE Graph

Before planning a graph migration, confirm graph is actually in use:

cqlsh -e "DESCRIBE KEYSPACES" | grep -i graph
grep -r "Gremlin\|TinkerPop\|graph" /var/log/cassandra/

If graph is not in use, skip this section entirely.

Option A: Denormalise into Cassandra tables

For simple traversals (1 to 2 hops, known query patterns), model the relationships as denormalised Cassandra tables and eliminate the graph database entirely. A “user follows user” relationship, for example, becomes a forward-lookup table and a reverse-lookup table:

-- Forward lookup: who a user follows
CREATE TABLE user_follows (
    follower_id UUID,
    followed_id UUID,
    followed_at TIMESTAMP,
    PRIMARY KEY (follower_id, followed_id)
);

-- Reverse lookup: a user's followers
CREATE TABLE user_followers (
    followed_id UUID,
    follower_id UUID,
    followed_at TIMESTAMP,
    PRIMARY KEY (followed_id, follower_id)
);

This works well when query patterns are well-defined, traversal depth is shallow, and the model is relatively simple.

Option B: JanusGraph with a Cassandra backend

For complex workloads with deep traversals, variable query patterns, or heavy Gremlin use, deploy JanusGraph (Apache-2.0) with Cassandra as the storage backend. JanusGraph uses standard Apache TinkerPop Gremlin and stores graph data in Cassandra tables, so it scales independently of the database tier.

Watch for these differences during migration:

• DSE Graph runs in-process on each DSE node; JanusGraph is a separate process that connects to Cassandra over CQL. This adds a network hop, negligible for most workloads, but latency-sensitive traversals should be benchmarked during validation.
• DSE Graph and JanusGraph use different schema APIs. Standard TinkerPop steps (g.V(), g.E(), addV(), addE(), path steps) work unchanged; DSE-specific extensions (search predicates, geospatial queries, DseGraph.traversal(), DseCluster/DseSession) require replacement.
• JanusGraph officially supports Elasticsearch, Solr, or Lucene as index backends, not OpenSearch. If the deployment standardises on OpenSearch, deploy a separate Elasticsearch instance for JanusGraph indexing.

---

Is Apache Cassandra as secure as DSE Advanced Security?

A common reason teams hesitate to leave DSE is the belief that its Advanced Security module makes it “more enterprise” than open-source Cassandra. That comparison has not held since Apache Cassandra 4.0 (2021). DSE 6.x is built on a fork of Apache Cassandra 3.11, which reached end-of-life in 2024 and no longer receives upstream security patches; security fixes depend on DataStax backporting them to the 3.11 fork. Open-source Cassandra 4.x and 5.0, by contrast, have had several years of active security development. Every DSE Advanced Security capability has an open-source equivalent.

DSE security features and their open-source equivalents

DSE security feature	Open-source equivalent	Notes
Internal authentication	PasswordAuthenticator	Built in
LDAP authentication	LDAP via a production authenticator plugin	Maintained plugins are in production use; corporate LDAP integration is a solved problem
Kerberos authentication	Kerberos via an authenticator plugin	Available through community and vendor plugins
Role-based access control	CassandraAuthorizer	Built-in roles and permissions, with datacenter-level restrictions added in 4.0
Row-level access control	Dynamic data masking (5.0) + application-level controls	Native masking covers most cases that previously required row-level ACLs
Encryption at rest	Filesystem-level encryption (LUKS / dm-crypt), with an optional KMS, plus native commitlog and hints encryption	Standard, compliance-grade approach (see below)
Encryption in transit	Native TLS	client_encryption_options / server_encryption_options in cassandra.yaml, including mutual TLS

Encryption at rest warrants clarification. DSE’s Transparent Data Encryption integrates key management into the database, whereas the open-source approach encrypts the underlying storage with LUKS or dm-crypt, optionally backed by a KMS, and encrypts commitlog and hints natively. Filesystem-level encryption at rest is the standard pattern for self-managed datastores and is accepted under PCI-DSS, HIPAA, and SOC 2; it is a configuration choice, not a missing capability.

Compliance certifications attach to deployments and their controls, not to the database engine. An open-source Cassandra cluster, whether self-managed or operated by a third party, can be run to meet PCI-DSS, HIPAA, and SOC 2 using the encryption, authentication, authorization, and audit-logging capabilities listed above. Leaving DSE does not forfeit the ability to be compliant.

Security capabilities modern Cassandra has and DSE does not

Because DSE is frozen on the 3.11 lineage, it never received the security work that landed in open-source Cassandra 4.x and 5.0 (and continues in 6.0):

• Full database audit logging (Cassandra 4.0, CASSANDRA-12151): audit_logging_options, enabled at runtime with nodetool enableauditlog, including obfuscation of passwords in DCL events and redaction of keystore, truststore, and encryption secrets from the system_views.settings virtual table.
• Dynamic data masking (Cassandra 5.0): native CQL masking functions (mask_inner, mask_hash, and others) with UNMASK and SELECT_MASKED permissions, so sensitive columns are masked without application changes.
• Native CIDR / IP allowlist authorizer (Cassandra 5.0, CEP-33) and datacenter-level role restrictions (ACCESS TO DATACENTERS), enforced at the database, not just the firewall.
• Pre-hashed password support (Cassandra 4.1), so credentials can be supplied already hashed rather than in plaintext. Password-validation guardrails follow in Cassandra 6.0 (CEP-24, CASSANDRA-17457).
• PEM-format key and certificate support (Cassandra 4.1, CEP-9) and certificate-based mutual-TLS internode authentication (Cassandra 5.0, CEP-34), including mixed-mode rollout without downtime.

Export the DSE security configuration (the dse.yaml security section, roles, and permissions) and recreate roles and grants on the target cluster with CQL CREATE ROLE and GRANT statements. Test authentication and authorization thoroughly before any production traffic moves. AxonOps supports LDAP and SAML for operator access and centralises log and audit-event management across the cluster, assisting with access-control and audit requirements during and after migration.

---

Migrating drivers

The DSE-specific drivers (dse-java-driver, dse-python-driver, and so on) were unified into the standard open-source DataStax drivers in 2020, and the DSE drivers are no longer maintained. All DSE-specific functionality (graph traversal APIs, geospatial type bindings, DSE authentication, continuous paging) was merged into the open-source drivers under the Apache License 2.0.

Applications still on the DSE drivers should migrate to the maintained open-source drivers regardless of the cluster migration, because running on unmaintained drivers is an accumulating security and technical risk.

The Cassandra drivers are in the process of being donated to the Apache Software Foundation. The exact artifact coordinates depend on how far along that move is for each language at migration time; the maintained driver may still publish under its previous open-source coordinates, or it may already have moved to the apache/cassandra-*-driver project. Verify the relevant Apache repository for the current release and coordinates before pinning a version. The Java driver was donated first and now ships as org.apache.cassandra:java-driver-core.

Language	DSE driver	Maintained open-source driver	Apache project
Java	com.datastax.dse:dse-java-driver-core	com.datastax.oss:java-driver-core → org.apache.cassandra:java-driver-core	apache/cassandra-java-driver
Python	dse-driver	cassandra-driver	apache/cassandra-python-driver
Node.js	dse-driver	cassandra-driver	apache/cassandra-nodejs-driver
Go	None	gocql	apache/cassandra-gocql-driver
C++	dse-cpp-driver	cassandra-cpp-driver	apache/cassandra-cpp-driver
C#	Dse	CassandraCSharpDriver	(donation in progress; check upstream)

For Java, the common class replacements are:

• DseSession → CqlSession
• DseSession.builder() → CqlSession.builder()
• DseDriverConfigLoader → DriverConfigLoader
• DseProgrammaticPlainTextAuthProvider → ProgrammaticPlainTextAuthProvider
• DseLoadBalancingPolicy → DefaultLoadBalancingPolicy

For driver setup, connection management, prepared statements, load-balancing policies, and best practices, see Application Development: Drivers.

Migration steps

1. Inventory driver usage by searching for DSE artifacts and imports (com.datastax.dse, dse-driver, etc.).
2. Update dependencies to the unified driver in Maven, pip, npm, or NuGet.
3. Update imports to the unified equivalents. The unified driver is API-compatible; deprecation warnings appear but existing code continues to work.
4. Test thoroughly against a staging cluster, paying particular attention to DSE-specific features (graph queries, geospatial types, custom authentication).

The PHP and Ruby DSE drivers were not merged into a unified driver and remain in maintenance mode. Applications using these languages require a move to a community-maintained driver or a supported language driver.

---

Replacing NodeSync and OpsCenter

NodeSync is DSE’s proprietary continuous-repair mechanism, with no open-source equivalent shipped in Cassandra. Open-source Cassandra still needs regular repair to stay consistent, so this capability must be replaced before the new cluster serves production traffic. The standard nodetool repair works, but scheduling and tracking it across a cluster requires additional tooling.

AxonOps Adaptive Repair is the direct replacement for NodeSync. It runs repair continuously as a managed service and adjusts repair intensity to real-time cluster load (throttling during peak traffic and increasing throughput during quiet periods), tracks repair coverage per table, and alerts on failures, without the manual scheduling that raw nodetool repair requires. See Post-Migration Operations for where repair fits in the day-2 operational setup.

OpsCenter supports DSE only and stops working as soon as DSE nodes are replaced. It must be replaced with a Cassandra operations platform. The OpsCenter-to-AxonOps capability mapping and the architectural comparison are covered in DSE proprietary features.

Go / No-Go

Go: every DSE-specific component has a tested open-source replacement running in staging.

Rollback: shut down the replacement components. The DSE cluster remains unchanged; nothing in this phase modifies it.

---

Next: ZDM Proxy and CDM setup.