QRadar SaaS End of Life: Migration Options for Indian SOC Teams
QRadar's SaaS products hit end of life on 14 April and 31 August 2026. A decision framework for Indian SOC teams weighing Cortex XSIAM, another SIEM, or on-premises.
If you run IBM QRadar as a cloud service in India, two dates on Palo Alto Networks' end-of-life calendar now decide your SOC's next twelve months.
Executive Summary
On 5 September 2024, Palo Alto Networks completed its acquisition of IBM's QRadar SaaS assets. On 14 April 2025, Palo Alto announced end-of-life dates for the acquired product line: 14 April 2026 for QRadar on Cloud, QRadar Suite Cloud-Native SIEM, QRadar Suite SOAR, SOAR on Cloud, Randori Recon and QRadar Suite Log Insights, and 31 August 2026 for QRadar Suite EDR, XDR, X-Force Threat Intelligence, Randori Attack and QRadar Advisor with Watson.
This does not touch on-premises QRadar. IBM shipped QRadar 7.6.0 on 30 June 2026 with a fresh five-year support lifecycle — not the behaviour of a product being wound down. We covered that upgrade in detail in our QRadar 7.6.0 upgrade guide. This post is about the other half of the QRadar estate: the SaaS products that genuinely are ending, and what an Indian SOC team's real options are before the clock runs out.
The decision isn't binary. You can take IBM Consulting's no-cost path to Cortex XSIAM, move to an entirely different SIEM, retreat to on-premises QRadar, or restructure around a managed SOC model that makes the platform question secondary. Each path has a different data residency profile, a different cost curve, and a different amount of detection-content rework — and for organisations under SEBI CSCRF or CERT-In's log retention direction, the residency question isn't optional homework, it's the first filter.
1. What Actually Ended, and When
The divestiture, precisely
IBM's own divestiture notification for QRadar Suite – Log Insights records the transaction cleanly: divested to Palo Alto Networks on 5 September 2024, with end of marketing the same day under announcement AD24-0738. The QRadar Suite – EDR SaaS divestiture notice records identical dates for that product. IBM's position, stated on both pages, is unambiguous: "QRadar product support, for both SaaS and on-prem customers, will continue to be provided by IBM." The divestiture moved ownership of the SaaS assets; it did not immediately end support for them.
That changed with Palo Alto's follow-up announcement. Per the End-of-Life Summary published on Palo Alto's support site:
| QRadar SaaS product | End-of-life date |
|---|---|
| IBM Security QRadar on Cloud | 14 April 2026 |
| IBM Security QRadar Suite – Cloud-Native SIEM | 14 April 2026 |
| IBM Security QRadar Suite – SOAR | 14 April 2026 |
| SOAR portion of Cloud Pak for Security as a Service | 14 April 2026 |
| IBM Security SOAR on Cloud | 14 April 2026 |
| IBM Security Randori Recon | 14 April 2026 |
| IBM Security QRadar Suite – Log Insights | 14 April 2026 |
| IBM Security QRadar Suite – EDR | 31 August 2026 |
| IBM Security QRadar Suite – XDR | 31 August 2026 |
| IBM Security X-Force Threat Intelligence | 31 August 2026 |
| IBM Security Randori Attack | 31 August 2026 |
| IBM Security QRadar Advisor with Watson | 31 August 2026 |
Palo Alto states explicitly: "This announcement does not affect any IBM QRadar on-premise products or SKUs." If your estate is entirely on-premises, none of this changes your schedule — your relevant dates are the ones in our 7.6.0 upgrade guide, not this one.
Why this happened
The rationale is spelled out in IBM's own announcement of the deal: Palo Alto Networks wanted the QRadar SaaS customer base as a funnel into Cortex XSIAM, its AI-driven security operations platform, and structured the acquisition around "seamless migrations" for existing QRadar clients, with IBM Consulting positioned as the delivery partner. That's the commercial logic behind the free-migration offer discussed in section 3 — it isn't goodwill, it's a customer-acquisition mechanism, which is a fine reason to use it but a poor reason to skip evaluating alternatives.
2. Why On-Premises QRadar Is a Different Product Entirely
This is the most commonly misread fact in the whole announcement, so it's worth stating twice: the divestiture and the resulting EOL dates apply only to the SaaS product line. On-premises QRadar SIEM has its own release cadence, its own support lifecycle, and its own roadmap, none of which trace back to Palo Alto Networks.
IBM's QRadar Support Lifecycle page confirms 7.6.0 reached general availability on 30 June 2026 under a Support Cycle-5 policy: five years of standard support, a one-year critical-fix extension, and three further years of sustained support (5+1+3). A vendor doesn't publish a five-year lifecycle for a product it's retiring.
If your organisation runs QRadar on-premises today and has no SaaS components in the mix, this entire announcement is background context, not an action item. If you're on a hybrid estate — on-prem SIEM with a QRadar SaaS SOAR or EDR component — you have a narrower problem: migrate the SaaS piece, keep the SIEM.
3. Your Three Real Options
Option A: Free migration to Cortex XSIAM
IBM Consulting will migrate eligible QRadar SaaS clients to Cortex XSIAM "seamlessly and cost-free," per IBM's announcement, using migration automation tooling, pre-built accelerators and IBM's delivery teams (over 1,000 IBM consultants have been trained on Palo Alto's platform as part of this partnership).
What "cost-free" covers, in practice, is the migration service — not the ongoing Cortex XSIAM licensing, which is priced separately and on Palo Alto's commercial terms, typically consumption-based on data ingest and retention. Before committing, get a written total cost of ownership for at least a 24-month horizon, not just the migration line item.
This is the right default if: you're already invested in Palo Alto's ecosystem (NGFW, Prisma Cloud, Cortex XDR agents), your detection content is largely out-of-the-box rather than heavily customised, and you don't have a hard data-residency requirement that Cortex XSIAM can't currently satisfy in India (see section 4 — this is the one point in the decision tree we could not verify from public documentation, and it needs a direct answer from your Palo Alto account team before you sign).
Option B: Migrate to a different SIEM
The three vendors most commonly displacing QRadar SaaS deployments — per Gartner's 2025 Magic Quadrant for SIEM, which named Splunk (its eleventh consecutive year as a Leader), Microsoft, Google, Securonix and Exabeam as Leaders — are Splunk, Microsoft Sentinel and Google SecOps (built on the former Chronicle platform). We've compared QRadar against Splunk specifically in our QRadar vs Splunk guide, which remains a useful reference for that particular comparison.
The case for moving off the IBM/Palo Alto ecosystem entirely is strongest when: your organisation is already standardised on Microsoft (Sentinel's marginal cost drops sharply if you're already paying for Microsoft 365 E5 or Azure), you need confirmed India data residency today rather than "coming soon," or the QRadar SaaS relationship soured enough that you don't want to re-enter it one layer removed via Cortex XSIAM.
Option C: Retreat to on-premises QRadar
If your SaaS footprint is narrow — say, QRadar Suite SOAR on Cloud sitting alongside an on-prem QRadar SIEM you already operate — moving the SOAR workload on-premises rather than to a new SaaS vendor keeps your architecture in one place and avoids taking on a second vendor relationship mid-migration. This is a smaller project than a full platform migration, but it does mean provisioning and staffing SOAR infrastructure you previously consumed as a service. Our SIEM/IAM integration playbook covers the architecture patterns for a self-hosted stack if this is the direction you're evaluating.
4. The Data Residency Question for Indian Enterprises
CERT-In's Cybersecurity Directions of 28 April 2022 require, in direction (iv), that all service providers, intermediaries, data centres, body corporates and government organisations "mandatorily enable logs of all their ICT systems and maintain them securely for a rolling period of 180 days and the same shall be maintained within the Indian jurisdiction." That single clause should be the first filter applied to any SIEM alternative on your shortlist — not an afterthought once the platform decision is made.
Here is what we could verify directly from each vendor's own documentation at the time of writing:
| Platform | Confirmed India data residency | Source |
|---|---|---|
| QRadar on-premises | Full — you control physical location | N/A, self-hosted |
| Microsoft Sentinel | Yes — Central India, Jio India West, Jio India Central for the SIEM workspace; Central India also supported for the Sentinel data lake | Microsoft's geographical availability documentation |
| Google SecOps (Chronicle) | Yes — via Google Cloud's Mumbai (asia-south1) and Delhi NCR (asia-south2) regions | Google Cloud region documentation |
| Cortex XSIAM | Not confirmed from public documentation at time of writing | Confirm directly with Palo Alto Networks account team |
| Splunk Cloud Platform | Not confirmed from public documentation at time of writing | Confirm directly with Splunk account team |
The two confirmed rows aren't a recommendation — Sentinel and Google SecOps carry their own trade-offs in detection content maturity, licensing model and integration depth that matter as much as residency. But if your organisation is SEBI CSCRF-regulated (see our SEBI CSCRF compliance playbook for the broader framework) or otherwise cannot accept ambiguity on where log data physically sits, treat the two "not confirmed" rows as blocked until your vendor puts residency in writing, not as a detail to sort out during onboarding.
5. The Migration Risk Checklist
Every migration guide undersells the same three things. In order of how often they actually derail a timeline:
Detection logic doesn't port mechanically. Correlation rules, reference sets, offense logic and custom parsers were built against QRadar's data model. Moving them to Cortex XSIAM, Sentinel or Google SecOps means re-implementing detection logic against a different schema and query language, not exporting and importing a file. Budget for a rule-by-rule validation pass, not a bulk migration.
SOAR playbooks are typically incompatible across vendors. If you're also retiring QRadar Suite SOAR, every automated response playbook needs to be rebuilt in the destination platform's automation language. This is usually the single largest line item in migration effort estimates that vendors don't surface upfront.
Parallel running is not optional if you're under a log-retention obligation. CERT-In's 180-day requirement doesn't pause during a migration. Run source and destination platforms simultaneously, with verified event-count parity, until you're confident the new platform has fully absorbed the detection and retention workload — then decommission the old one. Cutting over on the EOL date itself, rather than well before it, is how retention gaps happen.
6. Timeline: What to Do Before Each Deadline
Now through Q4 2026 (before 14 April 2026): Inventory every QRadar SaaS product in your estate against the table in section 1. For anything on the April list — QRadar on Cloud, Cloud-Native SIEM, SOAR, Log Insights, Randori Recon — this is your active decision window. Request written confirmation from your chosen destination vendor on India data residency before signing anything.
Before 31 August 2026: If your estate includes QRadar Suite EDR, XDR, X-Force Threat Intelligence, Randori Attack or QRadar Advisor with Watson, you have a longer runway, but the underlying migration work (endpoint agent redeployment, threat intel feed reconfiguration) is not smaller — start the technical planning in parallel with the April-deadline items rather than sequentially.
Throughout: If your internal team doesn't have the bandwidth to run a SIEM migration alongside day-to-day SOC operations, a co-managed or fully managed SOC engagement during the transition is usually cheaper than the alternative of a rushed, understaffed cutover. This is a staffing and delivery-capacity question as much as a platform one — our staffing services team places exactly this kind of transitional SOC and SIEM engineering capacity.
Talk to a QRadar migration specialist
Conclusion
The single most damaging thing an Indian SOC team can do with this announcement is treat "QRadar is ending" as the headline. It isn't — the on-premises product has a fresh five-year lifecycle, and even within the SaaS line, IBM Consulting's free migration path to Cortex XSIAM means nobody is forced into an unplanned platform change with no support. What genuinely is forced is a decision, on a fixed timeline, and the decision quality depends entirely on how early you start the data residency and detection-logic homework rather than defaulting to the path IBM and Palo Alto have pre-built for you. For most regulated Indian enterprises, that homework — not the migration mechanics — is the actual project.
FAQ
Is IBM QRadar shutting down completely?
No. Only the SaaS products that IBM divested to Palo Alto Networks on 5 September 2024 are affected — QRadar on Cloud, QRadar Suite Cloud-Native SIEM, QRadar Suite SOAR, SOAR on Cloud, Randori Recon and QRadar Suite Log Insights end of life on 14 April 2026, and QRadar Suite EDR, XDR, X-Force Threat Intelligence, Randori Attack and QRadar Advisor with Watson end of life on 31 August 2026. IBM's on-premises QRadar SIEM was not part of the divestiture and continues to receive new releases and support.
What happens to my data if I do nothing before the deadline?
Palo Alto Networks' end-of-life policy means standard support, updates and, eventually, service access stop on the published date for each product. Exactly how long data remains retrievable after that point is a contractual detail that varies by agreement, not a fixed industry number — get it in writing from your account team rather than assuming a grace period. Waiting until the deadline to start extraction is the single most common way SOC teams lose historical detection content and case history.
Do I have to move to Cortex XSIAM?
No. IBM Consulting offers a no-cost migration path to Cortex XSIAM for eligible QRadar SaaS customers, which is the path of least resistance if you want to stay inside the IBM–Palo Alto partnership. But it is one option among several: moving to on-premises QRadar, migrating to a different SIEM entirely (Splunk, Microsoft Sentinel, Google SecOps), or adopting a co-managed SOC model are all legitimate alternatives depending on your data residency, budget and staffing constraints.
Does this affect CERT-In's 180-day log retention requirement?
It can, if the migration is rushed. CERT-In's 28 April 2022 direction requires that logs of all ICT systems be retained for a rolling 180 days within Indian jurisdiction. A forced SIEM migration under a hard vendor deadline is exactly the kind of event that creates retention gaps — if the export from the old platform and the ingestion into the new one aren't run in parallel with verified overlap, you can end up with a period where logs exist on neither system in a compliant, queryable form.
Which SIEM alternatives actually support Indian data residency today?
Confirmed, vendor-documented options: Microsoft Sentinel supports Central India, Jio India West and Jio India Central for the SIEM workspace, with Central India also supported for the Sentinel data lake. Google SecOps (built on Chronicle) supports India data residency through Google Cloud's Mumbai (asia-south1) and Delhi NCR (asia-south2) regions. For Splunk Cloud Platform and Cortex XSIAM, current India-region availability should be confirmed directly with the vendor at contracting time — the public documentation on both is less specific than Microsoft's and Google's on this point.
Is on-premises QRadar still a viable choice in 2026?
Yes, and it is unaffected by this divestiture. IBM shipped QRadar 7.6.0 on 30 June 2026 under a five-year support lifecycle (5+1+3: five years standard, one year critical-fix extension, three years sustained). For organisations where data residency is non-negotiable — most SEBI CSCRF-regulated entities fall in this category — on-premises QRadar removes the data-residency question entirely, at the cost of owning the infrastructure and staffing yourself.
How long does a SIEM migration actually take?
Longer than the vendor timeline suggests. Detection logic has to be rebuilt and validated rule by rule, not just exported — correlation rules, reference sets and offense logic rarely translate mechanically between platforms. SOAR playbooks are typically incompatible across vendors and need to be rewritten. Most teams run source and destination platforms in parallel for weeks to months to validate parity before decommissioning the old one, which means starting well before the EOL date, not on it.
About the Author
Saurabh Pande is the Co-Founder of Cyberaube Technologies. He has 13+ years of experience across IBM Security, CyberArk and QRadar implementations, and has personally interviewed and placed 2,500+ cybersecurity professionals across Indian enterprises. He advises BFSI organizations on SIEM, IAM and SOC transformation programs.
About Cyberaube
Cyberaube Technologies is an Indian cybersecurity staffing, managed SOC and compliance firm. We provide contract and permanent staffing for SOC, SIEM, IAM and GRC roles, 24/7 managed security services, and consulting for SIEM, IAM and data protection programs — with hands-on expertise across QRadar, Splunk, ArcSight, CyberArk, Okta and SailPoint.