Multi-SIEM estates are common across the GCC and India. Acquisitions, country-level IT teams and different regulators leave one enterprise running two or three SIEMs, each with its own collectors, parsers, query language and detection library. Consolidating onto one cloud-native SIEM is the obvious goal. The SIEM migration itself is where most programmes stall.
This article walks through a recent engagement in which HIT Services helped a large enterprise group with operations in Saudi Arabia, the UAE and India move from Splunk, IBM QRadar and Elastic Security to Microsoft Sentinel. The client and the security data pipeline technology are anonymised. The method is vendor-neutral and applies to any SIEM migration.
The starting point: three SIEMs, three countries, one SOC
The group had grown through acquisition, and each region had chosen its own SIEM:
- Saudi Arabia: IBM QRadar on premises, covering banking and critical-infrastructure subsidiaries subject to the NCA Essential Cybersecurity Controls (ECC), the SAMA Cyber Security Framework and the Personal Data Protection Law (PDPL).
- United Arab Emirates: Splunk Enterprise for operations in Dubai and Abu Dhabi, aligned to the UAE Information Assurance Regulation and the Dubai Electronic Security Center's Information Security Regulation.
- India: Elastic Security for shared-services and technology centres, operating under CERT-In's directions, including 180-day log retention within Indian jurisdiction, and the Digital Personal Data Protection (DPDP) Act.
One group SOC was expected to monitor all three. In practice analysts switched between three consoles and three query languages, and detection engineers maintained the same use cases three times over. The group standardised on Microsoft Sentinel to unify detection, automation and reporting, and asked for the move to happen without a gap in monitoring.
Why multi-SIEM migrations usually take months
The group's internal plan estimated 9 to 12 months. That is typical, and the reasons are well known:
- Collection is tied to the SIEM. Splunk forwarders, QRadar DSMs and Elastic Agents each need re-pointing or replacing, source by source, often with a change window per site.
- Detection rules do not translate one-to-one. Splunk SPL searches, QRadar AQL rules and building blocks, and Elastic EQL and query rules encode logic differently from KQL analytics rules in Microsoft Sentinel.
- Nobody is sure which rules matter. Years of rule sprawl leave duplicates, disabled rules and rules whose data source no longer exists.
- Parallel running is expensive. Ingesting everything into two SIEMs during a long transition inflates licence and cloud costs.
- Regulation limits shortcuts. Data residency, retention and audit-evidence obligations in each country must hold throughout the cutover, not just at the end.
The approach: decouple, map, prove, cut over
1. Decouple log collection with a security data pipeline
We placed a vendor-neutral security data pipeline between every log source and the SIEMs. Existing forwarders, syslog, Windows Event Forwarding and cloud APIs were pointed at regional pipeline nodes once. From then on, the same stream could be routed to the legacy SIEM, to Microsoft Sentinel, or to both, by configuration rather than by touching sources. That single change removed most of the per-source rework and made every step of the migration reversible.
2. Normalise once, filter before ingestion
Events were parsed and normalised in the pipeline to a schema aligned with Sentinel's Advanced Security Information Model (ASIM), so analytics rules read the same field names whether data came from a firewall in Riyadh, a domain controller in Dubai or a cloud workload in Bengaluru. Low-value events were filtered and summarised before ingestion, so running two SIEMs in parallel did not double the bill.
3. Build one detection inventory mapped to MITRE ATT&CK
We extracted roughly 1,400 rules, saved searches and building blocks from the three SIEMs into a single inventory. Each was tagged with its data sources, required fields, MITRE ATT&CK techniques, alert history and owner. Detection rule mapping at this level showed the real scope:
- About a third were the same use case implemented in more than one SIEM.
- Around one in five had not fired in a year or depended on sources that no longer existed, and were retired with the SOC's sign-off.
- The remaining ~650 unique use cases became the migration scope, prioritised by ATT&CK coverage and regulatory relevance.
4. Translate through a neutral format and test against real data
Unique use cases were expressed in Sigma as a vendor-neutral intermediate format, converted to KQL analytics rules and then reviewed by engineers, instead of being rewritten by hand from three different languages. Every rule was tested against replayed historical logs and attack simulations, and its Sentinel alerts were compared with the legacy SIEM's alerts on the same data before it was approved. This is where most of the engineering hours were saved.
5. Cut over in waves, country by country
Because collection was already decoupled, each wave was a routing change: run in parallel, confirm alert parity, make Microsoft Sentinel the source of truth, and keep the legacy SIEM read-only for lookback. India went first as the largest cloud estate, then the UAE, then Saudi Arabia, where change windows were aligned with critical-infrastructure operations. Every wave had a documented rollback.
6. Keep data residency and retention intact throughout
The pipeline wrote full-fidelity raw logs to in-country object storage in each jurisdiction, covering CERT-In's 180-day requirement in India and national and sector retention requirements in Saudi Arabia and the UAE, regardless of which SIEM was live. Personal data fields not needed for detection were masked in the pipeline before leaving the country.
Results
- ~1,400 legacy rules rationalised into ~650 validated Sentinel analytics rules, each mapped to MITRE ATT&CK
- One console, one query language and one detection library for the group SOC
- Lower Sentinel ingestion from day one, because filtering and summarisation happened before data arrived
- Log collection no longer tied to any SIEM, so future changes are a configuration task, not a project
Client details are anonymised. Figures are rounded and representative; results vary by environment.
Regional lessons from Saudi Arabia, the UAE and India
- Saudi Arabia: settle data residency and NCA control evidence before choosing the migration order. Producing ECC and SAMA audit evidence from the pipeline is far easier than reconstructing it after cutover.
- UAE: Splunk estates carry years of saved searches, lookups, macros and dashboards. Inventory all of them, not just correlation searches, or analysts lose context they rely on daily.
- India: cloud and endpoint volumes grow fastest. Filtering in the pipeline before Sentinel keeps cost predictable, and CERT-In retention can live in in-country storage outside the SIEM.
SIEM migration readiness checklist
- Do you know how many detection rules you have, and which fired in the last 12 months?
- Can you send a log source to a new SIEM without touching the source?
- Is every rule mapped to MITRE ATT&CK and to the fields it needs?
- Can you prove alert parity between the old and new SIEM on the same data?
- Will data residency and retention hold during parallel running, not just after it?
- Does every cutover wave have a rollback plan?
If any answer is no, that is where the months go. Our SIEM optimization and migration practice and detection engineering team start there. You can also see related outcomes in our case studies.
Frequently asked questions
How long does a Splunk, QRadar or Elastic to Microsoft Sentinel migration take?
With log collection decoupled through a security data pipeline and a rationalised detection inventory, a multi-SIEM migration for a large enterprise can typically be completed in 8 to 12 weeks. Without them, 9 to 12 months is common.
Can detection rules be converted automatically from SPL, AQL or EQL to KQL?
Partly. Using a neutral intermediate format such as Sigma speeds up conversion, but every rule still needs engineer review and testing against real data, because data models, field names and correlation logic differ between SIEMs.
How do you avoid disruption to the SOC during a SIEM migration?
Route the same data to both SIEMs during the transition, compare alert parity rule by rule, and switch the source of truth one wave at a time with a rollback plan. The SOC keeps monitoring in the legacy SIEM until Microsoft Sentinel is proven.
Does migrating to Microsoft Sentinel affect data residency in Saudi Arabia, the UAE or India?
It has to be planned. Choose workspace regions that meet each regulator's requirements, keep full-fidelity log copies in-country where required, and mask personal data in the pipeline before it leaves the jurisdiction.