SIEM migration from Splunk to Microsoft Sentinel
Cohash migrates SIEM operations from Splunk to Microsoft Sentinel. We inventory log sources and searches, model ingest cost across the analytics and data lake tiers, rebuild connectors, translate SPL detections to KQL with tests, move SOAR playbooks to automation rules and Logic Apps, and run both SIEMs in parallel until alert coverage matches. Historical data and retention needs are settled before Splunk is switched off.
- 01Inventory and cost model
- 02Connectors and parsing
- 03Detection translation
- 04Automation and workflows
- 05Parallel run and cut-over
The story
Told without the client's name or anything that could identify them.
A manufacturer's security operations team received a Splunk renewal quote while its Microsoft E5 security licenses were already paid for, and most alerts came from Defender and Entra ID anyway. Nobody could say which of the saved searches still fired. We inventoried sources, searches and SOAR playbooks and modeled ingest cost across the analytics and data lake tiers before any connector went live. Detections were drafted from SPL with Microsoft's migration tool, reviewed by hand and tested with sample events, and both SIEMs ran on the same sources until alerts matched rule by rule. Analysts then moved to Sentinel in the Defender portal and the Splunk history went to its agreed archive.
why it was urgentCisco closed its Splunk acquisition on 18 March 2024. For a migration, though, two later dates matter more. Microsoft's AI-powered SIEM migration tool for Splunk and QRadar went generally available in April 2026. And Sentinel leaves the Azure portal after 31 March 2027, so we take new migrations straight to the Defender portal.
- openSplunk's renewal quote just came in. The Microsoft E5 security licenses are already paid for.
- recurringMost of your alerts come from Microsoft Defender and Entra ID. Splunk mostly just forwards them.
- blockedSaved searches number in the hundreds and nobody knows which ones still fire.
- openRetention rules force you to keep years of logs in an expensive hot tier.
The estate, before and after
Before: Splunk ingesting everything into a hot tier
Forwarders sent Defender alerts, Entra ID sign-ins and server logs into Splunk, and the saved searches and SOAR playbooks ran there. Most alerts were coming from Microsoft tools anyway. Retention rules kept years of logs on expensive hot storage.
Read the diagram as text
- Microsoft Defender XDR → Splunk forwarders: alerts forwarded
- Entra ID → Splunk forwarders: sign-in logs
- Firewalls and servers → Splunk forwarders: raw events
- Splunk forwarders → Splunk: all data, hot tier
- Splunk → Splunk SOAR playbooks: notable events
- Splunk SOAR playbooks → Ticketing: ticket
After: Microsoft Sentinel in the Defender portal
We had native connectors and Azure Monitor Agent filter logs before they reach Sentinel, and placed each table in the analytics or data lake tier. KQL rules deploy from a repository. Automation rules and Logic Apps open the tickets.
Read the diagram as text
- Microsoft Defender XDR → Native connectors: incidents
- Entra ID → Native connectors: sign-in logs
- Firewalls and servers → Azure Monitor Agent: filtered events
- Native connectors → Sentinel analytics tier: analytics tables
- Azure Monitor Agent → Sentinel analytics tier: analytics tables
- Azure Monitor Agent → Sentinel data lake tier: retention tables
- Detection repository → Sentinel analytics tier: deploy rules
- Sentinel analytics tier → Automation rules: incident
- Automation rules → Ticketing: ticket
How we run it, phase by phase.
5 phases take you from Splunk Enterprise or Splunk Cloud to Microsoft Sentinel in the Defender portal. Each one ends with something you can check before the next starts. As you scroll, the blocks show the estate moving across.
- phase 01
Inventory and cost model
List indexes, sources, sourcetypes, daily volume, saved searches, correlation searches, dashboards and SOAR playbooks. Model which tables go to the analytics tier and which to the data lake tier for retention.
- phase 02
Connectors and parsing
Replace forwarders with Azure Monitor Agent, syslog and CEF collectors and native connectors. Check that parsed fields match what the old detections relied on, and filter noise before ingestion.
- phase 03
Detection translation
Run the SIEM migration experience to draft KQL from SPL, then review each rule by hand, map it to ATT&CK and test it with sample events. Macros and lookups that have no direct equivalent are rebuilt as functions or watchlists.
- phase 04
Automation and workflows
Turn Splunk SOAR playbooks into automation rules and Logic Apps playbooks, then connect incidents to the ticketing system you use. Put detections and playbooks in a repository on day one.
- phase 05
Parallel run and cut-over
Run both SIEMs on the same sources, compare alerts per rule and explain every gap. Move analysts once coverage matches, then stop forwarding to Splunk and archive or export the history you must keep.
What the client got
What changed for the client once the work was done. Described, not scored: we don't publish client figures.
- result 01
Every detection lives in a repository with test events
We mapped every KQL rule to ATT&CK, gave it sample events that ought to trigger it and versioned it with the playbooks, so any change can be reviewed and rolled back.
- result 02
Log tiering was decided table by table
Tables analysts query sit in the analytics tier and retention-only data sits in the data lake tier. That decision was made before each connector went live.
- result 03
Built in the Defender portal from the start
Everything was built in the Defender portal, the workspace, the rules and the playbooks, and tested there. Sentinel leaving the Azure portal after 31 March 2027 doesn't mean a second migration.
- result 04
Response automation runs inside Sentinel
The SOAR playbooks didn't survive the move as-is. Each was rebuilt as an automation rule or a Logic Apps playbook, and when an incident opens now, the ticket opens with it.
- result 05
Splunk history has a known home
We didn't switch off forwarding to Splunk until the logs auditors and investigators might need had been archived or exported under the agreed retention plan.
Risks we plan for
-
Ingest cost surprise
Send everything to the analytics tier and you rebuild the cost problem you left. Decide tiering table by table before any connector goes live.
-
Translated rules that never fire
Machine-translated KQL can be perfectly valid and still wrong. So every rule gets tested against events that should make it fire.
-
Field and parsing differences
Splunk add-ons and Sentinel connectors don't parse fields the same way. A detection keyed on a field name can fail quietly, so parsing gets checked first.
-
Lost history
Someone will eventually ask for logs from years ago, an auditor or an investigator. Settle where the Splunk history lives before the licenses run out.
Where AI helps, and where it needs guardrails
Sentinel adds AI-generated playbooks, GA in May 2026, and an MCP server whose entity analyzer became GA in April 2026 and is billed in Security Compute Units. We test generated playbooks like any code before they run. Agents that query security data through the MCP server get read-only scopes and their own identity, because a security data lake holds the most sensitive logs you own.
forward deployed engineers →What you're left with
We write these for your setup, and they're working documents. Your team should be able to keep things running from them long after we've gone.
- runbook01
Source, search and playbook inventory with a decision per item
yours to keep - design02
Ingest and retention cost model across analytics and data lake tiers
yours to keep - tests03
KQL detection library in a repository, each rule with test events
yours to keep - runbook04
Playbooks and automation rules with ticketing integration
yours to keep - runbook05
Parallel-run comparison report and cut-over plan
yours to keep - plan06
Historical data retention and export plan
yours to keep
Platforms and services on this move
Services involved
Certified engineers, wherever you need them.
Some clients want a project team, some want a couple of engineers on theirs. Either works. Onsite, nearshore or offshore, with handovers across time zones that keep things moving.
Onsite
Engineers at your sites in the US
Nearshore
Overlapping hours with US teams
Offshore
Overnight progress on your backlog
All time zones
Coverage handed over across time zones
01Will Sentinel be cheaper than Splunk?
It depends on volume, which tables need analytics-tier queries, retention, and which Microsoft licenses you already hold. We model it from your actual ingest before anyone commits.
02Can the migration tool translate all our searches?
It drafts translations. Complex SPL, macros, lookups and custom commands still need an engineer, and every rule needs a test before it's trusted.
03What happens to our Splunk history?
You have a few options. Keep a small Splunk instance for search until retention runs out, export to cheaper storage, or load what you need into the data lake tier. Which one makes sense depends on how often anyone actually searches the old data.
04Should we start in the Azure portal?
No. After 31 March 2027 Sentinel is only supported in the Defender portal. Build and test new workspaces and migrated rules there, or you'll be doing the move twice.
Often on the same roadmap
On-premises Active Directory to cloud-first Microsoft Entra ID
We shrink on-premises Active Directory one application at a time, moving groups, users and app authentication to Microsoft Entra ID as each app is ready.
read the case studyAD FS federation to Entra ID authentication
Converting federated domains from AD FS to Entra ID cloud authentication, moving relying parties app by app and retiring the AD FS farm.
read the case studyNasdaq Calypso upgrade to V19
Upgrading Nasdaq Calypso to V19, with server consolidation, properties moved to the database, the WebUI and deployment changes tested on your own trades.
read the case study562b5768 - 01Cisco newsroom: Cisco completes acquisition of Splunk (18 Mar 2024)newsroom.cisco.com ↗
- 02Microsoft Learn: What's new in Microsoft Sentinel (SIEM migration tool GA Apr 2026, Azure portal retirement 31 Mar 2027)learn.microsoft.com ↗
- 03MITRE ATT&CKattack.mitre.org ↗
Planning this move?
A 30-minute working session with a senior engineer. No slides.
- The platform and the version you're on
- Where you need to get to, and by when
- What's custom: rules, plugins, integrations
- Any audit finding or deadline driving it