Migrating Splunk rules to Elastic Security in practice
Automatic Migration in Elastic Security translates Splunk rules and dashboards. How the process works, the requirements and why every rule needs a review.
Moving from Splunk to Elastic Security usually stalls not on the data but on the rules. Over the years a security team has written dozens or hundreds of SPL queries, saved as correlation searches, and nobody wants to rewrite them from scratch. Elastic answers with a tool called Automatic Migration, which translates rules and dashboards into the Elastic Security format. In the Security 9.1 release notes (29 July 2025) rule migration is listed as generally available (GA), and Elastic 9.2 of 23 October 2025 added improvements to it and dashboard migration as a technical preview. Below we describe how it works in practice and where the automation ends and the analyst’s work begins.
What the tool can do
Automatic Migration accepts rules exported from Splunk (saved searches) and, as a technical preview since 9.2, dashboards. For rules it works in two modes, which you choose when you start the translation:
- matching to Elastic rules: if the Elastic library has a ready-made rule that does something similar, the migrated rule is replaced by it. This uses fewer model tokens and gives you a rule that Elastic itself keeps updated,
- translation into a custom rule: when the matching option is off or there is no counterpart, the SPL query is converted into an Elastic query, and the resulting rule is “custom” and does not update automatically.
The translation is performed by a language model that you connect through a connector. That is an important decision, because choosing the model is also choosing where your rule definitions go.
Requirements
According to Elastic’s documentation you need:
- a working connector to a large language model (LLM),
- Kibana privileges for the Automatic Migration feature and at least read access to rules,
- for self-managed clusters, an Enterprise subscription and machine learning enabled,
- for Elastic Cloud, machine learning enabled, with at least 4 GB of memory per machine learning zone recommended.
Check the licensing requirements against your own subscription before you plan a project. They change between releases and deployment types.
How the process works
- In the Get started section you choose the model connector.
- You choose to translate rules (or dashboards) and open the upload window. The window gives you the query with which you export rules from Splunk to a JSON file. The default query downloads correlation searches. The documentation advises against downloading all saved searches, because most of them are not detection rules. You can use your own query as long as you save the result as JSON.
- A large file can be split into parts so that it does not exceed the model’s context window.
- The tool detects whether the rules use macros, lookups, reference sets or MITRE mappings. If so, it asks you to export and upload them. Without them some rules will end up as partially translated.
- You click Translate. Progress is visible on the page, and you get a notification when it finishes.
- On the Translated rules page you review the results, install them and enable them.
You do not need to have data in Elastic beforehand. The tool suggests integrations that provide the data the translated rules need. Until the data is there, Unknown index errors may appear, which the documentation tells you to ignore until you add the sources.
Statuses and what to do about them
Every rule gets one of five statuses:
| Status | Meaning | What you do |
|---|---|---|
| Installed | The rule is already in Elastic SIEM | Check and enable it |
| Translated | Ready to install | Review and install |
| Partially translated | Part of the query could not be translated | Supply the index pattern, macros or lookups, fix the syntax |
| Not translated | Nothing from the query could be translated | Write it again or reprocess with another model |
| Failed | The translation ended with an error | Read the message and reprocess |
For partially translated rules that lack an index pattern there is an Update missing index pattern button. It changes all migrations that contain the [indexPattern] placeholder, not only those visible in the table. Rules that were not translated can be reprocessed with the same or a different connector. Splunk severity levels are mapped to the Elastic scale: 1 and 2 to low, 3 to medium, 4 to high, 5 to critical.
Why every rule needs a review
The tool saves a lot of work but does not replace a review. From our point of view there are four things to watch.
First, whether the rule has data. A translated rule for logs you do not collect will detect nothing while looking as if it works. Before enabling it, check in the list of integrations which sources it needs and whether you have them.
Second, whether the meaning is preserved. The model translates syntax, but field names in Splunk and in the Elastic ECS schema differ, and subtleties in SPL (grouping, time windows, filtering through macros) are easy to change by a single setting. In the details panel compare the source rule with the translated one, and check on historical data whether it gives similar results.
Third, whether it creates noise. When a rule was matched to the Elastic library, it may behave differently from your original and raise a different number of alerts. Start with a dozen or so of the most important rules and watch the alerts for a few weeks before you enable more.
Fourth, what happens to the rest of the Splunk environment. Rules are one part of a migration. You still have data collection (forwarders are replaced by Elastic Agent or a collector), alert actions, integrations with the ticketing system, reports and permissions. As for dashboards in technical preview, according to the documentation visualisation, chart, table and single value panels are supported, and the others are marked as unsupported.
How we approach such a project
We start with an inventory: which rules are really used (the number of alerts and responses over the last year), which are dead and which cover requirements such as compliance. We do not migrate the unnecessary ones. We translate the rest with the tool, review them in pairs with the client’s analyst and test them in parallel with Splunk. Only after a period of running both systems together do we switch off the old rules.
We run such projects as part of monitoring migration. How to start with rules in Elastic Security from scratch is shown in SIEM on Elastic Security: first steps with detection rules. Enriching events with reference lists, which Splunk does with lookups, can be done in Elastic in a similar way with the LOOKUP JOIN command described in our article on ES|QL and log enrichment.
