Shuffle → Palo Alto XSOAR
Shuffle ↔ Palo Alto XSOAR: integration to migration path.
Your SOAR is load-bearing — playbooks, indicator lifecycle and War Room transcripts are stateful, so a big-bang cutover is never an option. Shuffle deploys alongside XSOAR first, shadow-running the same playbooks against real production traffic, then takes over one cohort at a time with a measured parity gate at every step — no flag day, no forced re-credentialing, and a revert in minutes.
The honest exceptions are the genuinely SaaS-only surfaces — TIM push-to-enforcement, the War Room artifact and bidirectional mirroring — which we substitute deliberately rather than pretend are free. We say so up front, because the rest of this only matters if you can trust it.
The idea
Run in shadow first. Retire XSOAR last.
The topology that makes this zero-downtime: your SIEM dual-routes the same notable to both XSOAR and Shuffle in parallel. XSOAR keeps owning the analyst console, TIM, War Room and mirroring while every Shuffle workflow runs in shadow mode against real traffic, ending each run with a parity verdict scored over thirty days. Acting steps stay log-only until the numbers earn promotion — so Shuffle proves itself on production alerts before a single analyst depends on it, then takes the cohort over, then the next, each reversible in minutes.
The phases
Seven steps. Each one reversible.
Baseline & inventory
We mine your live XSOAR over read-only APIs to catalogue every playbook, Integration, Script, incident type, indicator type, mirror config and War Room command in use, then tag each by blast radius. XSOAR keeps running untouched.
Stand up Shuffle alongside XSOAR
Shuffle deploys in HA next to XSOAR and the top SIEM/EDR sources dual-route the same alerts to both. Shuffle runs only the alert-normalise workflow with severity mapping pinned — no investigation steps, no acting.
Shadow-run the low-blast-radius cohort
The ten lowest-risk playbooks are hand-ported to Shuffle and run in shadow against every matching incident, with all acting steps logged-only. Analysts still act on XSOAR; Shuffle output writes to a parity table scored over 30 days.
Promote Shuffle to acting SOAR
For the soaked cohort we enable Shuffle's acting steps, rename the XSOAR playbook to a legacy passthrough placeholder, and route War Room notes into an indexed Slack/Teams thread. Analysts now work in Shuffle for that cohort, XSOAR for everything else.
Promote remaining cohorts in waves
Medium- and high-blast-radius playbooks promote in two further waves, each soaked thirty days in shadow then thirty acting. Destructive actions gate behind an SSO-fronted approver check, and indicator enforcement moves to MISP plus per-target push workflows.
Cut over War Room and indicator lifecycle
New incidents stop creating XSOAR War Rooms — investigation moves to per-incident Slack/Teams threads with scheduled transcript export to immutable storage, and MISP becomes the indicator source of truth with XSOAR TIM read-only.
Retire XSOAR
XSOAR holds read-only for a 30 to 60 day evidence window while we reissue mirror and TIM feeds from Shuffle and MISP, then export the full incident and transcript corpus to an immutable archive. After the window the tenant is cancelled.
Feature parity
Where Shuffle matches XSOAR, and where it does not.
| Capability | Shuffle | Palo Alto XSOAR | Parity |
|---|---|---|---|
| Playbook / workflow authoring | Shuffle Workflows (visual editor over JSON) | XSOAR Playbooks (visual editor over YAML) | At parity |
| Integration / connector catalogue | Shuffle Apps (OpenAPI-derived, ~5,000 community) | XSOAR Content Pack Integrations (~900 packs) | Partial |
| Custom script runtime | Docker Python actions (no JS) | Automation Scripts (JS + Python via demisto-sdk) | Partial |
| Alert ingestion | Per-workflow webhook trigger with signed secret | fetch-incidents plus generic webhook | At parity |
| Threat-intel module | None native — MISP plus Shuffle workflows | XSOAR TIM (TAXII ingest, score / expire, push-to-enforcement) | SaaS only |
| Incident mirroring | One-way comment push plus webhook-back (hand-built) | XSOAR Mirroring (bidirectional, conflict resolution) | SaaS only |
| Collaboration / War Room | Slack/Teams thread plus transcript export (substitute) | XSOAR War Room (inline commands, exportable transcript) | SaaS only |
| PAP (Permissible Actions Protocol) | No first-class PAP — explicit pap-red workflow gate | Tag / conditional convention; no first-class PAP either | Partial |
| Approval / collaboration gate | User-input node plus SSO-fronted role check | Ask / collection task with named approver role | Partial |
| RBAC plus multi-tenant | First-class Orgs plus Environments (included) | Multi-Tenant Server (separate SKU) | At parity |
| Credential vault | Built-in store; externalise to Vault / OpenBao / Secrets Manager | Vendor-managed vault (RBAC, rotation, BYOK) | SaaS only |
| Deployment & HA | Self-hosted: 2+ backend nodes, Postgres, Orborus pool | Vendor-managed (XSOAR 8 SaaS) / Server self-host | Partial |
| Cost model | Self-hosted compute; CE free, Cloud / Enterprise commercial | Per-tenant licence; TIM / Mirroring tier-gated | Partial |
| Compliance (SOC 2) | Self-operated boundary (you own controls) | Vendor-operated SOC 2 boundary | SaaS only |
What we're honest about
The SaaS-only gaps we name, not hide.
TIM push-to-enforcement has no OSS parity
XSOAR's Threat Intel Module ingests TAXII, scores and expires indicators, then pushes them straight to enforcement — PAN-OS EDLs, CrowdStrike Custom IOC, EDR allow/blocklists. MISP recovers roughly 60 per cent of that (ingest, dedupe, share), but every push-to-enforcement target becomes its own Shuffle workflow with its own rollback. It is a sustained workstream, not a one-shot port.
War Room and incident mirroring don't port like-for-like
XSOAR's War Room — inline commands plus an exportable transcript as evidence — and its bidirectional mirroring with ServiceNow or Jira are best-in-class SaaS surfaces with no OSS equivalent. We substitute Slack/Teams threads with transcript export, and a one-way comment push plus webhook-back. We document to your auditors and ITSM owners that edit-either-side-both-update is no longer the model.
Shuffle runs no JavaScript and has a thinner approver gate
Shuffle executes Docker Python actions only, so every XSOAR JavaScript automation is rewritten from scratch, and its User-input node is whoever clicks unless you front it with SSO. We inventory JS in Phase 0 and wire approver gates through Keycloak, Okta or Azure AD with a role check before any destructive step — but these are deliberate engineering, not free parity.
Self-hosting moves the vault, uptime and SOC 2 boundary to you
XSOAR's vendor-managed vault and vendor-operated SOC 2 boundary become your responsibility: credentials externalise to Vault, OpenBao or Secrets Manager, and Shuffle being down means promoted playbooks halt with no managed backstop. That is exactly why we run it managed — HA backend nodes, Postgres replication, Orborus autoscale, a break-glass path and a tested DR runbook with an RTO target.
Why this beats a flag day
Reversible per phase, soak-gated before cancellation.
Every phase reverts in under 15 minutes — disable a webhook, flip acting_mode back to shadow, restore
the legacy XSOAR tag — because XSOAR stays live and authoritative until each cohort has earned its place. No playbook
promotes without a 30-day shadow soak at 98 per cent verdict-match, and no cohort acts without a further 30-day soak;
XSOAR's contract is only cancelled after the final 30-to-60-day read-only evidence window closes with the export-of-record
verified. You are never betting the SOC on one cutover.
See whether your SOAR migrates cleanly.
A working session with a senior detection-and-response engineer. We inventory your XSOAR playbooks, Scripts, mirrors and TIM enforcement targets, mark the cohorts that shadow cleanly and the SaaS-only surfaces that need substitutes, and tell you honestly what the Shuffle path looks like for your environment — before you commit to anything.
Map my migration →