Splunk to Elastic SIEM Migration Checklist: A Step-by-Step Practitioner Guide

Before touching any infrastructure, you need a complete inventory of what you are migrating. Skipping this phase is the single most common reason migrations run over timeline and budget. The inventory has five components.

Splunk app and add-on inventory. Run | rest /servicesNS/-/-/apps/local to list all installed apps. For each app, document whether it provides: data inputs (TA for a specific log source), field extractions (CIM-mapped fields), knowledge objects (saved searches, alerts, macros), or dashboards. Every Splunk Technology Add-on (TA) that provides CIM field mapping needs an Elastic equivalent integration or custom ingest pipeline.

Data source inventory. Document every data source feeding Splunk: Windows Event Logs, Syslog, endpoint agents, cloud provider logs, network appliances, identity platforms. For each source record the current Splunk input method (Universal Forwarder, Heavy Forwarder, HEC, scripted input), approximate daily GB volume, and the Splunk index it lands in. This map becomes your Elastic Agent or Logstash migration target list.

Detection rule inventory. Pull all correlation searches from Splunk ES: | rest /servicesNS/-/-/saved/searches | search alert.track=1. Document each rule by: SPL query complexity (simple stats vs. subsearches vs. lookup-dependent), alert action (notable event, risk score, external webhook), MITRE ATT&CK mapping if present, and firing frequency in the last 90 days. Rules that fire zero times in 90 days should be evaluated for deprecation rather than ported.

Dashboard inventory. Export the list of dashboards and document which are used by which teams. Kibana can recreate most Splunk dashboard visualizations but the panel-by-panel rebuild is manual work. Prioritize dashboards that SOC analysts touch daily and defer low-usage operational dashboards.

Splunk license tier and data retention. Document your current ingest volume by index and your Splunk license tier (Enterprise, Cloud, Infrastructure Monitoring). This is the baseline for the cost comparison model you will build in Phase 7.

SPL (Search Processing Language) and EQL (Event Query Language) are fundamentally different in architecture. SPL is a pipeline language where each step transforms results from the previous step. EQL is a sequence-and-pattern language optimized for detecting ordered events across time. The mental model shift matters for detection engineers.

Key syntax differences. SPL pipes filter and transform: index=windows EventCode=4624 | stats count by user | where count > 10. EQL sequences describe event chains: sequence by user [authentication where event.outcome == "success"] with maxspan=5m [process where process.name == "cmd.exe"]. Simple SPL searches with stats and where translate relatively cleanly. Subsearches ([search ...]) and lookup joins (| lookup threat_intel.csv ip AS src_ip) require architectural rethinking in EQL.

The Sigma conversion approach. For organizations with MITRE ATT&CK-aligned detection rules, Sigma is the most practical migration path. Sigma is a vendor-neutral detection rule format with converters (sigmac or the newer pySigma) that output both SPL and EQL. The SigmaHQ repository contains thousands of community rules already in Sigma format, many of which correspond directly to Splunk ES content library rules. The migration workflow: export Splunk ES correlation search SPL, find the equivalent Sigma rule in the SigmaHQ repo, convert to EQL with pySigma, and validate. For rules with no Sigma equivalent, manual EQL authoring is required.

Common pitfalls in SPL-to-EQL conversion. First: Splunk macro expansion. SPL macros (defined with backticks) expand at search time. EQL has no macro system. Every macro reference in a Splunk rule must be manually expanded before conversion. Second: subsearch as filter. SPL subsearches like [search index=threat_intel | fields ip | rename ip as src_ip] perform in-line lookups. EQL handles this with enrich policies loaded from Elasticsearch indices, which require separate configuration. Third: time-based stats across long windows. SPL stats over rolling 24-hour windows are straightforward. EQL sequence matching has configurable maxspan but long-window aggregations use ES aggregations in Kibana rules, not pure EQL.

