The honest answer is "it depends", but the dependencies are not what the vendor pitch suggests
Three enterprises moved off Splunk to Palo Alto Cortex XSIAM with us as the migration partner over the past year. Two were full migrations; one was a parallel deployment with eventual decommissioning of the Splunk environment. Across the three, the decision framework that actually predicted the migration outcome was different from the framework Palo Alto's sales engineering team led with.
The vendor pitch focuses on AI-driven detection, unified data ingestion and the consolidation of XDR plus SIEM into a single platform. All real, all valuable. None of them is the dependency that decides whether the migration is worth running. The dependencies that actually matter are operational and commercial, not technical. This piece walks through the framework we use now, what the three migrations produced, and where Splunk (or another legacy SIEM) is still genuinely the right answer in 2026.
What XSIAM actually does differently
Cortex XSIAM is Palo Alto's next-generation SOC platform. It combines XDR (endpoint detection and response, network analysis, identity threat detection), SIEM (log ingestion, correlation, search), SOAR (automation and response orchestration) and threat intelligence into a single platform with a single data model.
The architectural difference from Splunk is that XSIAM is purpose-built for security analytics whereas Splunk is a general-purpose data platform with a security application layered on top (Enterprise Security). The implications of this design choice cascade through the operating model in ways that are hard to appreciate until you have run both platforms in production.
Three specific differences that consistently matter in practice.
One. XSIAM data ingestion is structured against a security-specific schema. Logs come in, get parsed against the schema, and become queryable against entity-centric models (user, host, file, network connection). Splunk ingests data as semi-structured text and relies on search-time field extraction. The XSIAM model is more constrained but produces faster and more consistent analytic results across diverse log sources.
Two. XSIAM correlations are largely vendor-curated and machine-learning-augmented. Customers add detection content on top, but the baseline detection library is substantially deeper out of the box than Splunk Enterprise Security's out-of-box content. The trade-off is less customisation flexibility at the very top end.
Three. XSIAM is consumption-priced primarily against endpoints, identities and ingested data with a different pricing curve than Splunk's ingest-volume model. The economic implications change at the margin for enterprises with high log volumes and modest endpoint counts versus enterprises with the inverse profile.
The framework that actually predicts migration success
Five dimensions matter more than the feature comparison. We apply them in order during migration assessment.
Dimension 1: How heavy is your existing Splunk customisation?
Splunk customers fall into two broad camps. Light customisers run Splunk Enterprise Security with mostly vendor content, maybe a handful of custom detections, and a Splunk Cloud or Splunk Enterprise deployment that is operated rather than tuned. Heavy customisers have years of custom SPL queries, bespoke detection content, integrated dashboards and Splunk-as-a-data-platform workloads beyond security.
For light customisers the migration is straightforward. Most of what they run can be reproduced in XSIAM with the vendor-curated content plus a small body of custom detection rules ported across. Migration timeline 3 to 6 months for a mid-market enterprise.
For heavy customisers the migration is harder. Years of SPL-based custom content does not have a one-to-one mapping into XSIAM's query language. Some content is genuinely lost in translation; some is rebuilt against XSIAM's structured model and the rebuild is sometimes better than the original; some is kept by running Splunk and XSIAM in parallel for an extended transition window. Migration timeline 9 to 18 months for a heavy-customisation estate.
The heavy-customisation conversation is where most XSIAM migrations stall. The migration cost is high. The eventual operating-cost improvement is real but distant. Light customisers should usually migrate. Heavy customisers should do the math twice before committing.
Dimension 2: Are you already running Cortex XDR on endpoints?
If you are already running Palo Alto Cortex XDR for endpoint protection, XSIAM is a substantially smaller migration. The endpoint telemetry already flows to the Cortex backend. The data model is already familiar to the SOC team. The integration with the Palo Alto network and identity products is already established.
If you are running CrowdStrike, SentinelOne or Microsoft Defender for Endpoint, the migration to XSIAM means moving SIEM but keeping the existing EDR. XSIAM ingests data from other EDR vendors, but the deeper integration value that justifies the migration is reduced. For enterprises in this profile, the right answer is often "stay on Splunk for SIEM, keep your existing EDR, evaluate XSIAM at the next major refresh cycle".
Dimension 3: What is your data ingestion profile?
XSIAM is consumption-priced primarily against endpoints and identities, with a separate dimension for ingested data above the inclusive volumes. Splunk is priced primarily against ingest volume.
For enterprises with high log ingest volumes (hundreds of GB per day) and modest endpoint counts, XSIAM is economically attractive. The high ingest volume costs more on Splunk than on XSIAM. For enterprises with very large endpoint counts (tens of thousands) and modest log ingest, the economics are closer or sometimes favour Splunk.
Model the five-year total cost of ownership before signing. The vendor sales engineer will help with this; insist on a model that uses your actual log volumes and endpoint counts, not the vendor's assumed mid-market profile.
Dimension 4: How structured is your SOC operating model?
XSIAM is opinionated software. It expects the SOC to operate against vendor-curated content with customer-specific additions on top. Splunk is permissive software. It expects the SOC to build whatever detection content makes sense for the environment.
Mature SOCs that have invested heavily in detection engineering sometimes find XSIAM constraining. The vendor-curated baseline is good but not always good enough for environments with sector-specific threat profiles. The customisation surface in XSIAM has improved through 2025 and continues to expand, but the operating philosophy is different from Splunk.
Less mature SOCs that operate primarily against vendor content benefit substantially from the XSIAM baseline being deeper. The shift from "we need to build all our own detection" to "we tune the vendor baseline and add customer-specific overlays" is the right direction for most enterprises.
Dimension 5: Your wider Palo Alto footprint
Enterprises already running Palo Alto firewalls, Prisma Access, Prisma Cloud or Cortex XDR have a stronger XSIAM business case than enterprises with no other Palo Alto footprint. The integration between Palo Alto products on the same platform is genuinely deep, shared threat intelligence, shared identity model, shared automation flows.
Enterprises with no Palo Alto footprint can still run XSIAM as a standalone SOC platform, but the integration value that justifies the migration is reduced. For pure best-of-breed environments, the case for XSIAM specifically (versus Microsoft Sentinel, Google Chronicle or staying on Splunk) is competitive rather than clear.
What the three migrations actually delivered
The honest outcomes from the three enterprises we migrated.
Migration one. UAE financial services firm with moderate Splunk customisation, existing CrowdStrike EDR, 4,000 endpoints, around 200 GB per day ingest. Migration timeline eight months. Mean time to detect on phishing-pivoted credential attacks dropped from around 4 hours under Splunk Enterprise Security to around 45 minutes under XSIAM. Five-year TCO model showed roughly 20 percent savings versus continuing on Splunk Cloud. The migration was worth running.
Migration two. UAE government-adjacent entity with light Splunk customisation, existing Cortex XDR, 2,000 endpoints, modest ingest. Migration timeline four months. Operating-model improvement was substantial. The SOC team's daily workload compressed because XSIAM's vendor-curated content covered scenarios the previous Splunk deployment had not. Five-year TCO model showed roughly 30 percent savings. The migration was an easy win.
Migration three. UAE enterprise with heavy Splunk customisation, mixed EDR estate (CrowdStrike plus Microsoft Defender), 12,000 endpoints, high log ingest. Migration timeline 14 months and is still running through the long tail of custom-content rebuild. The migration is producing operational value but the rebuild cost is substantial. We have advised similar profiles since to evaluate carefully before committing.
When Splunk is still the right answer in 2026
Three profiles where we have advised clients to stay on Splunk rather than migrate.
Heavy customisation with no clear pain point. If the existing Splunk Enterprise Security deployment is operating well and the SOC team is producing strong detection outcomes from years of investment in custom content, the migration cost is unlikely to be recovered for several years. Stay on Splunk; evaluate again at the next major refresh.
Splunk-as-a-data-platform beyond security. Enterprises using Splunk for application logs, business analytics and operational intelligence alongside security are running a different platform than XSIAM is built to replace. XSIAM is a security platform. Migrating only the security workload while keeping the broader Splunk deployment for the non-security use cases is sometimes the right answer but often produces an operating-model complexity that exceeds the benefit.
Microsoft 365 E5-anchored estates with Sentinel as the obvious alternative. For enterprises already deeply invested in Microsoft 365 E5 with Microsoft Sentinel as the SIEM, the migration target should be Sentinel rather than XSIAM. The Microsoft integration is materially better than the third-party integration with any other Microsoft tooling.
UAE context: XSIAM in the regional market
Palo Alto Cortex XSIAM has gained substantial market share in the UAE enterprise market over the past two years, particularly in the banking, federal and large-enterprise segments. The Palo Alto regional team has invested heavily in the market and the partner ecosystem has matured.
For UAE banks operating against sector regulation requirements, XSIAM's out-of-box content includes a meaningful set of detections aligned with the banking-sector threat profile. For federal entities under NESA / UAE IAS, the audit-logging and evidence-handling characteristics work cleanly against the framework requirements. These are not unique to XSIAM, but they are operationally adequate.
For UAE healthcare, hospitality, retail and the broader enterprise segment, the XSIAM case is similar to the global one, depends on the dimensions above more than on UAE specifics.
The migration playbook in summary
For enterprises considering the move, the playbook we apply.
Week 1 to 4: assessment. Score current Splunk deployment against the five dimensions. Build the five-year TCO model. Document the custom content inventory. Decide go or no-go before incurring migration cost.
Month 2 to 4: parallel build. Stand up XSIAM alongside the existing Splunk environment. Port the highest-value content first. Run both systems in parallel for the critical detection scenarios.
Month 4 to 8: parallel operation and content rebuild. SOC team works against both platforms with the priority detections live on XSIAM. Custom content from Splunk gets rebuilt, retired or migrated to manual workflows as appropriate.
Month 8 to 10: cutover and Splunk decommissioning. Primary detection operations move fully to XSIAM. Splunk transitions to historical-data-only retention or full decommissioning depending on the data-platform-use-beyond-security question.
Bottom line
XSIAM is a meaningful improvement over legacy SIEM for a measurable subset of enterprises. The subset is defined by existing customisation depth, EDR vendor alignment, ingestion profile, SOC operating-model maturity and broader Palo Alto footprint. None of those dimensions appear on the vendor feature matrix.
For light Splunk customisers with existing Cortex XDR or substantial Palo Alto estate, XSIAM is usually the right answer. For heavy Splunk customisers with mature detection engineering, the migration cost frequently exceeds the operating-cost improvement. For Microsoft-anchored estates, Microsoft Sentinel is usually the better target than XSIAM.
The vendor pitch about AI-driven detection is real but secondary. The dimensions above are what actually predict whether the migration is worth running.
