End to end migration flow

Understanding the migration workflow

Before designing the wizard, I mapped how a SIEM migration actually unfolds across detection engineers, SOC analysts, and security leads, the three roles a migration touches. The friction wasn't in any single rule: it accumulated in the manual rewriting, the spreadsheet tracking, the untested translations, and a cutover date nobody could call safe.
Lead
Cost or contract decision starts the move off Splunk or QRadar
→
Engineer
Export rules & dashboards, upload with macros and lookups
→
Engineer
AI matches to prebuilt rules or translates to ES|QL
→
Analyst
Review the five states, reprocess or fix what fell short
→
Lead
Install what's ready, resolve missing integrations & cut over

Detection engineer journey

10 steps · 5 pain points, as mapped before Automatic Migration
  • 1Export every detection rule from the legacy SIEM
  • 2Inventory which rules are still worth keeping
  • 3Read each SPL or AQL query to reconstruct its intentPain
  • 4Rewrite the query by hand in ES|QLPain
  • 5Chase the macros and lookup tables the rule silently depends onPain
  • 6Find or set up the data source each rule needs
  • 7Test the rewrite and hope nothing was lost in translationPain
  • 8Log the status in the migration spreadsheetPain
  • 9Repeat for hundreds of rules, weeks to months of expert time
  • 10Recreate the dashboards the team relies on every morning
✓5 of 10 steps were pain points, and steps 3 to 8 repeated for every single rule. LLM translation with prebuilt matching compressed the rewriting into a reviewable afternoon, and uploaded macros and lookups resolve automatically: 11,000+ rules translated since launch.

SOC analyst journey

8 steps · 4 pain points, as mapped before Automatic Migration
  • 1Keep the daily queue running in the old SIEM while the migration happens
  • 2Triage in two consoles at once during the transitionPain
  • 3Relearn which translated rule replaced the one known by namePain
  • 4Spot coverage gaps only when an expected alert never firesPain
  • 5Verify each translated rule behaves like the original
  • 6Distrust automated translations with no visible confidencePain
  • 7Escalate questionable translations back to engineering
  • 8Sign off rule by rule before anything runs in production
✓4 of 8 steps were pain points. The five state results table made confidence visible per rule instead of assumed, a mistranslation is a visible status, not a silent gap, and nothing activates without the analyst's say so.

Security lead journey

8 steps · 5 pain points, as mapped before Automatic Migration
  • 1Decide to leave the legacy SIEM on cost or contract terms
  • 2Scope the migration: hundreds of rules, months of expert timePain
  • 3Choose between a services engagement or a spreadsheetPain
  • 4Track progress one spreadsheet row per rulePain
  • 5Pay for two SIEM licenses while both run in parallelPain
  • 6Ask "can we cut over yet" with no signal to answer itPain
  • 7Accept losing marginal rules to protect the deadline
  • 8Cut over and hope the coverage held
✓5 of 8 steps were pain points. A guided wizard with explicit per rule status turned an unbounded services project into a trackable product flow, and missing integrations point at their fix instead of surfacing after cutover: ~300 migrations completed.
Detection engineer SOC analyst Security lead Select a role to explore its journey