SIEM Migration Guide: Detections, Data and Parallel Running

Most SIEM migrations quietly lose detection coverage, because rules are translated without their data, parsers break on the new schema and the old platform is switched off before anyone proves the new one sees the same attacks. Organisations change SIEM for cost, cloud coverage, licensing changes or vendor consolidation, and the project is usually run as an infrastructure move when it is really a detection programme. This guide covers how to inventory what you have, decide what not to migrate, re-map log sources and parsers, translate and validate detections, handle historical data, run both platforms in parallel and decommission safely. It is written for SOC managers, detection engineers and security architects planning a move between any two SIEM platforms. For what a SIEM is and how to choose one, see the SIEM Guide.

Key takeaways

Migrate use cases, not rules: Microsoft's migration guidance advises reviewing rules that have not fired in 6 to 12 months and removing low-value alerts analysts routinely ignore, rather than translating everything.
Data first, detections second: a translated rule is worthless until the source it needs is ingested, parsed and normalised in the new platform.
Validate with tests, not syntax: every migrated detection needs a test case that fires it, using attack simulation or replayed logs, before the old rule is retired.
Parallel running is the safety net: keep both platforms live for critical use cases until alert parity is measured, and agree exit criteria before the contract end date forces your hand.
Integrations are machine identities: every collector, forwarder token and API connector is a credential that must be re-issued on the new platform and revoked on the old one.

Why migrations fail and what to plan for

A SIEM holds four kinds of asset that do not move automatically: the data pipeline (collectors, forwarders, parsers and field mappings), detection content (rules, correlation searches, watchlists, lookups), response content (playbooks, case workflows, dashboards) and the history (stored logs for investigations and compliance). Each has its own migration method and its own failure mode.

Microsoft's Sentinel migration guidance frames the work in four phases, Discover, Design, Implement and Operationalise, and notes they are a guideline that some projects extend or compress. The same structure works for any pair of platforms.

Phase	Main outputs	Exit criterion
Discover	Inventory of log sources, rules, playbooks, dashboards, integrations and retention obligations; prioritised use-case list	Every rule has a keep, replace or retire decision
Design	Target architecture, data tiers, schema mapping, access model, test plan	Design approved by SOC, platform and compliance owners
Implement	Connected sources, parsers, translated and new detections, playbooks; a minimum viable product for a few use cases first	Each migrated use case passes its test
Operationalise	Analysts working in the new platform, runbooks updated, old platform read-only then decommissioned	Agreed parity metrics met for a set period

Discover: build the inventory and cut the scope

Export everything from the current platform: saved searches and correlation rules with their trigger history, data inputs and source types with daily volume, lookups and watchlists, dashboards with usage, automation playbooks, user roles and API integrations. Then score each detection.

