The storage is moving, the engine isn't (yet).

There is a version of the off-Splunk story that gets told at vendor keynotes, and a quieter version that shows up in pricing books, earnings transcripts, and the architecture diagrams of teams I have actually sat with. The two versions disagree about what is happening and how fast. The loud version says the open lakehouse is replacing the legacy SIEM analytics engine, that the next Splunk is a security data lake on open table formats, and that the migration is underway at enterprise scale right now. The quiet version says something narrower and, I think, truer: the storage layer and the pipeline layer are moving, fast and measurably, while the analytics engine that legacy SIEM customers actually run their detections on is mostly staying put.

I want to make the case for the quiet version, because the evidence supports it and the loud version does not, and because the gap between them is exactly where a buyer gets oversold. My confidence here is moderate, not high. The interesting tension is that the best-sourced evidence points away from the most exciting claim. The structural shifts that are real are also kind of boring. Tiered storage, pipeline-layer cost control, OCSF-normalized lakes feeding analytics you bring yourself. The shift that would be exciting, a regulated enterprise retiring Splunk's analytics engine for an open, engine-agnostic lakehouse with the TCO math published, is the one nobody has publicly attested.

Start with the most important instance, because it is the dominant SIEM vendor building the lake pattern into its own product rather than ceding it. Microsoft shipped a Sentinel data lake tier (GA September 30, 2025) that stores security telemetry in open-format Parquet with storage and compute separated, then in April 2026 added read-only federation to query Azure Databricks Unity Catalog, ADLS Gen2, and Microsoft Fabric tables in place. The economics are what make it the cleanest case. Using Microsoft's own analytics-versus-lake meters, the per-GB gap on ingest alone is roughly 80×: analytics-tier pay-as-you-go runs $4.30/GB ingested in East US, against a lake-tier ingest rate near $0.05/GB. That 80× is the headline number, and it is also the misleading one if you stop there. Add the lake's data-processing meter (~$0.10/GB) and the gap narrows to roughly 28× on ingest-plus-processing. Add storage at ~$0.026/GB-month and per-GB query charges and the realized arbitrage depends entirely on how often you scan the data. (Microsoft pricing pages, 2026, Tier C-vendor for the $4.30 anchor; Realm.Security's "Microsoft Sentinel Pricing Explained" breakdown of the lake meters, May 2026, Tier C-independent with pipeline-vendor framing bias.) I would drop the 6:1 stored-byte compression figure that floats around the same writeups; I have not been able to corroborate it, and a bare compression ratio is the kind of number that should be measured, not repeated.

The reason this is a storage signal and not an engine signal is in Microsoft's own design. Federation is one-directional, read-only, and requires the federated source to be delta-parquet. The hot detection path stays in the proprietary KQL analytics tier; the lake is the cold, compliance, and hunting tier. Microsoft built the lake to defend Sentinel's seat, not to vacate it. That is precisely why it is strong evidence that the substrate is moving (open Parquet, decoupled storage and compute, query-in-place across engines) and weak evidence that the engine is being replaced. The control plane stays closed. And the format-war detail my own work tracks gets decided inside the Microsoft estate in Delta's favor, not Iceberg's: Microsoft says Parquet and Delta, never Iceberg, and names no OCSF class or version for the lake schema. If you believe open Iceberg V3 is the inevitable security-lake foundation, the largest incumbent's productized lake is a data point against you, not for you.

One media-cost detail sits a level below this, and it matters when you size the warm tier the lake feeds rather than the cold object floor. The instinct is to spec high-endurance NVMe for the hot path, but for sequential security telemetry that tier is usually over-specified, because the way the drives are rated and the way append-only ingest writes diverge. The JESD219 endurance standard the DWPD ratings come from assumes a random worst-case write pattern, while append-mostly ingest writes with a measured write amplification factor near 1 (Min et al., FAST '12; Cai et al., Proceedings of the IEEE 2018, both Tier A), so the rated endurance and the realized endurance are not the same number for this workload. The field bears that out: roughly 80% of enterprise SSDs run under 1 DWPD (ServeTheHome's 1,347-drive survey and Forward Insights, Tier B/C), and at-scale fleet studies find drives rarely fail by wear-out at all (Google, FAST '16; NetApp, FAST '20, Tier A). The cost-correct default for this profile is read-intensive NVMe over a cold object tier, and the high-endurance premium is hard to justify for append-only ingest. I would still hold reliability-equivalence-at-matched-load as Tier D until I have run it on my own bench; the rating-versus-workload gap is well sourced, but "the cheaper tier is as reliable under your actual load" is the claim I have not yet measured myself.

Now the central negative, stated plainly because it is the spine of the honest read. No named Tier-1 bank or systemically-important entity has publicly attested retiring Splunk's analytics engine for an open, engine-agnostic lakehouse, with quantified TCO, in a venue that is not a vendor stage. The single Tier-1-bank "replacement" claim in the entire corpus is Standard Chartered's "self-managed SIEM" talk (35% cost reduction, 92% faster investigation, 80% faster time-to-detect), and that is a Databricks Data + AI Summit 2025 session, GTM-motivated and vendor-staged. Standard Chartered is also UK-headquartered, so it is not even a US SCI entity for the regulatory argument people try to hang on it. Three of the four named Tier-1 FSI references in Databricks' own roster (HSBC, State Street, Capital One) are augmentation or modernization stories, security-data-lake-alongside-Splunk, not Splunk-out. State Street running 50 PB of security data on a lakehouse is a real and large fact. It is not the same fact as State Street turning off its SIEM engine, and the gap between those two facts is where the loud and quiet versions part ways.

Databricks' Lakewatch, announced March 24, 2026, sharpens this rather than resolving it. It is a first-party "open, agentic SIEM," and it is in private preview with no published GA date. The headline is "up to 80% lower TCO," and the most useful thing about that number is what independent analysts did to it. InfoWorld (March 2026) assembled named skepticism that I think is exactly right. Robert Kramer of Moor Insights & Strategy: "Costs don't disappear; they shift. If usage isn't controlled, compute can add up quickly," and Lakewatch is "more likely to complement existing SIEMs than replace them." Akshat Tyagi of HFS Research framed the savings as concentrated where enterprises "want to retain large amounts of data," which is to say conditional, not universal. Stephanie Walter of HyperFRAME Research pointed out that buyers value domain depth, not just infrastructure scale. (All Tier B, named analysts, named firms.) The pattern worth seeing: the cost claim is a vendor "up to" figure, and the only independent layer touching it is cautionary. That is the inverse of how a well-evidenced trend reads, where the independent sources corroborate and the vendor merely amplifies.

This squares with my own benchmark experience, which I will get to, and which says lakehouse TCO wins are real but concentrated at high-retention cold-tier workloads and conditional on disciplined compute governance. "Up to 80%" is directionally defensible at the workload where retention scale dominates and overstated as a blanket claim. SACR's September 2025 framing puts the structural point cleanly: most security data lakes in 2025 remain coupled to a single analytics engine, not running open Iceberg-on-S3 with the engine swappable underneath. The open, engine-agnostic part, the part that would actually validate the loud narrative, is the part that is least built.

Cisco's disclosed numbers are the highest-tier evidence in the whole pile, and they are genuinely ambiguous. The Splunk security segment was flat-to-slightly-negative across the first three quarters of FY2026 (down roughly 2% YoY in Q1, around flat near $2.0B in Q3), while Splunk ARR and product RPO grew double digits and the unit added about 500 new logos in H1 FY2026, on pace for 1,000. Those are SEC-filing and earnings-transcript numbers, Tier A, and they do not show an exodus. Double-digit ARR and RPO growth alongside a thousand-logo new-customer pace is not the profile of a platform customers are fleeing.

The reading you will hear from Cisco, and the one repeated everywhere, is that the flat segment line is a deliberate on-prem-to-cloud revenue-recognition transition under ASC 606, not customer flight. CFO Mark Patterson called it a near-term drag from the cloud shift; CEO Chuck Robbins called the mix shift "purely a timing issue." I find that explanation plausible and partially corroborated by the RPO growth, which is what deferred-but-contracted revenue looks like. But it is management self-attribution, and I will flag it as such rather than launder it into settled fact. From public data I cannot cleanly separate "Splunk revenue deferred into later periods" from "Splunk losing some accounts at the margin," because both produce a flat reported line in the near term. The honest statement is that the primary numbers do not show flight, and the most-repeated explanation for the flat line is the seller's own. Watch whether the segment inflects positive once the rev-rec transition laps; if it does not, the timing story weakens.

What the Cisco disclosure does show cleanly is a deployment-model move: Cisco is actively winding down the on-prem perpetual indexer footprint and pushing customers into cloud subscription. That validates the broader claim that the legacy on-prem schema-on-read deployment model is in managed decline. It also shows Cisco intends to capture that transition itself, to Splunk Cloud, not to cede it to a third-party lakehouse.

The destination is validated and, more tellingly, incumbent-endorsed. When the two dominant SIEM vendors both ship the lake pattern in-product (Microsoft's Sentinel data lake, Cisco's Splunk-side machine-data-lake-and-federation roadmap), the open-architecture argument has stopped being a challenger's pitch. The storage and pipeline layers are moving, measurably, with hard per-GB numbers and a $300M-ARR pipeline business to price the pain. That much I hold with reasonable confidence.

The speed, at the engine-replacement layer, is slow, selective, and skills-gated, and the evidence for a stampede is the weakest evidence in the file. The best-sourced material in this entire scan is the counter-evidence, and that asymmetry, more than any single number in the file, is what I would take away. A buyer being told the open lakehouse will replace the Splunk engine this fiscal year is being sold the layer with the thinnest proof.

Two things would move my read upward, and I will name them so the claim is falsifiable. A named SCI entity or Tier-1 US bank publicly attesting a Splunk-engine retirement, not augmentation, onto an open catalog with TCO it is willing to print outside a vendor stage. Or Cisco's FY2026 numbers failing to inflect once the rev-rec transition laps, which would weaken the timing story and suggest the flat line was partly flight after all. One thing would move it downward: a documented migration-reversal, a named enterprise that moved off Splunk to a lake and came back. I went looking for that case and did not find it in citable form. Its absence is not evidence the move is permanent; it is a gap, and I would rather name the gap than fill it with a number I cannot source.