What moving from Splunk to Elastic Security involves
A renewal, a licensing change or a data residency requirement is forcing a SIEM decision, and the migration to Elastic Security is a staged project of agents, detection rules, historical data and parallel running. Effort depends mainly on the number of correlation searches you must rebuild and the number of log sources you must re-point, so count both before anyone estimates a timeline. The work is usually carried out by your security engineering team together with an implementation partner, since the people who understand your correlation searches are rarely the same people who run Elasticsearch clusters. Elastic Security runs on Elasticsearch and Kibana and can be self-managed in your own infrastructure or hosted on Elastic Cloud, and that hosting choice determines who operates the cluster, applies upgrades and holds the data.
The short answer on risk is that detection logic is the hardest part, not data movement. Moving events into Elasticsearch is a well-understood ingest task, but each SPL correlation search encodes assumptions about field names, time windows, lookups and thresholds that must be re-expressed as detection rules and then proven against real alerts. Start by inventorying every saved search and alert, marking which ones are actual detections and which are dashboards, and mapping each detection to a prebuilt rule where one exists. Confirm with Elastic which detection engine features your target subscription includes, because the detection engine is a paid capability on self-managed deployments and the tier decision affects your budget before any rule is written.
Plan historical data as a separate decision from live detections. Decide which indices must be searchable in Elastic Security for investigations and which can be exported and archived, and check how Splunk's export methods, covered in the sibling page on exporting Splunk data, fit your volumes. Run both platforms in parallel until each migrated detection fires on the same test events as its Splunk original, and record every gap as an accepted risk or a rule still to build.
Which Splunk capabilities map to Elastic Security
This table compares the main Splunk Enterprise Security capabilities with their Elastic Security counterparts and marks each row as clean, needs rework or gap. Read the migration note before planning, because tier requirements and rule parity depend on your own content and license choice. Most detection logic moves across, but SPL-based content and Splunk app content need manual work.
| Splunk capability | Elastic Security equivalent | Migration note (clean, needs rework or gap) |
|---|---|---|
| Universal Forwarder to managed agents | Elastic Agent enrolled and managed centrally through Fleet | Needs rework: agent policies, outputs and enrollment must be rebuilt, then forwarders retired in stages |
| Correlation searches to detection engine rules | Detection engine correlation, indicator match and threshold rule types | Needs rework: each SPL search must be translated and tested against the same events to confirm rule parity |
| Prebuilt detection content and customization | Prebuilt detection rules from the elastic/detection-rules repository, delivered to the Kibana detection engine and customizable | Clean for common use cases, but confirm which prebuilt rules match your existing content and review their tuning |
| Alert suppression and notable event handling | Alert suppression in the detection engine on the subscription tier listed for it | Needs rework: confirm the suppression behavior matches your current event grouping before cutover |
| Investigations and case management | Timeline for investigations and Cases for tracking work | Needs rework: analyst runbooks and case workflows must be rebuilt, and Cases features depend on the tier you buy |
| Entity analytics and ML anomaly detection | Entity analytics and machine learning anomaly detection, with anomaly-based alerting limited to paid tiers | Gap to confirm: Elastic lists anomaly alerting only on Platinum and Enterprise, and Platinum is no longer sold to new customers |
| Endpoint protection | Elastic Defend running through Elastic Agent | Needs rework: policy design and exception handling must be rebuilt for each endpoint group |
| Host isolation and response actions | Host isolation and the interactive response console, listed under the Enterprise tier | Gap to confirm: verify that response actions on your endpoints meet your procedures before relying on them |
| Single sign-on for analysts | SAML and OpenID Connect single sign-on, listed under the Enterprise tier | Needs rework: confirm the tier and identity provider setup before access reviews |
| SPL searches to Elasticsearch query languages | Discover, Timeline queries and Elasticsearch query languages | Gap for direct reuse: SPL cannot run unchanged, so each search must be rewritten and its results compared |
| Splunk app ecosystem content | No direct equivalent in Elastic Security; some integrations exist as Elastic packages | Gap: confirm each app's function with its vendor or with Elastic before planning replacements |
What data, content and integrations need to move
A Splunk to Elastic Security move touches four things: historical events, identity and roles, detection content and the integrations around them. Each has a different export path and a different owner, so the inventory should be done before any ingest work starts. The cards below cover what to pull out of Splunk and what to rebuild on the Elastic side.
Retrieving search results from Splunk
Splunk offers several retrieval paths for search results: Splunk Web, the CLI, the REST API, SDKs, the dump search command and data forwarding. Splunk's documentation calls the CLI the most stable retrieval method, so it is the usual choice for scripted bulk pulls. Test each path against your largest index before you commit to a method, and confirm which of them your Splunk version and deployment type support. Watch for search limits and time-range chunking on large exports.
Saved search output formats
Splunk exports search results as raw events, CSV, JSON, XML or PDF. Raw events and JSON preserve the most field detail for re-ingestion into Elasticsearch, while CSV flattens nested fields and PDF is only useful for reporting. Decide per dataset which format you need, and check how timestamps, time zones and multivalue fields come through. Keep a sample export from each source so you can compare field names after the first Elastic ingest.
Identity, roles and SSO mapping
Splunk roles and capabilities must be mapped to Elastic native users, realms and roles, which is a design task, not a copy job. Elastic's Basic tier includes TLS, the file and native user realms and role-based access control, while SAML, OpenID Connect, Active Directory and LDAP single sign-on and field- or document-level security sit in paid tiers. Confirm the subscription level before you commit to a directory integration, and list every Splunk role that needs document-level restrictions.
Detection content and saved searches
Correlation searches, alerts and saved searches become Elastic detection rules, and each one needs a rebuilt query, a severity, a schedule and a field mapping. The elastic/detection-rules repository provides prebuilt rules that are delivered to the Kibana detection engine, so start by checking which of your Splunk detections already have an equivalent. Record the Splunk search, its owner and its alert destination for each item, then review the Elastic rule against the same test events.
Dashboards and third-party integrations
Dashboards, ticketing hooks, SOAR connectors and custom apps usually depend on Splunk's REST endpoints or add-ons, and none of them move automatically. Each one must be rebuilt against Elastic's APIs, Kibana objects or connectors, and every alert destination needs its own test. Inventory the integrations before cutover, and confirm the Elastic-side ingest paths for historical data against the Elastic documentation for the version you choose.
How correlation searches become Elastic detection rules
Start with an inventory of every Splunk correlation search, not just the ones people remember. For each search, record its schedule, its search window, its throttling or suppression settings, the fields it reads, and what it writes to the notable event index. Those last two items matter most for the migration, because the analysts' queues, case routing and dashboards depend on them. Then classify each search into one of three groups. The first is a match to a prebuilt Elastic rule, which is the cheapest path if the logic and data sources line up. The second is a custom rule built on the detection engine's correlation, indicator match or threshold types, which covers most searches that compare events across sources or count occurrences over time. The third is a search that needs redesign because its logic depends on Splunk-specific lookups, macros or enrichment that Elastic does not reproduce one for one. Confirm the exact rule types and their options against the Elastic Security documentation for your version before you write the mapping.
Prebuilt rules are developed in the elastic/detection-rules repository, where the rules and code are licensed under the Elastic License v2, and the latest prebuilt rules are delivered to the Kibana detection engine automatically. That automatic delivery is useful, but it also means a rule that behaves differently after an update can look like a new alert spike. Keep a register that lists which prebuilt rules you enable, the version of each rule you tested, every local change such as an added exception, altered query or changed threshold, and the owner who approved it. Local changes can be lost or overwritten when rules update, so review them at each upgrade. Confirm with Elastic how your deployment handles rule updates and whether customized rules are preserved before you rely on the register alone.
Test every rule against historical or replayed events before cutover, and compare alert volume with Splunk for the same period. Replay a representative window that includes known incidents and normal peaks, then check whether each Elastic rule fires for the events that caused the Splunk notable, and whether it fires for events that did not. Track alert counts per rule per day, not only totals, because a rule that produces ten times the Splunk volume will overwhelm an analyst queue even if it catches the same incidents. Where the numbers diverge, find out whether the cause is field normalization, a missing data source, a different time window, or suppression that Splunk applied and Elastic does not. Run both platforms in parallel until each rule's alert behavior is explained and approved. Ask your Elastic partner or internal team to document the acceptance criteria for each rule in writing before the parallel run starts.
The migration sequence from inventory to decommission
This sequence moves Splunk security monitoring to self-managed Elastic Security in controlled stages, so each detection is proven against live data before anyone relies on it. Each step ends with a written output that the next step depends on, and the Splunk environment stays available as the reference until cutover is signed off.
Inventory sources, searches and retention needs
The security engineering lead and the Splunk administrator list every data source feeding Splunk Enterprise Security, every correlation search, saved alert, dashboard, lookup and integration, and the retention each compliance obligation requires. Each correlation search is mapped to an Elastic detection rule type (query, threshold, indicator match or correlation) or flagged as a gap that needs a custom rule, an alternative tool or a documented risk acceptance. The output is a rule mapping register with an owner and a status for every item, plus a retention record that states which indexes and time ranges must remain searchable. The step is done when the register has no unassigned rows and the compliance lead has reviewed the retention record.
Pilot with a small host set
The engineering team selects a limited set of hosts and a handful of high-value rules, then enrolls Elastic Agent through Fleet on those hosts in place of the Splunk forwarders that currently send the same logs. Detection rules are loaded from the prebuilt library where they match and customized where they do not, and the team confirms that events arrive with the expected fields and that rules fire on controlled test activity. Endpoint features that depend on Elastic Defend and on a paid subscription are tested separately. The output is a signed-off pilot report that lists the hosts, rules, field gaps and subscription features in use, and the security owner approves it before the parallel run starts.
Run Splunk and Elastic in parallel
Both platforms receive the same sources for a defined observation window agreed in advance, and the team compares what each produces. Analysts review alerts from both sides each day, record matches, misses and false positives, and tune rules in Elastic until the differences are explained. Any detection that Splunk raised and Elastic did not is treated as a blocking finding until it is resolved or formally accepted. The output is an alert parity log with one line per detection, showing the Splunk result, the Elastic result, the disposition and the approver. Cutover does not begin until every open parity item has a recorded decision.
Cut over alert routing and playbooks
The team moves alert routing, on-call rotations, ticket integrations and response playbooks from Splunk to Elastic Security, including Cases and Timeline workflows that analysts will use during incidents. Routing changes are made in a planned change window with the on-call lead present, and each change is documented with the exact configuration it replaced. A rollback procedure is written before the change, naming the steps to restore Splunk alert routing and to re-enable the forwarders if Elastic cannot process events. The output is a cutover record covering the change log, the rollback steps tested in a non-production setting, and the sign-off from the incident response owner.
Decommission Splunk and retain exported data
After a stable period that the security owner sets in advance, the team exports the Splunk data that the retention record requires, using the search export methods that Splunk supports, and stores it in the agreed archive location with access controls matching its classification. Universal forwarders are removed from hosts, Splunk alerts and apps are disabled, and license and infrastructure contracts are closed or scaled down according to the contract terms. The output is a decommission record that lists the archived datasets, their checksums or retrieval tests, the removed forwarders and the closed Splunk components. The step is complete when the compliance lead confirms that the archive can be retrieved for the retention period.
Which Elastic subscription the detection engine needs
The detection engine itself sits in a paid tier, and the tier that once bundled it is closed to new buyers. Elastic's subscriptions page places the detection engine, machine learning anomaly detection and case management under Platinum, which Elastic no longer sells to new customers. Endpoint malware and ransomware prevention, host isolation and SAML or OpenID Connect single sign-on sit under Enterprise. For a new self-managed deployment, that leaves two routes: Basic, which is free, or Enterprise, or moving the workload to Elastic Cloud. Read the detection engine as a paid requirement before you commit the design, because a rule set built on the free tier will not have the same operational features as the one Splunk Enterprise Security provides today.
Elasticsearch and Kibana are not open source under the default license. Elastic distributes both under the Elastic License 2.0 by default, and also offers the source code under SSPL 1.0 and AGPLv3. Elastic says it added AGPLv3 to provide an OSI-approved option. ELv2 and SSPL are not OSI-approved open source licenses, so if your procurement or legal policy requires OSI-approved licensing, record which license you rely on for each component and confirm with counsel which option satisfies that policy. Elastic Security's rules repository is licensed under the Elastic License v2 as well, which matters if you plan to modify or redistribute prebuilt rules.
Confirm the current tier for every feature you need before the design is final. Tier placement changes, and the Platinum withdrawal is recent enough that partner quotes and older blog posts may still describe the previous arrangement. Build a feature list from your current Splunk Enterprise Security use cases, such as correlation searches, alert suppression, anomaly detection, case management, endpoint response and single sign-on, and check each item against the subscriptions page. Ask the Elastic sales team to confirm the tier in writing, and ask what changes at renewal or on a version upgrade, so the licensing risk is documented alongside the technical plan.
What drives the cost and duration of the move
This table lists the factors that change the effort and cost of moving from Splunk Enterprise Security to self-managed Elastic Security, with how each one can be kept down. Read it as a checklist to scope with a quote, since most drivers multiply each other, especially rule count and historical volume.
| Driver | Why it matters | How to keep it down |
|---|---|---|
| Number of correlation searches | Each Splunk correlation search must be rebuilt as an Elastic detection rule (correlation, indicate match or threshold type), and searches that depend on SPL-specific logic need the most rework. | Inventory searches first, retire unused or duplicate ones, and start with prebuilt Elastic rules where they match the existing use case. |
| Endpoints and sources to re-enroll | Each universal forwarder must be replaced by Elastic Agent managed through Fleet, and sources that send syslog or HTTP data need separate input design. | Group hosts by policy in Fleet, migrate in waves, and confirm which sources can keep their existing feed during the transition. |
| Historical data volume and retention | Moving old events is often the largest storage task, and export methods differ in practical limits, so the volume you keep shapes compute and disk needs. | Decide which history must move versus which can stay archived in its original form, and set data tiers before importing. |
| Cluster design for high availability | A highly available Elasticsearch cluster needs at least three master-eligible nodes, and separating data tiers (hot, warm, cold, frozen) changes the number of nodes you pay to run. | Confirm node roles and tier sizing with your own retention targets, and ask the partner to size the cluster in the written scope. |
| Kubernetes deployment through ECK | If your platform team already runs Kubernetes, ECK manages Elasticsearch, Kibana and Elastic Agent as operators, which adds upfront design work and ongoing cluster skills. | Use ECK only where Kubernetes operations already exist, otherwise plan a VM-based deployment and document the choice. |
| Subscription tier and SSO requirements | Detection engine and machine learning anomaly detection need a paid self-managed tier, and SAML or OpenID Connect single sign-on sits in Enterprise. Platinum is no longer sold to new customers. | Map every required feature to the tier list before design, and confirm current pricing and terms directly with Elastic. |
| Integrations with ticketing and SOAR | Alert routing to ticketing systems, case workflows and any SOAR playbooks built on Splunk must be rebuilt against Elastic connectors or APIs. | List each integration and its owner, and decide early whether Elastic Cases or the existing ticket tool remains the system of record. |
| Length of the parallel run | Running Splunk and Elastic side by side keeps detections comparable but doubles infrastructure and licensing for the overlap period. | Set exit criteria for each rule family, such as matching alert outcomes, and agree the end date in writing before work starts. |
Questions teams ask before moving from Splunk to Elastic Security
How much effort does a Splunk to Elastic Security migration take?
Effort depends mainly on how much detection logic and how many log sources Splunk carries today. Correlation searches, lookups, macros, notable event handling and dashboards each need translation into Elastic detection rules, Timeline views and Kibana dashboards. On the collection side, Elastic Agent managed through Fleet replaces universal forwarder rollouts, so every host, container and network source needs a policy and a cutover. The drivers to inventory are the number of correlation searches, how many depend on custom SPL features, how many sources forward data today, which SOAR playbooks consume Splunk outputs, and which retention rules apply. Ask any implementation partner for this inventory in writing before agreeing a fixed scope.
How long does the migration take and what sets the timeline?
No single duration fits every environment. The two largest drivers are the number of detection rules that must be rebuilt and validated and the length of the parallel run, during which Splunk keeps receiving data while Elastic produces alerts and analysts compare results until detections match. Source count matters too, because each cutover needs change approval and log validation. Less obvious drivers include how many rules need field names changed after normalization, how much history must be reloaded, and how quickly the team can work through false positives. A fixed-scope agreement sets deliverables and timing in writing before work starts, so ask for the schedule to be tied to the rule inventory and to clear exit criteria for the parallel run.
What does our internal team need to supply during the move?
The internal team has to own decisions that no outside party can make for the organization. Plan for:
- A detection owner who approves which Splunk correlation searches become Elastic rules and what severity each carries.
- Platform engineers who run Elasticsearch nodes, Fleet, certificates and storage, including the three master-eligible nodes a highly available cluster needs.
- SOC analysts who validate alerts during the parallel run and tune noise.
- Change managers who schedule each log source cutover.
- A Splunk administrator for exports and final sign-off on what can be retired.
Analyst time during the parallel run is often under-planned, so reserve it explicitly in the project schedule.
Can our own team migrate to Elastic Security without outside help?
Some teams can, particularly if they already run Elasticsearch in production and have engineers comfortable with detection engineering. The gaps tend to be cluster sizing, security hardening, backup and restore testing, upgrade planning, and rewriting SPL logic in Elastic's query language. Teams without that experience often split the work: internal staff own detection content and analyst workflows, while an implementation partner plans, deploys, hardens, backs up and documents the platform inside your own cloud account, data center or air-gapped network. DeployOpen works this way. It plans, implements, integrates, hardens, backs up, upgrades, documents and supports self-hosted platforms, usually under a fixed scope agreed in writing, with ongoing support available as a retainer. The goal is that your team can run the platform after handover.
Does the free Basic tier include the Elastic detection engine?
The free Basic tier does not clearly cover the detection engine, so confirm before you budget. Elastic's self-managed subscriptions page lists the detection engine, machine learning anomaly detection and case management under Platinum, a tier Elastic no longer sells to new customers. Security features such as malware and ransomware prevention, host isolation and SAML or OpenID Connect single sign-on sit under Enterprise. The free features that Elastic announced in 2019 include TLS, native and file realms and role-based access control. Ask Elastic which current tier includes each detection feature you rely on and get the answer in writing. New self-managed buyers must choose between Basic and Enterprise or move to Elastic Cloud. Compare tiers on the Elastic subscriptions page.
How do we move historical Splunk data into Elastic Security?
Historical Splunk data moves by export and re-ingestion, and the volume you keep drives both time and storage. Splunk lets you export search results as raw events, CSV, JSON, XML or PDF through Splunk Web, the CLI, the REST API, SDKs, the dump search command or data forwarding, and Splunk describes the CLI as its most stable retrieval method. For SIEM history, export raw events for the windows your investigations and compliance reviews need, keep timestamps and source fields intact, and re-ingest them through Elastic Agent or Logstash into data streams governed by index lifecycle policies. Confirm with your Splunk administrator which indexes have already expired, because data past retention cannot be exported. Decide early whether history loads into Elastic or stays in an archive, since that choice sets the storage plan. Review the Splunk export guide before scoping.
How do Elastic end-of-life dates affect the target version?
Choose the 9.x line for a new deployment, because the 8.x line reaches its end of maintenance sooner. Elastic's end-of-life page lists end of maintenance for 8.x on January 15, 2027, with 8.x support ending July 15, 2027, and end of maintenance for the core 9.x line on October 15, 2027. The current release lines are 9.5.5 and 9.4.8, released October 6, 2026, with 8.19.23 still maintained. If your cutover lands after January 15, 2027, starting on 8.x would mean an upgrade soon after go-live. Starting on 9.x still requires a planned upgrade before October 15, 2027, so put that work on the platform roadmap now. Confirm the current dates on the Elastic end-of-life page before you commit to a version.
How DeployOpen scopes and runs a Splunk to Elastic Security migration
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, so an Elastic Security deployment runs in your cloud account, data center or air-gapped network. We start from your current Splunk correlation searches, data sources and retention requirements, then agree the scope in writing before any build work begins.
How we scope
- Inventory every Splunk Enterprise Security correlation search, saved search and alert, and mark which map to Elastic detection rules.
- Record data sources, forwarder fleets, index retention and daily ingest so the Elastic Agent and Fleet design matches your estimate.
- Confirm the Elastic subscription tier needed for the features in scope, such as the detection engine, endpoint protection and single sign-on, before the written scope is signed.
How we build
- Deploy Elasticsearch, Kibana and Fleet Server in your environment, with node roles and a highly available master layout suited to your cluster size.
- Replace forwarders with Elastic Agent policies, then rebuild detections as rules and test each one against replayed or parallel-run events.
- Document each rule mapping, its tuning history and any SPL logic that has no direct equivalent, so detection gaps are visible before cutover.
How we hand over
- Deliver runbooks for Fleet policy changes, rule updates, index lifecycle settings and backup and restore of the cluster.
- Provide a side-by-side validation record comparing Splunk and Elastic alerts, with agreed sign-off before Splunk ingestion is switched off.
- Set out a historical data plan covering which Splunk exports are archived, in what formats, and where they are stored under your own policies.
How we support
- Ongoing support, version upgrades and continuous testing are available as a retainer after handover, scoped separately from the migration.
- Track Elastic release lines and end-of-life dates so upgrades are planned against the support windows your team must meet.
- Review detection content and alert volume periodically, and confirm licensing changes with Elastic before they affect your deployment.