Usefulness: Microsoft suggests looking at true and false positive rates over the past year and aiming for detections that are about 90 percent true positive; anything that has not fired in 6 to 12 months needs a reason to exist.
Coverage value: map each rule to MITRE ATT&CK techniques so you know which coverage you lose if it is dropped. See the Detection Engineering Guide.
Replaceability: check whether the target platform already ships an equivalent rule. Microsoft recommends using out-of-the-box content where it exists rather than translating the old rule.
Prioritisation method: sort use cases by business risk, compliance requirement and stakeholder need; a MoSCoW sort (must, should, could, won't) works well for agreeing the first wave.

Record compliance obligations at the same time: which logs must be retained, for how long and in what form. These drive the historical data decision later and are often discovered too late. The Log Source Coverage Matrix Template is a practical starting format.

Design: data pipeline, schema and tiers

Most detection breakage happens here. Each SIEM has its own normalisation model: Splunk uses the Common Information Model (CIM), Microsoft Sentinel uses its own tables and the ASIM parsers, Elastic uses the Elastic Common Schema (ECS), and the Open Cybersecurity Schema Framework (OCSF) is an open, vendor-agnostic schema of categories, event classes and an attribute dictionary. A rule written against CIM's Processes.parent_process_name only works on the new platform if the equivalent field is populated from the same source.

Pipeline decisions

Decision	Options	Trade-off
Collection	Native agents of the new SIEM, or a vendor-neutral pipeline layer that can send to both	A neutral pipeline makes dual-feeding and future moves easier, but adds a component to run and secure
Normalisation	Parse at ingest, or parse at query time	Ingest-time parsing is faster to query; query-time parsing tolerates source format changes
Data tiers	Hot analytics tier, cheaper lake or archive tier	Detections need the analytics tier; bulk and compliance logs can live in cheaper storage
Dual-feed period	Send to both SIEMs, or cut sources over one by one	Dual-feeding costs ingest twice but is the only way to measure parity

Size the new platform from measured daily volume per source, not from licence assumptions, and check that high-value sources are not pushed into a tier that rules cannot query. The Storm-0558 case below shows why the logging tier itself can decide whether an attack is visible at all. See the Log Management and Retention Guide.

Access and identity design

Analyst access: rebuild roles from the target platform's model rather than copying old roles; review who has access to sensitive indexes or tables.
Integration credentials: list every forwarder token, HTTP event collector token, cloud connector app registration and SOAR API key. Issue new, scoped credentials for the target, store them in a secrets manager and schedule revocation of the old ones at decommission. See the API Key Management Guide.
Service accounts: collectors that read Windows event logs or cloud audit APIs often run with broad rights; take the migration as the moment to cut them back. See the Service Account Security Guide.

Implement: translate and validate detections

Translation is the visible part of the work and the easiest to get wrong. Query languages differ in more than syntax: real-time rules, trigger conditions and actions do not always have an equivalent. Microsoft's Splunk-to-Sentinel guidance, for example, notes that Splunk has scheduled and real-time rules triggered by number of results, hosts or sources, while Sentinel scheduled query rules trigger on a threshold number of query results.

Translation routes

Route	How it works	When to use
Replace with built-in content	Install the target vendor's equivalent rule	Common techniques the vendor already covers well
Vendor migration tooling	Tools such as Sentinel's SIEM migration experience match Splunk or QRadar detections to built-in rules and auto-translate others	Large rule sets; always review the output
Sigma as an intermediate	Express the logic as a Sigma rule and convert with pySigma backends for Splunk, Elasticsearch, Microsoft Sentinel and others	You want portable content and expect to move again
Manual rewrite	Map sources to tables, identify fields and entities, rewrite logic, define trigger and action	Complex correlations, custom logic, high-value rules

Microsoft's own translation examples need care: its SPL-to-KQL table maps mvcount to dcount, which returns a distinct count rather than the number of values in a multi-value field. Treat every automatic or documented mapping as a draft. See the Sigma Rules Guide, the KQL for Threat Hunting Guide and the Splunk SPL for Threat Hunting Guide.

Validation

Write the test before translating: for each must-have use case, define the input (a log sample, a simulated technique or a replayed event) and the expected alert.
Run the test on the old platform: if the old rule does not fire, you have found a gap that was already there; fix or retire it rather than migrating a broken rule.
Run the test on the new platform: confirm the alert fires with the right entities (user, host, IP) mapped, because incident correlation and playbooks depend on them.
Compare noise: run both rules on the same live data for at least two weeks and compare alert counts and true positive rate.
Record evidence: keep the test, result and approver per rule so audit and future migrations can reuse it.

Attack simulation and breach and attack simulation tooling make step 1 repeatable. See the Detection Engineering Maturity Model for how detection-as-code practices make this cheaper next time.

Historical data and retention

Decide early whether historical data moves, stays or is exported to cheap storage. The options are leaving it on the old platform in read-only mode until it ages out (simple, but you keep paying the licence), exporting it to an archive or data lake queryable from the new platform, or re-ingesting it into the new SIEM (usually the most expensive). Microsoft's guidance for Sentinel compares a data lake tier (retention up to 12 years in Parquet format), Azure Data Explorer and Blob Storage, and gives a sense of scale: at 1 GB per second, moving 100 TB takes at least about 27 hours, assuming disks, network and compute keep pace.

Protect integrity and chain of custody during export: hash exported files, log who ran the export and where it went, and keep the export store under the same access controls as the SIEM. Retention obligations from regulation, contracts or legal holds must be met across the transition, including any logs under litigation hold.

Parallel running and cutover

Run the old and new platforms side by side for the must-have use cases. Cut over in waves by source or by use case, never all at once.

Wave 0, MVP: three to five use cases from a few high-value sources (identity provider, endpoint detection, cloud audit logs) to prove the pipeline, roles and incident workflow.
Wave 1: remaining must-have use cases, analysts triaging in the new platform while the old one still alerts.
Wave 2: should-have use cases, dashboards, reporting and remaining playbooks.
Read-only period: stop alerting on the old platform, keep it searchable for investigations.
Decommission: revoke every old integration credential, remove agents and forwarders, confirm historical data obligations are met, then end the contract.
Rollback: until the read-only stage, any wave can be reversed by re-enabling old alerting, which is why the old rules and data feeds stay live until parity is signed off.

Small and large organisations

A small team with a few dozen rules can often replace most of them with the target's built-in content and run a short parallel period of two to four weeks. A large SOC with hundreds of custom rules and many business units should plan in quarters, fund dual ingestion explicitly, and consider a vendor-neutral pipeline so the next migration is easier. Where an MSSP runs the SIEM, contract the migration deliverables, test evidence and credential hand-back explicitly. See the Co-Managed SOC and SOC-as-a-Service Guide.

Measuring the migration

Use-case parity: percentage of must-have use cases migrated and passing their test (target 100 percent before alerting stops on the old platform).
Source parity: daily event count per source on old versus new, with a tolerance band; a drop flags a broken collector or parser.
Alert parity: alert counts and true positive rate per migrated rule over the parallel period.
ATT&CK coverage delta: techniques covered before and after.
Credential clean-up: old integration credentials still valid after decommission (target zero).
Analyst time to triage: median triage time in the new platform compared with the old baseline.

Framework mapping

Framework	Reference	Migration relevance
NIST CSF 2.0	PR.PS-04 Log records are generated and made available for continuous monitoring	No logging gap during cutover
NIST CSF 2.0	DE.CM-09 and DE.AE-02	Monitoring and analysis continue in both platforms
NIST SP 800-53 Rev. 5	AU-6, AU-9, AU-11, AU-12	Review, protection, retention and generation of audit records
NIST SP 800-53 Rev. 5	SI-4 System Monitoring, CA-7 Continuous Monitoring	Monitoring coverage maintained and evidenced
CIS Controls v8.1	Control 8 Audit Log Management (centralise, retain and review logs)	Centralised logging and retention through the transition
ISO/IEC 27001:2022 Annex A	A.8.15 Logging, A.8.16 Monitoring activities	Logging and monitoring controls remain effective

Common failure patterns

Translating every rule: migrating years of untested, noisy rules doubles the work and imports the noise.
Rules without data: a rule is marked migrated but its source table is empty or mis-parsed, so it can never fire. Microsoft notes analytics rules will not run without the required data types.
Lost entity mapping: alerts fire but without user and host entities, so correlation, enrichment and playbooks fail silently.
Contract-driven cutover: the old licence ends before parity is proven and the team switches off with known gaps.
Orphaned credentials: old forwarder tokens and connector app registrations stay valid for years after decommission.
Cheaper tier, blind rules: high-value logs are routed to a tier detections cannot query to save cost.

Lessons from incidents

The Microsoft Storm-0558 Key Breach is the clearest example of logging decisions deciding detection. The US State Department detected anomalous mailbox access because its licence included premium audit logging, and its analysts had built a custom alert on the MailItemsAccessed event. Organisations without that logging could not see the same activity, and Microsoft later expanded logging for all customers. In a migration, the equivalent risk is a high-value source that is dropped, downgraded to a cheaper tier or left unparsed on the new platform. Check that every source behind a must-have detection arrives with the same fields before old alerting stops. See the Storm-0558 and Cloud Key Theft Profile.

Practitioner checklist

Export and score every rule; record keep, replace or retire with a reason.
Map each kept rule to ATT&CK and to the log source and fields it needs.
Agree retention obligations and the historical data option before design sign-off.
Choose built-in content first, Sigma for portable logic, manual rewrite for high-value custom rules.
Write and run a test for every must-have use case on both platforms.
Dual-feed critical sources and compare daily event counts per source.
Rebuild roles and issue new scoped integration credentials; plan revocation of old ones.
Set written parity exit criteria before the old contract end date.
Keep the old platform read-only until investigations and retention needs are covered.

SIEM Migration Guide: Move Detections, Parsers and Data Without Losing Coverage