Phase 0: Assess an Astra DB Database Before Migration

Assessment is analytical and read-only: no changes are made to Astra during this phase. The goal is to know exactly what is being migrated before provisioning, so that the plan is based on facts.

Bring in an AxonOps expert

AxonOps has assessed and migrated many Astra workloads, and the assessment is where the awkward cases surface: heavy use of the Data API or Collections, vector data, Astra-specific guardrails, or uncertain target sizing for a managed service whose capacity is opaque. 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.

Because Astra is a managed service, there is no access to nodetool, JMX, or configuration files for inspection. The database is inventoried through the Astra console, through CQL DESCRIBE, and by examining how the application connects.

Step 1: Confirm the workload is CQL

This migration covers CQL tables and rows, which are ordinary Apache Cassandra data. First, confirm whether the application uses Astra's proprietary document and AI layer, because that part does not move to open-source Cassandra.

• Check whether the application uses the Data API or Collections (the JSON/document interface) rather than, or in addition to, CQL.
• Check whether it uses Vectorize (server-side embedding generation).

Data API, Collections, and Vectorize are out of scope

These are Astra-specific and have no open-source Apache Cassandra equivalent. If the application relies on them, this guide does not cover that part of the migration. Talk to AxonOps so the right approach can be designed before proceeding. CQL tables, SAI, and vector search through CQL are unaffected and continue below.

Step 2: Export and review the schema

Connecting cqlsh to Astra requires a Secure Connect Bundle and a valid application token, both obtained from the Astra console. Export the full schema:

cqlsh -e "DESCRIBE FULL SCHEMA" > astra_schema.cql

Confirm that astra_schema.cql is non-empty and contains the expected keyspaces and tables. An empty or truncated file indicates a connection or permission issue that must be resolved before the migration can continue.

Review the export and record:

• All keyspaces and tables to recreate on the target.
• All roles and permissions, so they can be recreated on the target. The data migration does not copy credentials; roles and permissions are created manually on the target.
• Any SAI indexes (CREATE CUSTOM INDEX ... USING 'StorageAttachedIndex'). SAI is native to Apache Cassandra 5.0, so these carry over.
• Any vector columns or vector indexes. Vector search is native to Apache Cassandra 5.0, so if vector search is in use, the target must be Cassandra 5.0 or later.

Step 3: Record a performance baseline

Confirm after the migration that the new cluster performs at least as well as Astra. Capture a baseline from the Astra console metrics, covering a representative period (ideally including both busy and quiet traffic):

• read and write latency (including tail latencies such as p99);
• request throughput (operations per second);
• data size per keyspace or table (from Astra console metrics, or estimated via system.size_estimates, which returns partition-level estimates and should be treated as approximate).

Retain these figures for comparison against the target cluster during validation.

Step 4: Note Astra's guardrails and limits

Astra enforces guardrails and service limits (for example, on page sizes, collection and field sizes, and certain statement types). A self-operated cluster does not impose the same limits by default, and in a few cases its default behaviour differs. Record any application behaviour that depends on Astra guardrails so it can be checked during validation.

Step 5: Inventory drivers and the connection method

This is where Astra differs most from a self-managed source, so capture it carefully.

• Driver and version for each application. Each service moves to a maintained open-source Cassandra driver on the target. The Cassandra drivers are in the process of moving to the Apache Software Foundation; check the relevant Apache driver project for the current release for the relevant language, and see the Cassandra drivers documentation for setup once migrated.
• How the application connects to Astra today: the Secure Connect Bundle path and the application token (or client ID and secret). Note every service and config location that references the SCB, because all of them change at cutover.
• TLS expectations on the target. Astra connections are always encrypted via the SCB. To encrypt connections to the new cluster, plan a TLS configuration; the SCB does not carry over.

The cutover details, including exactly what replaces the SCB, are in Cutover and Drivers.

Assessment checklist

• Application confirmed CQL-only, or Data API/Collections/Vectorize usage flagged
• Full schema exported and reviewed
• Roles and permissions recorded for manual recreation on the target
• SAI indexes recorded
• Vector columns/indexes recorded (target must be Cassandra 5.0+ if present)
• Performance baseline captured from the Astra console
• Astra guardrail dependencies noted
• Driver artifacts and versions recorded per application
• Secure Connect Bundle path and application token locations inventoried
• Target TLS approach decided
• Data volume estimated (it drives the migration duration)

Go / No-Go

Go: the workload is confirmed as CQL, the schema, roles, and indexes are inventoried, the connection method and drivers are recorded, a baseline is captured, and any Data API usage has been raised and handled separately.

Rollback: none required. No changes have been made.

---

Next: Set up the ZDM Proxy and Cassandra Data Migrator