Splunk → Microsoft Sentinel

The business case for leaving Splunk for Microsoft Sentinel usually writes itself: the Splunk licence is a large, visible, annual number, Sentinel is already inside an E5 agreement someone else negotiated, and the security team would rather have one Microsoft console than two vendors. The plan that follows is almost always the same — point the forwarders somewhere new, translate the searches, decommission the indexers.

That plan moves complexity. It does not reduce it, and it frequently does not reduce cost either, because both products bill on the volume you send them. A lift-and-shift of 900 GB/day into Sentinel is 900 GB/day of Sentinel ingest. The vendor changed; the economics did not.

This post covers what actually differs between the two platforms, what a forwarder lift-and-shift really costs, and where a telemetry pipeline changes the answer.

The three things that are genuinely different

Beyond the console, three differences drive the real work:

• The query language. SPL and KQL are not dialects of each other. Every saved search, every correlation rule, every dashboard panel is a rewrite — assisted by translation tooling, but reviewed by a human who understands what the detection was supposed to catch. Budget this as the largest line item; it is engineering time, not infrastructure.
• The ingestion model. Splunk takes almost anything and figures out the schema at search time. Sentinel sits on Log Analytics, which wants tables, a declared schema and a Data Collection Rule describing the transform. Schema-on-read becomes schema-on-write, which is more up-front work and less tolerance for messy sources.
• The tiering. Sentinel separates ingestion into analytics-grade tables and cheaper tiers with reduced query capability and different retention behaviour. That tiering is the main cost lever the platform gives you — and it only works if something decides, per record, which tier a given log belongs in.

That last point is where most migrations quietly fail. The tiering is real and it does save money, but nothing in Splunk’s forwarder topology knows how to make that decision, so everything lands in the expensive tier by default.

What a forwarder lift-and-shift actually costs

Splunk’s collection layer is universal and heavy forwarders shipping to indexers. The naive Sentinel equivalent is Azure Monitor Agent on every host with Data Collection Rules, or a syslog/CEF forwarder for network gear. It works. It also inherits every property of the old setup that you were presumably trying to escape:

• Volume is unchanged, so the per-GB bill simply moves to a new vendor. If Splunk was expensive because of what you sent it, Sentinel will be expensive for the same reason.
• The agent is vendor-specific again. You have swapped a Splunk forwarder for a Microsoft agent. The next migration — and there will be one — is the same project over again, because the collection layer is still owned by whoever owns the backend.
• The messy sources stay messy. Multiline stack traces, inconsistent timestamps and free-text logs that Splunk tolerated at search time now have to be parsed on the way in, or they become unqueryable columns of text.
• Nothing gets cheaper per record. Debug logs, health-check chatter and verbose access logs are still shipped in full, still indexed, still billed.

Where the pipeline layer changes the answer

The alternative is to put a collection layer you own between the sources and Sentinel. Concretely, an OpenTelemetry Collector on each host (or a gateway tier for network sources), and a pipeline that does four things before anything is billed:

• Filter. Drop what nobody will ever query. Health checks, successful liveness probes, debug-level chatter from a service in steady state. This is the single largest lever and it is not subtle — see reducing observability costs.
• Parse. Fold multiline events into single records and extract the handful of fields that make a log queryable, so Sentinel receives structure rather than a text blob — onboarding messy logs.
• Route by value. Security-relevant records to the analytics tier; high-volume operational logs to a cheap archive or a different backend entirely. This is the decision the tiering model needs and cannot make for you — routing by attribute.
• Redact. Strip credentials, tokens and personal data before the record leaves your network, rather than trusting a downstream masking rule — masking PII in logs.

The result is that the migration becomes an actual reduction rather than a change of address, and the collection layer stops being tied to the backend — which is what makes the next backend decision cheap.

Be honest about the connector gap

One thing to plan around: OpenTelemetry does not have a first-class, officially supported Sentinel exporter the way it has one for OTLP backends. Getting records into a Log Analytics table generally means the Logs Ingestion API against a Data Collection Rule, or keeping the Microsoft agent as the final hop with the collector doing the reduction upstream of it.

That is a real integration cost and it belongs in the plan. It does not change the argument — the reduction happens before that hop either way, which is where the money is — but a design that assumes a clean OTLP path into Sentinel will hit a wall in week three. Check the current exporter and API situation against Microsoft’s documentation when you scope the work, not from a blog post.

A migration order that works

1. Measure first. Volume per source, per day. Almost every estate finds that a handful of sources produce most of the bytes, and that some of them are queried approximately never — see real throughput.
2. Put collectors in the path while Splunk is still live. Collect once, export to both — dual-ship without duplicates. Do not run two collection agents on the same host for the same file; that is how you get double-counted hosts and duplicated log lines.
3. Cut volume before you cut over. Filter, sample and route with the old backend still running, so you can compare the two and prove nothing you rely on disappeared.
4. Translate detections against the reduced stream, not against the old one. Rewriting an SPL rule that depends on a field you are about to drop is wasted work.
5. Then decommission, one source at a time, keeping the collection layer in place.

The order matters: reduce while you can still see both sides. A cutover followed by a reduction is two risky projects; a reduction followed by a cutover is one.

The honest trade-off

You are adding a component. The collector fleet is infrastructure to run, configure and keep current, and if it is misconfigured it can drop data you needed — which is why the filter rules want previewing against real captured records before they go fleet-wide, not after.

What you get for that is the thing a backend migration alone never gives you: the volume decision, the redaction decision and the routing decision all move to a layer you own, and stay there when the backend changes again.