Splunk or QRadar to Sentinel: A Migration Plan

A Splunk or IBM QRadar to Microsoft Sentinel migration is a phased project, not a cutover weekend. You list what the old SIEM actually does, keep the detections that still earn their place, connect the data those detections need, rebuild automation and dashboards, decide where historical logs will live, and run both platforms until every migrated rule has been tested. Microsoft's SIEM migration tool speeds up detection mapping, but it only recommends built-in content, so custom logic still needs someone who writes KQL. If you want a partner for the Sentinel side, see our Microsoft Sentinel services in Dubai.

Why move from Splunk or QRadar to Microsoft Sentinel?

Move when the rest of your security stack is already Microsoft and you want SIEM and XDR in one place. Microsoft describes Sentinel in the Defender portal as a unified SIEM and XDR experience, which matters most if you already run Microsoft Defender XDR.

Microsoft's migration guide lists the problems it sees with legacy SIEMs:

• Infrastructure work: teams spend time on setup, maintenance and patching instead of analysis, and run into storage or query limits as data grows.
• Cloud coverage: on-premises architectures may not cover cloud assets in Azure, Microsoft 365, AWS or Google Cloud well.
• Alert load: correlation rules are hard to maintain, and analysts face large numbers of false positives.

Contract dates can set the timing. Microsoft notes that an organisation might need to move urgently because of a licence expiration, so start planning well before the old renewal date. We run Microsoft Sentinel for 50+ client tenants, and our SOC is based in Dubai.

What should you inventory before migrating?

Inventory everything the old SIEM does, then decide what is worth moving. Microsoft's planning guide asks you to decide, before migration starts, which detections and use cases are actively useful to your business.

• Data sources: every log source, how it is collected and how much it sends each day.
• Detections: every enabled rule or saved search, with its alert history. Microsoft suggests reviewing rules that have not triggered an alert in the last 6 to 12 months.
• Dashboards and reports: who uses each one, and how often.
• Automation: Splunk SOAR or QRadar SOAR playbooks, scripts and ticketing integrations.
• Retention obligations: how long your regulators, auditors, contracts or internal policy require logs to be kept, and whether anyone searches the old data.
• Owners: a named person for each data source and each detection, who can confirm the new version behaves like the old one.

The data source list doubles as your cost model. Sentinel cost depends on the tier data is ingested into, the volume stored and how long you keep it. Expect the detection list to shrink, too. Microsoft warns that some Splunk detections may be redundant in Sentinel and should not be migrated blindly, and it gives the same advice for QRadar rules.

How does the SIEM migration tool map your detections?

It reads an export of your Splunk or QRadar rules and recommends matching Microsoft Sentinel analytics rules and Defender XDR native detections, plus the data connectors those rules need. Microsoft states that it analyses custom detections as well as standard ones.

1. Export your rules. For Splunk you run a search Microsoft supplies, and you need a Splunk admin role to export all alerts. For QRadar you run Microsoft's collector script with a QRadar authorised service token that has Admin privileges.
2. Upload the export. In the Defender portal, open the SOC Optimization tab, choose Set up your new SIEM and upload the file.
3. Review the analysis. Recommendations appear as cards grouped by Content hub solution, and a downloadable report lists the rules that have no good match.
4. Enable or edit. Connect any missing connector, then enable the recommended rule or open it in the rule wizard first. For Splunk rules, the wizard lets you compare the original SPL with the Sentinel KQL.

Three limits shape the plan. The tool needs Sentinel in the Defender portal, at least Sentinel Contributor permissions and Security Copilot enabled in your tenant, although Microsoft states that the tool itself does not consume SCUs or generate SCU-based charges. It does not install connectors or enable rules on its own. And it maps only to built-in content: out-of-the-box Sentinel connectors and detection rules, and Defender XDR native detections. Logic specific to your business still has to be rewritten in KQL and tested by hand.

