Transition to Caver. Same dashboards, same queries, same alerts. Day one.
There are exactly two ways to adopt Caver: migrate fully with caver-migrate, or run it in parallel beside the SIEM you have today and cut over when the numbers convince you. Both start from the same fact: Caver ships its own enterprise lake on install, provisioned, retained, and compacted by Caver itself, so there is nothing to build before you begin and no data-lake team to hire.
Same dashboards
Ported panel-for-panel into Dashboard Studio, or served unchanged to the search head you already run. The views your analysts open Monday morning are the views they opened Friday.
Same queries
One engine speaks the five languages your team already knows, SPL, SQL, KQL, ES|QL, and LSQL, plus Sigma content. Nothing to re-learn, nobody to re-train.
Same alerts
Scheduled alerts and correlation rules keep firing through the move. Detection coverage never goes dark because a migration is in flight.
Two ways to adopt. Exactly two.
Migrate fully, or run in parallel. There is no half-install to get lost in: Caver ships whole, lake included, under one license, and either path leaves your SOC running the workflows it already knows.
Full migration
Point caver-migrate at the legacy deployment and it ports the lot: dashboards, saved searches, scheduled alerts, correlation and risk rules, service trees and KPIs, behavior models, and SOAR playbooks, each mapped onto the matching Caver layer.
- ✓ Audit first: --dry-run prints a full coverage report before --apply touches anything.
- ✓ Every migrator is tested end-to-end before it ever sees your data.
- ✓ Day one your SOC opens the same dashboards and runs the same queries, on Caver, on the enterprise lake it ships.
$ caver-migrate --dry-run dashboards → Dashboard Studio saved searches → Caver scheduler scheduled alerts → Caver scheduler correlation + risk rules → CAVERN service trees + KPIs → ECHO behavior models → UBA SOAR playbooks → SLAM coverage report written · nothing applied $ caver-migrate --apply-all
Run in parallel
Stand Caver up beside the SIEM you run today. It registers as a search peer of the search head you already have, so existing dashboards, saved searches, and correlation rules keep running unchanged, and it federates with Elastic, Sentinel, and others. Because the enterprise lake ships with the install, the parallel path requires building nothing.
- ✓ No forwarder changes: sources keep flowing exactly as they do today, tee to Caver, or speak their native protocol directly.
- ✓ Search head unchanged: the peer app drops in via the standard install flow (caver-peer.spl).
- ✓ Cut over when the numbers convince you. Until then, nothing about your daily workflow moves.
search head · settings · distributed search + add search peer → caver-lake:8089 peer registered · status Up dashboards + saved searches now read the OCSF lake federate → Elastic · Sentinel · Sumo Logic · Datadog
What moves, and where it lands.
Each migrator takes one surface of the legacy deployment and maps it onto the matching Caver layer. Together they cover the work a SOC actually accumulates over years, not just the raw data.
Dashboards
Ported panel-for-panel. Every panel arrives cloneable and editable in Studio.
Saved searches
Runnable searches auto-port into the Caver scheduler with their cadence intact.
Scheduled alerts
Alerting moves with the searches that drive it, so coverage never goes dark mid-transition.
Correlation + risk rules
Correlation searches and risk rules land as CAVERN detections with their risk contributions mapped.
Service trees + KPIs
Service topology, KPIs, and thresholds rebuild as ECHO service trees with propagated health.
Behavior models
Behavior models map onto per-entity baselines and risk-based alerting in UBA.
SOAR playbooks
Playbooks port into SLAM and run approval-gated against real incident cases.
Tested end-to-end
Every migrator is exercised end-to-end before release, and --dry-run prints the full coverage report first, so the port is auditable before a single object is applied.
Phased, not big-bang. You set the pace.
The two paths compose into one calm sequence. Most teams start in parallel and let the side-by-side numbers make the cutover decision for them.
Assess
Run caver-migrate --dry-run against the legacy deployment. Read the coverage report: every surface it will port and the Caver layer each one lands on. Nothing is written, nothing is touched.
Run in parallel
Install Caver beside what you have. The enterprise lake comes with it, so there is nothing to build first. Register it as a search peer, federate what you keep, and let both stacks answer the same questions side by side.
Cut over
When the numbers convince you, apply the migration and make Caver primary. Same dashboards, same queries, same alerts, now on the lake. Keep the legacy stack in a read-only overlap window as the safety net.
Retire
Wind down the indexer tier and let the per-GB renewal lapse on your schedule. Your history lives in open Parquet on storage you own, so retiring the old stack never strands a byte.
What "the numbers" usually look like in phase 03: object storage runs roughly 10x cheaper than indexer storage at the same retention, and compression lands around 48:1, measured against raw ingest volume in the same window; legacy tsidx-style SIEMs land near 2:1.
Your Splunk contract stays between you and Splunk.
Any change to a Splunk license, downsizing, lapsing, or renegotiating, happens through Splunk, per your existing agreement and on your timeline. Caver never modifies, works around, or bypasses another vendor's licensing. The search-peer registration uses the standard, documented install flow, and federation with Elastic, Sentinel, and others rides their public interfaces the same way. The transition is additive until the day you decide it is not.
Start with the coverage report.
Tell us what you run today, current SIEM, storage tier, on-prem or cloud, and we will scope the transition with you: a dry-run coverage read-out, a parallel plan, and cutover criteria that make sense for your SOC.