Cortex XSOAR is priced on the two things a successful automation programme produces more of: analysts using it and automations running. That is an uncomfortable shape, because the better your SOAR works, the more it costs. Shuffle is the closest open-source equivalent, an app-based orchestration engine you self-host, and the migration is conceptually simple and practically laborious: nothing exports, so everything gets rewritten.
The good news is that “everything” is much smaller than the platform makes it look.
Pull the execution statistics before you plan anything
XSOAR estates accumulate playbooks the way SIEMs accumulate correlation rules. Before scoping, export the execution counts per playbook over the last twelve months and sort them.
The distribution is reliably lopsided. Phishing triage, alert enrichment, indicator lookups, user and host containment, and ticket creation typically account for most executions. Then there is a long tail: playbooks built for a project that ended, playbooks that duplicate each other with slight variations, and playbooks that error silently and have not run since an API changed.
Your migration scope is the head of that distribution, not the platform inventory. Migrating the top ten playbooks by run count usually recovers the great majority of the operational value, and it makes the project a matter of weeks rather than quarters. Retire the tail explicitly, with an owner and a date recorded, so the decision is visible.
Do the same for integrations. Count the integrations those surviving playbooks actually call. That list, not the content-pack catalogue, is what you have to rebuild.
The mapping
- XSOAR playbooks → Shuffle workflows (nodes, conditions, branches).
- Integration commands → Shuffle app actions, generated from the vendor’s OpenAPI spec where one exists.
- Automation scripts (Python) → Shuffle Python steps, often close to a copy-paste with the demisto SDK calls replaced.
- Incident fields → workflow variables, plus fields on your case platform.
- Incident types and layouts → case templates in TheHive or equivalent.
- War room → the case platform’s timeline and comments.
- Indicators and the threat-intel module → MISP or OpenCTI, queried from workflows.
- Jobs and scheduled playbooks → Shuffle schedules.
- Sub-playbooks → Shuffle child workflows.
The integration library is the real gap
Be clear-eyed about this, because it is where the migration either works or does not. XSOAR’s content library is one of the largest in the industry and it is a genuine reason people pay for the product. Shuffle’s app ecosystem is a fraction of the size.
What makes the migration viable anyway is that you do not need the library, you need your integrations. Go through the list you produced above and check each vendor for a documented API. Where there is an OpenAPI specification, Shuffle can generate an app from it directly and you are most of the way there. Where there is a documented REST API without a spec, a Python step calling it is straightforward. Where the vendor’s only supported automation path was the XSOAR content pack and the underlying API is undocumented or unavailable, you have found a real blocker, and you want to find it in week one rather than week ten.
Run that check before you commit to the migration. It takes a day and it is the single highest-value piece of diligence in this project.
Credentials are a migration in themselves
Every integration XSOAR holds is an authenticated connection to something important: your EDR, your firewall, your identity provider, your ticketing system, often with permission to change things. Those credentials live in XSOAR’s vault and are not transferable, nor should they be.
Treat this as a re-issuance exercise rather than a copy. For each surviving integration, mint a new service credential scoped to exactly the actions the rebuilt workflow performs, and no more. This is the natural moment to fix the over-permissioned tokens that accumulated in XSOAR because somebody granted admin to get a playbook working on a Friday. Store them in Shuffle’s secret handling or an external secrets manager, and revoke the XSOAR credentials as each workflow cuts over, so a decommissioned platform is not left holding live keys to your estate.
Shadow mode, then write access, one action at a time
A SOAR is the most dangerous thing in a security stack, because it acts. The rollout pattern that keeps this migration safe is strict and worth following literally.
First, every rebuilt workflow runs read-only: it performs enrichment, evaluates its logic, and logs the action it would have taken, without taking it. Run it on the same alert stream XSOAR is handling and compare decisions. Discrepancies are either a logic bug you just caught for free, or a difference in enrichment data you need to understand.
Second, once the decision log is clean over a meaningful sample, grant write access to one action at a time, lowest blast radius first: create a ticket, then add a comment, then tag an indicator, then block a hash, then isolate a host, then disable an account. Each step gets its own scoped credential and its own soak period.
Third, keep human approval on anything that can take a production system offline, regardless of how confident the workflow is. Shuffle supports approval steps; use them.
Order of operations
- Export execution statistics and scope to the head of the distribution.
- Inventory the integrations those workflows call, and verify each vendor’s API independently of XSOAR.
- Deploy Shuffle and the case platform together, because a workflow with nowhere to put a case is only half migrated.
- Rebuild the highest-volume workflow first, in shadow mode, using the exported XSOAR YAML as the specification.
- Compare decisions daily against the live XSOAR playbook until they agree.
- Grant write scopes incrementally, one action at a time with fresh, narrowly scoped credentials.
- Cut over per workflow, disabling the XSOAR playbook only once its replacement has run in production.
- Revoke XSOAR credentials as each cuts over, and confirm none remain live at decommission.
Clearing the bar before you cut over
Every migrated workflow has run in shadow mode with a clean decision log. Every credential is newly minted and scoped to the specific actions used. Containment actions have been tested against a deliberately triggered incident, including the failure path where the target system is unreachable. Analysts have worked real cases in the new case platform. Retired playbooks are documented as retirements. And nothing in the estate still trusts an XSOAR-issued token.
The short version
XSOAR to Shuffle is a rewrite, not a migration, and the scope is set by how many playbooks genuinely run rather than how many exist. Verify your integrations have usable APIs before committing, pair Shuffle with a case platform because orchestration alone is not the whole product, re-issue every credential with tighter scope than the original, and never let a rebuilt workflow take an action in production before it has spent time proving its decisions in shadow. Use the calculator above for illustrative economics, and count the self-hosting and the engineering time as real costs against the licence you are removing.