Microsoft's rule migration steps for both platforms end the same way: test each rule with every relevant use case, and if it does not give the expected results, review the KQL and test again. Our Sentinel analytics rules page explains the rule types and what changes when you adopt the Defender portal.

How do you move data sources and historical logs?

Connect live data sources first, then decide separately what happens to old logs. A Sentinel analytics rule needs its data type present in the Log Analytics workspace before it can be enabled, so connector work sets the pace for detection work.

Order the connectors by the detections you decided to keep. Defender XDR native detections do not need Sentinel data connectors at all, which can shorten the list if you already run Defender. Our Sentinel data connectors page covers ingestion in more detail.

For historical logs, ask who will search them, how often and for how long. Microsoft compares three targets:

• Microsoft Sentinel data lake: Microsoft's recommendation for most new migrations. It keeps up to 12 years of security data, and you query it with KQL from the Defender portal. Cost comes from lake storage plus the compute your queries and notebooks use.
• Azure Data Explorer: suited to frequent access where you want control over cluster size, with more management work because it sits outside Sentinel.
• Azure Blob Storage: suited to logs kept only for compliance or audit, when fast access and performance do not matter.

The export itself needs planning. Microsoft names dump or the Splunk command line interface as the most stable methods for large Splunk exports. For QRadar, it recommends small time ranges in AQL queries and migrating only the data you need, because the export is resource intensive. The amount of data is the main factor in how long the migration takes.

How do you rebuild playbooks and dashboards?

Rebuild them rather than copy them. Sentinel handles simple incident tasks with automation rules and runs more complex response sequences as playbooks built on Azure Logic Apps, so each Splunk SOAR or QRadar SOAR workflow needs to be redesigned in those terms. Microsoft's guidance on choosing what to automate:

• Pick procedures that are clearly defined, with minimal variation and a low false-positive rate.
• Require human confirmation before high-impact actions are taken.
• Keep decision points few, with binary criteria.
• Leave the most complex tasks to analysts.

Dashboards become Azure Workbooks, which mostly use KQL queries against your Sentinel workspace. Microsoft's advice is not to migrate every dashboard, and to focus on those that are critical and used regularly. For executives without Azure access, it suggests a reporting tool such as Power BI.

How long should the old and new SIEM run side by side?

Until every migrated detection has been validated, not for a fixed number of weeks. The length depends on how many rules you keep, how quickly data sources connect and how often the threats you detect actually occur.

Microsoft suggests starting with a minimum viable product for several use cases, then using that Sentinel instance to test each use case as you add it. It also recommends preparing a validation process with defined test scenarios and a test script. Switch the old platform off only when:

• each kept detection has fired correctly in Sentinel, on a test or on real activity;
• alert volume is tuned to a level your analysts can work;
• every data source in the inventory reports into the new workspace;
• historical logs are exported and searchable where you chose to keep them;
• the owner of each detection has signed it off.

Microsoft's Deployment and Migration workbook tracks progress inside Sentinel, from data connectors to analytics rules, incidents and automation. Work backwards from the old licence renewal date so the overlap is not cut short by a contract deadline.

What changes for your security team after the move?

The query language, the portal and the daily workflow. KQL replaces SPL in Splunk and AQL in QRadar, and Microsoft calls KQL the language you use to work with data in Sentinel, so build training time into the plan for every analyst who writes searches. Our KQL threat hunting page shows what hunting looks like once the data is in place.

The portal matters too. Microsoft states that after 31 March 2027, Sentinel will no longer be supported in the Azure portal and will be available only in the Defender portal, so build and document a new deployment there. Analysts triage from the Incidents page, where an incident is a collection of alerts, and dig deeper with the investigation graph. As Microsoft puts it, a migration has to update the SOC's tasks and processes, not only its technology. Our guide to Sentinel in the Defender portal covers the portal change in practice.

If you want Sentinel operated for you after cutover, our Dubai-based SOC works to a 5-minute response for P1 incidents, 24/7.