Automatic Migration

Security teams do not leave their SIEM lightly. Years of tuned detection rules, saved dashboards, and institutional knowledge live inside Splunk or QRadar, and rewriting all of it by hand is the single biggest reason migrations stall or never start.

Automatic Migration is the LLM powered tool I designed to remove that barrier: it ingests a team's existing detection rules and dashboards, translates them to Elastic's query language, maps them to prebuilt Elastic rules where an equivalent already exists, and generates custom rules for the rest, all behind a wizard that keeps the analyst in control of what activates. Unlike the Onboarding System proposal it later inspired, this one shipped and is live in production today.

When I picked up this work, migration wasn't a product yet: it lived as a step buried inside Get Started. A usability test on that flow surfaced a finding that reframed everything: discoverability was the product's real bottleneck. Teams that couldn't see that migration existed never weighed Elastic as a serious alternative to their current SIEM, so every discoverability miss was a lost customer, not a lost click. I made the case that migration deserved to be its own entry point rather than a sub step of someone else's flow, and that reframing became Automatic Migration. From there I owned the experience end to end, from the first upload flyout to the five state results table, partnering closely with ML engineers to turn what the translation model could and could not guarantee into honest UI states. When post launch telemetry raised the stakes on the AI connector placement, I built both variants as functional prototypes and designed the usability study that settled the debate with evidence. The feature shipped and is live in production today.

Before this feature, migrating to Elastic Security meant a services engagement or a spreadsheet: export every rule, read every query, rewrite it by hand, test it, and hope nothing was lost in translation. For a mature SOC that is hundreds of rules and weeks to months of expert time.

The flow starts with a choice between migrating rules or dashboards (rules from Splunk or QRadar, dashboards from Splunk), then an upload of the team's exported artifacts. The LLM translates each rule to ES|QL, the Elasticsearch Query Language, first checking it against Elastic's 1,300+ prebuilt detection rules so teams inherit maintained rules instead of custom translations wherever possible.

Every result lands in a review table with an explicit status: installed, translated, partially translated, not translated, or failed. Partial and failed rows can be sent back through the AI for another pass, and rules that depend on missing integrations point directly at what needs to be installed. Nothing activates without the analyst's say so.

The first release put the AI connector choice and the "match to prebuilt rules" toggle in a modal that appeared after clicking Translate. Post launch telemetry raised the stakes on that decision: over 1,400 customers reached the connector step, the widest exposure of any point in the flow, and the team was split, engineering favoring the modal, design believing the settings belonged inline as a fourth step of the upload flyout. Instead of arguing, I built both variants as a functional prototype in Elastic's EUI design system and designed a counterbalanced, task based usability study around them, piloting it with five simulated user archetypes before recruiting real participants. The pilot favored the inline variant four to one: the modal read as an interruption, while the inline step gave analysts a sense of control before committing. That evidence resolved the debate and set the redesign direction I handed off.

An LLM translating detection logic will sometimes be wrong, and in security the cost of a silent mistranslation is an attack nobody sees. The design treats the model as a fast but fallible junior analyst whose work is always reviewed.

Automatic Migration taught me that trust in an AI product is built by the workflow around the model, not by the model itself. The riskiest moments were never the visible failures, a failed translation announces itself and invites a retry. The dangerous ones were silent: a mistranslated detection rule that looks fine and never fires. Most of the design work was about making sure nothing important could stay silent.