Cortex XSOAR or Shuffle: which fits a SOC that is weighing a switch
Cortex XSOAR fits a SOC that wants analyst case work, vendor-maintained content and a supported product in one place, whether that is the on-premises build or the SaaS edition of Cortex XSOAR 8. Shuffle fits a team that wants to self-host the automation layer, pay on app runs rather than per seat, and is comfortable owning integrations, upgrades and scaling itself. If your trigger is a renewal, a licensing change, a data residency rule or lock-in, the question is less about which tool is more capable and more about whether you need incidents, layouts and a war room inside the same product. Shuffle does not provide those, so they must be designed and hosted elsewhere before a switch makes sense.
Cortex XSOAR is the stronger choice when analysts work their queue inside the platform and you rely on packaged integrations and vendor-supported updates. Its on-premises option is installed through a terminal installer, and Cortex XSOAR 8 is also offered as SaaS, so residency and operating model can be chosen separately. Shuffle is the stronger choice when the main job is automation: enrichment, containment and routine tasks triggered from a SIEM or ticketing system. Its app creator builds integrations from OpenAPI specifications, its license is priced on app runs, and it documents Docker, Docker Swarm and Kubernetes deployments. Confirm current licensing terms and supported deployment options with each vendor before you rely on them.
The decision turns on three questions. First, where will cases live: in the automation tool, or in a separate case system that Shuffle would feed? Second, who will build and maintain integrations, and do you have staff who can write OpenAPI-based apps or Python apps for the tools you use every day? Third, what infrastructure will your team run, including an OpenSearch cluster, redundant Orborus nodes and a managed encryption secret for stored credentials, and who is on call when it fails. Answer these before you compare prices, because the cost of a switch sits mostly in the case workflow and the integration effort, not in the license.
Which option fits which scenario
This table matches common Cortex XSOAR and Shuffle scenarios to the platform that fits better and notes where Shuffle needs a case system beside it. Read each row against your own case volume, connectivity and team skills, since the better fit can change with those factors.
| Scenario | Better fit | Reason and what to pair with Shuffle |
|---|---|---|
| Heavy analyst case work with layouts and a war room | Cortex XSOAR | XSOAR bundles incidents, layouts and the war room. Shuffle has no built-in incident layouts or war room, so plan a separate case system and map incident fields and analyst notes to it. |
| Mostly automated enrichment and containment | Shuffle | Playbook-style enrichment and containment map well to Shuffle workflows and app runs. Confirm the app-run volume against the pricing article before committing. |
| Air-gapped or disconnected sites | Shuffle, if you can load apps offline | Shuffle runs on Docker or Kubernetes without internet access, but app images and updates must be staged in advance. Confirm the offline app loading steps with DeployOpen and the vendor before relying on them. |
| Data residency with no SaaS allowed | Shuffle self-hosted | Shuffle runs entirely in your own infrastructure, so do not use the hosted Shuffle Cloud option. XSOAR 8 SaaS is out of scope for this requirement, and XSOAR 8 on premises is the commercial route to compare. |
| Small teams without developers | Depends on the integrations needed | Shuffle's App Creator builds apps from OpenAPI specifications, which reduces coding, but custom Python apps still need someone to maintain them. Confirm integration coverage for your tools first. |
| Teams already running OpenSearch | Shuffle | Shuffle uses OpenSearch as its database, so existing OpenSearch skills and monitoring carry over. Plan for the cluster sizing and high availability settings in the configuration docs. |
| Need for shared, long-term case history across teams | Cortex XSOAR, or Shuffle plus a case system | Shuffle execution data lives in its own store, so audit and case history requirements must be designed in. Confirm retention and export needs with your compliance owner. |
Where the data lives under each option
Each option stores incident data, playbook content and saved app credentials in a different place, and that placement decides who can read them and who must be trusted with them. The cards below cover the hosting choices, identity controls, the encryption secret and the storage layer that Shuffle requires you to run yourself.
Cortex XSOAR 8 SaaS hosting
With XSOAR 8 as SaaS, Palo Alto Networks hosts the platform, so incident records, playbook run data and integration credentials sit in a vendor-operated environment. Ask the vendor where that environment is located, which regions and sub-processors handle data, how tenants are isolated, and what the contract says about retention and deletion at exit. Your compliance team will need these answers before any regulated case data is loaded.
XSOAR 6 and 8 on premises
On-premises XSOAR keeps incident data, playbooks and credentials on servers you operate, and the on-premises version of XSOAR 8 is installed through a terminal installer. You become responsible for database backups, patching, network segmentation and access to the host. Confirm with Palo Alto Networks which XSOAR release fits your sites, and confirm any support dates before you commit to a version.
Shuffle on Docker or Kubernetes
Self-hosted Shuffle runs on Docker or Kubernetes inside your own accounts or data centers, and the install guide states a minimum of 4 GB of RAM. Every workflow record, execution result and stored credential stays in the environment you run, which keeps data residency under your control. The cost is operating the stack yourself, including the frontend, the Go backend on port 5001, Orborus and the OpenSearch database.
shuffler.io hosted versus self-hosted
The hosted service at shuffler.io removes the server work, but workflow data and app runs then live in a service you do not operate. The architecture docs describe a hybrid model in which Shuffle Cloud is paired with a local Orborus that needs no inbound firewall ports, so execution can stay inside your network. Ask which data stays local in that model, and whether the backend and OpenSearch are in scope for your data residency requirement.
Identity and per-tenant SSO
Shuffle added SAML single sign-on in version 0.9.16 and OpenID Connect in 1.0.0, and both are available on premises and in the cloud. Per-tenant SSO enforcement lets you require federated login for each tenant, and SAML is being deprecated on Shuffle Cloud in favor of OpenID Connect. Map which identity provider issues analyst accounts, confirm that local admin accounts are restricted, and plan for the SAML to OpenID Connect move if you use the cloud service.
Key custody for the encryption modifier
Shuffle encrypts saved app credentials and API keys in OpenSearch with AES-256 using the SHUFFLE_ENCRYPTION_MODIFIER secret. Losing or changing that value breaks every saved app authentication, so the secret must be stored in a vault, backed up with a documented recovery path and rotated only through a planned procedure. Decide who holds this key, how it is injected into the containers, and who can read it, because anyone with the secret and the database can decrypt stored credentials.
OpenSearch storage and residency
Shuffle uses OpenSearch as its document database, and the high availability guidance recommends an OpenSearch cluster with NFS for shared files when several backends run. Those volumes hold workflow history, execution results and encrypted credentials, so backup, snapshot location, retention and disk encryption all fall to your team. Confirm where snapshots are written, how long execution data is kept and who can query the indices directly.
Compliance readiness work
Preparing for an assessment means documenting where each data category sits, who can access it, how keys are rotated and how backups are restored, then collecting evidence that these controls run. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports or certifications, which independent auditors and certification bodies provide. Ask your assessor which evidence they expect for SaaS versus self-hosted data flows before scoping the work.
How Shuffle licensing differs from XSOAR licensing
Shuffle's licensing splits by component, and the split matters for legal review. The backend is licensed under the AGPL-3.0, while its workflows, documentation, apps and app specifications are under the MIT license. Your team can therefore build and share workflows and apps under permissive terms, but if you modify the Shuffle backend and make it available to users over a network, the AGPL's source-sharing duties may apply to those changes. Ask your counsel to review this before you fork the backend or embed it in a service you offer to other organizations. Cortex XSOAR is licensed under a commercial agreement with Palo Alto Networks, so its terms govern what you may modify, host and share.
Shuffle's paid licensing uses one metric: app runs. An app run is an action that actually executes in a workflow. Triggers and skipped actions are not counted, and users, apps and workflows are unlimited. The cost driver is therefore execution volume, so a playbook that polls a SIEM every minute or enriches every alert with several lookups will generate far more runs than one triggered by a few escalations a day. Before any quote, pull run counts from your current XSOAR playbooks, identify the loops and enrichment steps that repeat, and give the vendor those numbers so the price reflects your real volume. Confirm current pricing and the definition of an app run in Shuffle's pricing article.
Shuffle says all features are available in its open-source edition, and that its paid tiers differ in feature limits, scaling and support. Since v2.1.1, the limits between the open-source and enterprise editions are actively enforced. Read the limits in the configuration documentation against your planned scale, including the number of executions, scaling and high availability, before you commit to a self-hosted design. For XSOAR, subscription terms, renewal conditions, support levels and what is included in an on-premises versus SaaS deployment are set in your contract. Ask Palo Alto Networks for the current written terms, the license metric and renewal provisions in writing, and have them confirmed against the version you actually run.
Who runs Shuffle and what keeps it highly available
Running Shuffle means your team owns the stack end to end: the frontend, the Go backend API, the OpenSearch document database, the Orborus runtime and the app containers that actions execute in. The install guide sets a minimum of 4 GB of RAM and states that the default Docker Compose setup is not a scalable build without changes. Treat the Compose file as a single-server starting point for a lab or pilot, then decide early whether production will run on Docker Swarm or Kubernetes with Helm charts. Those are the two layouts the architecture docs describe for multi-server operation, and the choice drives who on your side must understand orchestration.
High availability is where the operating load sits. The configuration docs recommend an OpenSearch cluster rather than a single node, optional Memcached for a shared cache, and NFS for shared files when several backends run. They also recommend scaling the backend and frontend across servers and running more than one Orborus node, so workflows keep executing if one runtime fails. Each of these is a component your team patches, monitors, backs up and restores, and the docs warn that losing or changing the SHUFFLE_ENCRYPTION_MODIFIER value breaks every saved app authentication, so key custody belongs in the runbook from day one.
Upkeep also covers the apps. Shuffle apps run as versioned Docker containers, built in the App Creator from OpenAPI specifications or written in Python with the app SDK, so each vendor API change, credential rotation or SDK update becomes work your engineers schedule and test. Compare that with XSOAR 8, where Palo Alto Networks operates the SaaS option, or with the on-premises XSOAR installer, which uses a terminal-based setup and a vendor upgrade path. Ask Palo Alto Networks or your partner which of these maintenance tasks would move to a vendor, and ask DeployOpen for a written scope that names which of the high availability components and app maintenance it would own.
What each option costs to own, by component
Cost of ownership for Cortex XSOAR and Shuffle splits into licensing, infrastructure, integration work and staffing, and each part is one-time or recurring. The cards below name who gets paid for each component, what pushes it up or down, and what to ask for in a written quote before comparing totals.
XSOAR subscription and renewal
Cortex XSOAR is a commercial product, so the license is the recurring line that most often drives the comparison. Ask the vendor or reseller to split the quote into the base license, any per-integration or content entitlements, support tier, and the renewal uplift for years two and later. Confirm which deployment you are buying, since XSOAR 8 is offered as SaaS or on premises, and whether the on-premises option is licensed separately from the SaaS subscription. Ask what happens to the term if you move workloads out before renewal.
Shuffle licensing and app runs
Shuffle's open-source edition includes all features, so the self-hosted server carries no per-user or per-workflow license cost. Its paid tiers differ in limits, scaling and support, and those limits have been enforced since v2.1.1. Shuffle's paid licensing is metered on app runs, meaning actions that execute in a workflow, while triggers and skipped actions are not counted. Ask whether your expected run volume stays within the open-source limits or needs a paid tier, and get the app-run metering stated in writing with a sample calculation based on your own playbooks.
Servers and HA design
Self-hosted Shuffle is a recurring infrastructure cost you pay to your cloud or data center provider. Shuffle needs at least 4 GB of RAM per the install guide, but the default Docker Compose setup is not scalable without changes. High availability in the Shuffle docs means an OpenSearch cluster, a shared cache, shared file storage for several backends, and more than one Orborus node. Each of those adds hosts and operations time. XSOAR on premises has its own server sizing, and its SaaS option moves hosting into Palo Alto Networks' subscription. Ask each vendor for sizing guidance matched to your run volume and redundancy target.
OpenSearch storage and retention
Shuffle stores workflow data, execution records and saved app credentials in OpenSearch, which is a recurring storage line that grows with execution history. Storage cost depends on how many executions you keep, how long you retain them, and whether you run a clustered OpenSearch for high availability. Budget for backups and snapshot storage too. Confirm the retention setting you need for audit, and test how quickly the index grows at your run volume before you size disks. Protect the SHUFFLE_ENCRYPTION_MODIFIER secret as part of this same operational setup, because losing it breaks saved app authentications.
Orborus nodes and runtime capacity
Orborus is the Shuffle runtime component that polls the backend for jobs and starts a worker for each workflow execution, which then starts app containers. Capacity is a function of how many executions run in parallel and how many Orborus nodes you deploy for failover. Each node is a recurring compute cost, and the count rises with peak concurrency and with the resilience you require. Ask for a load estimate based on your highest-volume playbooks, and check whether your container hosts need inbound ports open or can use the hybrid model with a local Orborus.
Integration development and maintenance
This is the largest variable cost in most automation projects, and it is mostly staff time rather than licenses. Migrating XSOAR playbooks means rebuilding integrations as Shuffle apps, either by generating them from OpenAPI specifications in the App Creator or writing them in Python with the app SDK. Each app then needs versioning, credential rotation and updates when vendor APIs change. Count the integrations you actually call, mark the ones with no OpenAPI definition, and estimate build hours per integration. Ask any implementation partner for a fixed-scope quote that lists each integration separately.
Case management and analyst tooling
Shuffle does not ship incident layouts or a war room, so a SOC that uses XSOAR as its case system needs a separate case tool. That tool may be a commercial product with its own license, or an open-source system that you must host, back up and integrate. Also count the cost of mapping incident fields, SLAs and analyst notes into the new system. Confirm whether your current XSOAR license includes case features you would lose, and ask any vendor or partner to price case management as its own line item.
Staff, support and upgrades
Staff time recurs for both options, but the mix differs. XSOAR shifts most platform operations to the vendor under a support contract, while self-hosted Shuffle leaves upgrades, patching, backups and on-call response with your team or a retained partner. Shuffle upgrades follow release tags, and you must test each one against your apps. Ask whether support is included, the response commitments, and whether a retainer for upgrades and continuous testing is cheaper than in-house coverage at your size. Compare the full-time equivalent effort for each option across a full year, not only the first build.
What a move from Cortex XSOAR to Shuffle involves
The sequence turns XSOAR playbooks, integrations and incident logic into Shuffle workflows and apps, with a named case system and a parallel run per use case. Each step ends with an output you can check before the next one starts.
Inventory playbooks, integrations and triggers
Your security engineers list every playbook, script, integration instance and incident type in the XSOAR server, and note which SIEM or ticketing source starts each one. Mark which items are JavaScript integrations, which call XSOAR-specific runtime features, and which are unused. The output is a signed-off inventory with an owner and a use case for each row, which becomes the basis for every later step.
Export custom content from XSOAR
An administrator exports the content from the XSOAR 8 interface under Settings, Server Settings, Custom content, using Export all custom content, and downloads individual playbooks from the content item menu. For XSOAR 6 sites, confirm the export path with your Palo Alto Networks representative or the 6.x documentation for your version. Store the archives in version control with a checksum, and record which items did not export cleanly. The check is that every inventory row has a matching exported file.
Classify what carries over and what must be rewritten
Security engineers sort the exported content into three groups: playbook logic that is mostly orchestration and can be redrawn as Shuffle workflows, integrations that call an API and can be rebuilt as apps, and code that depends on XSOAR's runtime, such as JavaScript integrations and logic tied to its war room or incident fields. Treat the third group as a redesign rather than a copy. The output is a migration backlog ranked by business value, with the runtime-bound items marked for redesign.
Rebuild integrations as Shuffle apps
Developers create apps in Shuffle's App Creator from the vendor's OpenAPI specification where one exists, or write Python apps with the Shuffle app SDK where the API needs custom handling. Each app is published as a versioned Docker container and tested against a non-production tenant with the same credentials scope. Confirm with each vendor that the API specification and the account permissions you need are available before you start. The check is a passing test run of each app's core actions against the test system.
Re-create incident triggers from the SIEM
Platform engineers point the SIEM, EDR or ticketing system at Shuffle's webhook triggers, then map the fields that XSOAR previously received into the workflow inputs. Shuffle does not provide XSOAR-style incident layouts, so define the fields and their validation in the workflow itself. The check is that a test alert from each source starts the expected workflow and carries every field the playbook reads.
Define the case system before cutover
Because Shuffle has no built-in incident layouts or war room, the SOC decides where analysts record case notes, status, owners and SLAs. Options include a separate case management system or a ticketing tool, with Shuffle handling only the automation. Write down the field mapping from each XSOAR incident type to the chosen system, and confirm that analyst access and audit requirements are met there. The output is an approved case design that the workflows write to.
Run both platforms side by side per use case
Move one use case at a time, keeping XSOAR playbooks active for the others. For each moved workflow, compare outcomes, action counts and analyst findings between the two platforms on the same alerts, and record discrepancies. Keep the XSOAR playbook in place until the Shuffle version has matched it on the agreed test cases and the rollback path is tested. The check is a signed-off comparison record per use case before the XSOAR playbook is disabled.
Questions buyers ask before switching from XSOAR to Shuffle
How much does switching from XSOAR to Shuffle cost?
The cost splits into software, infrastructure, staff time and any outside help, and the software line is the one that changes most. Shuffle says all features are available in its open-source edition, and its paid tiers differ in feature limits, scaling and support. Its pricing article meters licensing on app runs, meaning actions that execute in a workflow, while users, apps and workflows are unlimited. Infrastructure is a recurring cost you pay to your own cloud or data center provider. It covers servers, OpenSearch storage and, for high availability, an OpenSearch cluster, Memcached, NFS and more than one Orborus node. The install guide sets a minimum of 4 GB of RAM, but production sizing depends on your run volume. Ask any vendor, including Shuffle's paid tiers, for a written quote that states the license tier, the run volume assumed, hosting and support hours.
How long does it take to move playbooks from XSOAR to Shuffle?
No duration is fixed by the product, so the timeline depends on the number of playbooks, the complexity of each integration and how many workflows must run in parallel with XSOAR during cutover. Each integration needs a path into Shuffle. You can build an app in the App Creator from an OpenAPI specification, or write one in Python with the Shuffle app SDK. Either way, the app runs as a versioned Docker container, so it needs its own testing and version control. Simple, read-only enrichment playbooks usually move faster than playbooks that write back to case records or depend on XSOAR-specific scripts. Running both platforms side by side for each use case adds time, but it lowers the risk of a gap in response. Agree the timeline in writing as part of the scope before work starts, and ask for it to be broken into use cases.
What skills does a team need to run Shuffle in production?
The team needs container operations skills for Docker Compose or Kubernetes, with Helm charts for Kubernetes deployments. Someone must also administer OpenSearch, since it is Shuffle's document database, and understand how backups, snapshots and capacity work for it. Python skills matter if you build custom apps with the SDK, and API skills matter for OpenAPI-based integrations. Security operations staff must understand the workflows they own. Protect the SHUFFLE_ENCRYPTION_MODIFIER secret with care. Shuffle encrypts saved app credentials and API keys with AES-256 using that value, and the configuration docs warn that losing or changing it breaks all saved app authentications. Store it in a secrets manager and include it in your recovery plan.
Can our own team migrate from XSOAR to Shuffle without outside help?
Your team can do it alone if it has the time, the skills in the section above, and the capacity to test workflows against live alerts. The main drivers are the number of custom integrations and scripts, the amount of XSOAR logic tied to its runtime, and how much parallel running your SOC can absorb. Start with an inventory. In XSOAR 8, custom content can be exported from Settings, then Server Settings, then Custom content, and individual playbooks can be downloaded from the content item menu, as described in the XSOAR 8 playbook documentation. Confirm which formats your XSOAR version produces, and test each exported item to see what must be rebuilt. Teams that lack Python or API skills, or that cannot take analysts off the queue, often choose a fixed-scope engagement for the rebuild.
How does Shuffle handle incidents without a war room?
Shuffle does not provide a war room or built-in incident layouts, so it is an automation engine, not a case management system. It can receive alerts, enrich them, run response actions and record workflow executions. Analyst notes, assignments, SLAs, approvals and the incident timeline need another home. Decide early which system owns each of these. Options include a separate case or ticketing system, such as your existing ITSM tool, or a self-hosted case tool paired with Shuffle. Map your XSOAR incident types, fields and SLA rules to that system before you move any playbook that writes to incidents. Otherwise analysts lose context during cutover. Confirm how the chosen case system receives updates from Shuffle, and test the handoff with a sample incident before retiring XSOAR layouts.
Can Shuffle run in an air-gapped network?
Shuffle documents installs on Docker and Kubernetes, and both are the starting points for a disconnected site. Confirm in the install guide and configuration docs that every image, component and app dependency can be pulled or loaded without internet access, and test that before you commit. Ask how apps and their container images are transferred into the network, how updates are staged, and who approves each import. The hybrid model in the architecture docs relies on a local Orborus connecting to Shuffle Cloud, so it does not fit a fully disconnected site. Build a test environment with the same network controls first, and document what you verified and what you could not verify. Independent auditors, not the implementer, decide whether that evidence meets your assessment needs.
Does Shuffle support single sign-on for analysts?
Yes. Shuffle added SAML single sign-on in version 0.9.16 and OpenID Connect in 1.0.0, and both are available on premises and in the cloud, with per-tenant SSO enforcement. The extensions docs note that SAML is being deprecated on Shuffle Cloud in favor of OpenID Connect. For a self-hosted deployment, pick the protocol your identity provider supports well, and check the current documentation for the version you deploy. Test group mapping, role assignment and session behavior with a small set of analysts before you roll it out. Document who can change SSO settings, since those settings control access to every workflow and stored credential.
When should we bring in outside help for a SOAR migration?
Bring in outside help when the work exceeds your team's time or skills, or when the migration must be planned against audit or residency requirements. DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ongoing support, upgrades and continuous testing are available as retainers. DeployOpen does not publish a price list, and a quote follows from the written scope. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies do that work.
How DeployOpen helps evaluate or migrate to Shuffle
DeployOpen plans, implements, integrates, hardens, backs up and documents self-hosted Shuffle inside your own infrastructure, whether that is a cloud account, a data center or an air-gapped network. For a Cortex XSOAR replacement, the first engagement usually produces a written inventory of what runs today: playbooks, integrations, incident types, layouts and the war room usage that Shuffle does not provide. That inventory decides the architecture, including whether Docker Compose is enough for a pilot or whether a Kubernetes deployment with several Orborus nodes and an OpenSearch cluster is needed for high availability. DeployOpen also covers the pieces around Shuffle that you must pair with it, such as a case system, SSO through OpenID Connect, and the handling of the SHUFFLE_ENCRYPTION_MODIFIER secret, which must be backed up because losing or changing it breaks every saved app authentication.
Security testing is a separate, optional workstream. DeployOpen can test the Shuffle deployment, its APIs, the app containers and the integrations it calls, and red team the response path, so you know whether automated actions stay within the permissions you intended. Work is fixed-scope: scope, deliverables and timelines are agreed in writing before work starts, and ongoing support, upgrades and continuous testing are available as retainers. DeployOpen does not publish a price list. A quote follows from the written scope, so ask for the scope to list the number of workflows to migrate, the integrations to rebuild, the environments to build and the training your analysts need.
DeployOpen prepares systems, controls and evidence for compliance assessments, such as configuration records, access settings and backup and restore results, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make those determinations. Before you commit, confirm with your assessor which evidence they expect from an automation platform and whether the records you keep for Shuffle cover the controls your program relies on.