For SIEM alert tuning after migration, expect a retuning cycle of 4-6 weeks as EQL thresholds are calibrated to your environment's baseline. Rules translated from SPL will almost always fire differently in EQL because field values and event structure differ between Splunk CIM-normalized data and ECS-normalized data.

The log ingestion layer is where migration complexity lives. Splunk's Universal Forwarder and Heavy Forwarder ecosystem has been deployed in most organizations over years, with custom inputs, field extractions, and routing rules embedded in configuration files across hundreds of endpoints.

Universal Forwarder to Elastic Agent. For Windows Event Log, Syslog, and simple file-based log collection, Elastic Agent with Fleet management is a direct replacement for the Universal Forwarder. Fleet provides centralized policy management that mirrors Splunk's deployment server for forwarder configuration. The migration path: deploy Elastic Agent to a pilot group of endpoints, configure the equivalent integration (Windows, System, or custom log collection), validate that events appear in Elasticsearch with correct ECS field mapping, then roll out to production via Fleet policies.

Heavy Forwarder to Logstash or Elastic Agent Fleet. Splunk Heavy Forwarders performing parsing, routing, and transformation need more careful replacement. For parsing-heavy workflows, Logstash with the appropriate input and filter plugins is the most direct architectural equivalent. For routing-heavy workflows (sending different log types to different indexes), Elastic Agent's output routing and Fleet policy structure handles this natively. Organizations with complex Heavy Forwarder configurations often run a transitional Logstash layer that handles parsing while Elastic Agents handle collection, then consolidate once ECS field mappings are validated.

Index mapping strategy. Splunk indexes map roughly to Elasticsearch data streams. The critical difference is field schema enforcement: Elasticsearch data streams enforce field type mappings, which means a field that arrives as a string in one event but an integer in another will cause mapping conflicts and indexing failures. Establish ECS mappings for every data source before ingestion begins. The Elastic integration packages handle ECS mapping automatically for supported log sources. Custom log sources require manual ECS field mapping work.

Timestamp normalization. ECS uses @timestamp in UTC with millisecond precision. Splunk normalizes timestamps during indexing and handles timezone conversion automatically. For data sources with inconsistent timestamp formats or local timezone values, Elastic ingest pipelines need explicit date processor configurations. Timestamp normalization failures are one of the most common causes of broken sequence-based detections in EQL, because events that appear to arrive out of order break sequence matching.

Elastic Security ships with a prebuilt detection rule library of 900+ rules aligned to MITRE ATT&CK. Before porting Splunk ES correlation searches manually, audit which prebuilt Elastic rules cover the same techniques. For many organizations, the Elastic prebuilt rules cover 60-70% of their active Splunk ES correlation searches with no migration work required beyond enabling the rule and configuring thresholds.

Comparing Splunk ES content to Elastic prebuilt rules. Map each active Splunk ES correlation search to its MITRE ATT&CK technique. Then check whether Elastic's prebuilt rule library covers that technique. The Elastic detection-rules GitHub repository documents each rule's MITRE ATT&CK coverage. For covered techniques, validate that the Elastic prebuilt rule fires correctly against your log sources before deprecating the Splunk rule.

Porting custom SPL correlation searches. For organization-specific detections with no Splunk ES content library equivalent and no matching Elastic prebuilt rule, the porting process is: translate the SPL logic to EQL, validate against historical event data using Timeline in Kibana, set threshold and suppression parameters, and enable in detection engine. The Kibana detection rule editor provides real-time EQL syntax validation that catches common errors before a rule goes live.

Risk scoring migration. Splunk ES risk-based alerting (RBA) assigns risk scores to entities over time rather than generating individual alerts for each event. Elastic Security's risk scoring feature provides equivalent functionality via asset criticality scoring and risk engine configuration. The risk score logic does not translate directly between platforms. RBA rules need to be rebuilt using Elastic's risk engine framework rather than converted from SPL.

