Is Cribl's 'no vendor lock-in' claim real? Anyone actually switched data out?

Having extensively evaluated Cribl Stream's architecture for a recent multi-cloud log routing project, I find their 'no vendor lock-in' claim to be one of its most compelling and technically sound features. The premise is that your data remains in your control, in your chosen format, and can be egressed to any destination at any time. But theoretical architecture and production reality often differ. I'm interested in concrete, operational experiences.

From an implementation standpoint, the claim holds water because Cribl operates as a processing layer, not a storage sink. Your data pipeline (e.g., Splunk Heavy Forwarders, Fluentd, OpenTelemetry Collector) is redirected to Cribl, which then fans out to your final destinations. The critical elements enabling vendor agnosticism are:

* **Native Outputs:** The vast library of pre-built destinations (S3, HTTP/S, Kafka, Elastic, Datadog, etc.) means you're not forced into a proprietary format.
* **Code-Based Processing:** Your routing, filtering, enrichment, and reduction logic lives in Cribl's Pipelines as reusable JavaScript/RE2 expressions. This logic is conceptually portable.
* **Schema Preservation/Flexibility:** You can maintain original payloads or reshape them to match a new destination's schema before sending, avoiding lock-in at the data model level.

My primary question for the community is not about capability, but about **actual execution under pressure**. Has anyone performed a significant *cut-out* or *egress* operation? For instance:

* Migrating a primary log stream from Splunk to, say, Azure Monitor or Google Chronicle, where Cribl was the routing hub. Did you simply reconfigure the Pipeline's output and adjust the schema, and was it as straightforward as changing a destination IP?
* In a scenario where you needed to decommission Cribl itself, is the configuration truly exportable in a usable form? The Pipeline logic can be version-controlled via Git, but how would you translate that into another processor like Apache NiFi or a custom script?
* Were there hidden dependencies? For instance, did you rely on Cribl's built-in functions for PII detection or custom JavaScript libraries that would need re-implementation elsewhere?

A snippet of a simple pipeline route demonstrates the decoupling:

```javascript
// In a Cribl Pipeline - a simple filter and route
// This logic is self-contained and destination-agnostic.
if (__inputId === 'prod_web_logs') {
// Drop verbose health checks
if (event.url === '/health') {
return null;
}
// Enrich event with lookup
event.env = 'production';
// Route to one or multiple outputs
__outputQueue = ['aws_s3_bucket', 'http_syslog_endpoint', 'splunk_hec_dest'];
}
```

The above could be adapted to any system. But the proof is in the operational switchover. Were you able to redirect terabytes per day with minimal loss and no reprocessing? Did the promise of 'no lock-in' reduce contractual friction with your incumbent SIEM or observability vendor?

I'm looking for war stories and technical specifics on the egress process, not sales brochures. The architecture suggests it's real, but I value hands-on validation.

API first.