# Keep your tools. Change what is underneath them.

Replacing a security or observability platform is a year of migration nobody asked for. CtrlB is designed to slot underneath what you already run, taking the volume and the retention while your team keeps the workflows they know.

## Metadata

- **Canonical HTML**: https://ctrlb.ai/solutions/extend-your-stack
- **Section**: Solutions — Extend your existing stack

## At a glance

| Figure | What it refers to |
|--------|-------------------|
| No rip-out | Existing workflows stay |
| Your bucket | Data never leaves it |
| 10 min → 500 ms | Typical query change |
| Open Parquet | Nothing to migrate later |

## Why teams do not migrate

- The detections, dashboards, and runbooks in the incumbent tool represent years of institutional knowledge.
- A full migration means rewriting all of it at once, with no way to verify parity until the end.
- Meanwhile the actual pain is narrow: the volume is too expensive to keep, and the archive is too slow to search.

## The narrower change

- Move the high-volume sources and the long-tail retention to your own bucket, and leave everything else where it is.
- The incumbent tool keeps doing what it is good at, on the subset that justifies its price.
- Because storage is open Parquet in your account, a deeper migration later is a query-layer change rather than a data export.

## How it works

1. **Tee the firehose** — Route the high-volume sources into your own object storage alongside whatever you send the incumbent today. Nothing is cut over on day one.
2. **Verify in parallel** — Run the same investigations against both for as long as you want the comparison. The data is identical because it is the same events.
3. **Shift the expensive parts** — Once parity is boring, trim the incumbent to the workloads that actually need it and let the lake carry the volume and the history.

## Capabilities

- **No agent rewrite**: OpenTelemetry collectors and existing shippers can fan out to both destinations during the overlap.
- **Parallel running**: There is no cutover date. The two systems coexist for as long as the comparison is useful.
- **Query from outside**: SQL and MCP interfaces mean external tools and agents can read the lake without importing it first.
- **Your account, your keys**: The lake and its indexes live in your bucket. Turning CtrlB off does not strand the data.
- **Volume-first economics**: The sources that dominate the incumbent's bill are usually the ones with the least per-GB value — those move first.
- **Optional deeper migration**: If the incumbent eventually has nothing left to do, removing it is a licensing decision rather than a data project.

## Tool by tool

### Athena on S3

_Same bucket. Same Parquet. A query layer that answers in seconds._

Athena already reads the data where it lies, which is the right architecture — the problem is that a needle query means a full scan, and a five-to-ten minute wait per question ends an investigation early. CtrlB keeps the S3-native model and adds compact inverted indexes so a point search reads an index instead of the lake.

- No data movement: CtrlB indexes the Parquet already in your bucket.
- Point searches drop from minutes to sub-second, so investigations branch instead of batching.
- Per-query scan cost falls with the scan volume it no longer has to do.
- SQL stays SQL — the interface your analysts already write.

### Splunk

_Keep the detections. Move the volume off ingest pricing._

Splunk's cost model makes the highest-volume sources the least affordable to keep, which is why WAF, flow logs, and CloudTrail data events are usually the first to be trimmed. Those sources move to your bucket, where retention is a storage line item, while the searches and detections your team relies on stay where they are.

- High-volume, low-density sources land in your own object storage instead of a licensed index.
- Long-tail retention becomes years rather than the window the licence allows.
- Analysts keep their existing Splunk workflows for the data that still lives there.
- Frozen and archived buckets become searchable again rather than restorable.

### Datadog

_Keep the dashboards. Drop the retention and cardinality cliffs._

Datadog is excellent at the last fifteen days and at the metrics you were willing to pay cardinality prices for. CtrlB takes the two places that gets expensive: the log volume you are indexing selectively, and the metric dimensions you had to drop to keep the bill sane.

- Logs land complete in your bucket, so rehydration and index tiers stop being a planning exercise.
- Metrics keep every dimension — no allowlists and no per-series pricing.
- Retention extends to years at object storage cost, past the standard windows.
- Existing Datadog dashboards and monitors keep running on the data that stays there.

### Microsoft Sentinel

_Keep the analytics rules. Take the archive off the slow path._

Sentinel's analytics tier is priced for the data you actively detect on, which pushes everything else into basic or archive tiers where investigation means restoring first. CtrlB holds the full history in your own storage and keeps all of it directly searchable.

- Archive-tier data becomes queryable in place instead of restore-then-query.
- High-volume connectors route to your bucket rather than the analytics tier.
- Sentinel keeps the analytics rules and incident workflow your SOC already runs.
- One copy serves both compliance retention and live investigation.


## FAQ

**Does this mean running two systems forever?**

Only for as long as it is useful. Most teams start with a parallel period to build confidence, then let the incumbent shrink to whatever workloads genuinely justify its cost.

**Do we have to change our agents or collectors?**

No. OpenTelemetry collectors and most existing shippers can fan out to two destinations, so the overlap period does not require re-instrumenting anything.

**What happens to data already in the incumbent?**

It can stay there until its retention expires. Going forward, new data lands in your bucket, and historical exports can be backfilled into the lake if you want a single searchable history.

**Who owns the storage?**

You do. The Parquet files and the indexes live in your S3 or GCS bucket, in your account, in the region you choose.

Markdown mirror: fetch `/solutions/extend-your-stack.md` for this page as plain Markdown.