Stop rewriting detection rules by hand: automatic Sentinel-to-Elastic migration is here

Wed, 29 Jul 2026 00:00:00 GMT

Elastic automatically translates your Microsoft Sentinel detection rules into Elastic Security. Export your Scheduled and Near Real Time (NRT) analytics rules from Sentinel, upload them, and Elastic picks up the mapping and translation from there using an LLM you choose. Watchlists and severity mappings carry over. This is the first automatic migration path off a modern SIEM, available now in Tech Preview in 9.5, and it works across multiple cloud providers and regions so you can deploy closer to where your data lives.

Which Microsoft Sentinel rule types can be migrated automatically?

Automatic Migration focuses on the rules that carry your detection logic. In 9.5, it translates Scheduled and Near Real Time (NRT) analytics rules from Microsoft Sentinel, exported from your Sentinel workspace, and handles the translation for you.

It uses the same mapping and translation as our existing rule migrations, now extended to Microsoft Sentinel. The following are supported:

Integration identification with just rule export
Support for the following rule types:
- Near-real-time (NRT) detection analytics rules
- Scheduled Analytic Rules
Support for Watchlists to ES|QL Lookups
Severity Mapping

How to migrate Microsoft Sentinel detection rules to Elastic

The migration runs in a few steps, from exporting your rules in Sentinel to reviewing the translated versions in Elastic. Once you've decided which rules and data to migrate, follow these steps:

On the Security Launchpad, open Manage Automatic Migrations, select your AI provider, and expand Migrate your existing SIEM rules to Elastic.

Select the drop-down on the top right for Microsoft Sentinel. Let Elastic guide you through exporting your rules from Sentinel and uploading them into Elastic Security. Elastic handles the finer details by scanning for watchlists and then prompts you to upload them when found.

Once the rules are uploaded, you can view their status.

Installed: Already added to Elastic SIEM. Click View to manage and enable it.
Translated: Ready to install. This rule was mapped to an Elastic-authored rule, or translated by Automatic Import. Click Install to install it.
Partially translated: Part of the query could not be translated. You may need to specify an index pattern for the rule query, upload missing files, or fix broken rule syntax.
Not translated: None of the original query could be translated.
Failed: Translation failed. Refer to the error for details.

For more information, refer to the technical documentation.

After clicking View Rules, you will have the ability to edit and install rules.

Should you migrate rules first or data first?

One of the first decisions in a migration is sequencing: data or rules first. Elastic supports both paths, so you can start wherever makes sense for your team.

Path	When to use	What happens
Rules first	You do not know exactly which data sources to prioritise before moving any logs.	Translate your Sentinel rules first. Elastic identifies which integrations those rules need, so you can plan data onboarding around what your detections actually require.
Data first	Your log sources are already being onboarded, or you want detections to work the moment they're installed. Onboarding data beforehand improves the translation quality.	Onboard your log sources into Elastic, then migrate your Sentinel rules to match. Rules can be installed and enabled immediately against data that's already flowing.
Custom data	You have proprietary or non-standard log sources that don't map to a prebuilt Elastic integration.	Use Automatic Import to ingest custom data sources in minutes, then migrate or write rules against them.

By identifying exactly which integrations are needed before moving a single log, teams can build a precise, risk-aware roadmap for their migration project. This transparency eliminates the guesswork and helps ensure that critical visibility gaps are addressed long before you fully decommission your environment.

What happens after your Sentinel rules are running in Elastic

Once your rules are running in Elastic, Workflows lets you build automation around them. The moment a rule fires, a workflow can kick off multi-step remediation, enrichment, and notification automatically. And building these automations in Agent Builder lowers the barrier, so you can create a workflow in natural language.

How Elastic AI fits into a Sentinel-to-Elastic migration

Elastic Security brings generative AI into the SOC with retrieval augmented generation (RAG) and open agentic frameworks. Automatic Migration joins the lineup of Elastic Security’s AI features, helping SOC teams strengthen defenses across the IT environment:

Automatic Migration for Detection Rules complements Elastic’s deep library of prebuilt rules to broaden detection use case coverage.
Automatic Import extends visibility and powers detection rules by onboarding custom data sources in minutes.
Agent Skills assist in the response process and less time context switching.

Elastic’s SIEM and XDR solution helps analysts detect earlier and respond faster.

Try automatic detection rule migration

Migrating a SIEM has always meant rebuilding your detection rules by hand, and that cost is what keeps teams on a platform long after they've decided to leave. Automatic Migration simplifies that process, providing mapping to existing Elastic rules and helping to translate the rest. Your watchlists and severity levels carry over as well, and you move on your own terms, with your data and your tooling under your control. For further details check out our documentation.

Try it free, or get in touch. Have feedback? Tell us what you think in the Elastic Community Slack channel or on the Elastic Security forum.