Maintaining alert parity during migration. Run Splunk and Elastic detections in parallel for at least 30 days and compare alert outputs daily. Alerts that fire in Splunk but not Elastic indicate a porting gap. Alerts that fire in Elastic but not Splunk may indicate either a detection improvement or a false positive introduced by ECS field normalization differences. Document every divergence and resolve before cutover.

Kibana vs Splunk Dashboard comparison. Splunk dashboards use Simple XML or Dashboard Studio. Kibana provides Lens, Canvas, and Dashboard panels backed by ES|QL or KQL queries. The visualization types are largely equivalent but the query language and data model are different. A Splunk table panel driven by stats count by src_ip, dest_ip becomes a Kibana Lens table with a terms aggregation on source.ip and destination.ip (ECS field names). Every panel requires manual recreation; there is no automated dashboard conversion tool that produces usable results.

Prioritize dashboard migration by usage. SOC analyst operational dashboards that are opened daily come first. Executive and management dashboards come second. Historical reporting dashboards that are run monthly can be migrated last or rebuilt on demand.

Parallel run period. The parallel run is the most important operational safety net in the migration. During the parallel run: Splunk continues as the primary SIEM driving SOC alerts and investigations. Elastic ingests the same log sources and runs detections, but alerts are reviewed for accuracy rather than acted on as primary. The parallel run continues until Elastic alert parity reaches 95%+ of Splunk alert volume for the same events, dashboard coverage matches operational needs, and analyst workflows are validated in Kibana.

A 30-60 day parallel run is the minimum for a responsible cutover. Organizations with complex detection environments or compliance requirements for audit continuity should plan for 90 days.

Rollback plan. Maintain Splunk in a suspended state for 30 days post-cutover. Do not decommission Splunk infrastructure until the first full month of Elastic-only operations is validated. Keep Splunk indexes accessible for historical data queries during the transition period. The rollback trigger should be defined in advance: if Elastic alert volume drops below 80% of expected baseline for more than 48 consecutive hours, the rollback plan activates.

Splunk vs Elastic cost modeling. Splunk Enterprise licensing is typically calculated on GB per day of indexed data. A 100 GB/day deployment at standard Enterprise pricing runs roughly $150,000-200,000 per year in licensing before infrastructure costs. Elastic Cloud pricing on the same ingest volume depends on deployment configuration: hot tier data for active querying, warm tier for recent historical data, and cold/frozen tier for long-term retention. A typical Elastic Cloud configuration for 100 GB/day with 90-day hot retention and 365-day warm retention runs significantly less than Splunk's equivalent tier, though exact pricing varies by cloud provider, region, and committed spend.

On-premises Elastic (self-managed) eliminates licensing cost but adds operational burden. Factor in infrastructure costs (compute and storage), engineering time for cluster management, and upgrade cycles. Many organizations find that Elastic Cloud's managed offering at 40-60% of Splunk's licensing cost is the right balance between savings and operational overhead.

Common failure modes to plan around. First: EQL any where performance. EQL's any where clause queries across all event types and can be extremely resource-intensive on large indices. Splunk SPL searches that use index=* broadly have analogous performance issues but Splunk's search optimization is more mature. Constrain EQL rules to specific data streams using where clauses on data_stream.dataset rather than querying all indices.

Second: field name mapping failures. Splunk CIM uses src_ip for source IP addresses. ECS uses source.ip. Detection rules that reference CIM field names will not fire against ECS-normalized data. This is the single most common cause of silent detection failures post-migration. Audit every ported rule for CIM-to-ECS field name substitutions.

Third: Sigma rule conversion edge cases. pySigma is the best available tool for Sigma-to-EQL conversion, but it does not handle all Splunk-specific Sigma backend features. Rules that use condition: 1 of them across multiple detection sets require manual EQL rewriting using any of syntax. Rules that reference Sigma field mappings specific to the Splunk backend may generate incorrect EQL field references when converted to the Elastic backend.

For a deeper look at how Splunk and Elastic compare on capabilities beyond migration mechanics, see Splunk vs Elastic for a side-by-side feature comparison.