Migrate from Cortex XSOAR to Shuffle: what the move involves
A SOC or platform team that needs to leave Cortex XSOAR for self-hosted automation usually starts with one question: how much of what XSOAR does can move, and how much has to be rebuilt. The short answer is that playbook logic is portable as a design, integrations are rebuilt as apps, and incident handling needs a decision before any cutover date is set. Shuffle builds its apps from OpenAPI specifications in the App Creator or in Python with the Shuffle app SDK, so the work is largely re-expressing each XSOAR integration as an app that runs in a versioned Docker container. Shuffle does not ship XSOAR-style incident layouts or a war room, so analysts who work inside XSOAR cases need an answer for where those cases live after the move. The total effort depends mainly on how many playbooks and integrations are in use, how many of them carry custom Python or JavaScript logic, and how many depend on XSOAR's runtime. Platform engineers or automation developers usually do the rebuild, with SOC analysts as reviewers who confirm that the new workflows still close the same cases.
Start with an inventory. Export all custom content from XSOAR using the export option under Server Settings and Custom content, and download individual playbooks from the content item menu, as described in the Cortex XSOAR 8 manage playbook content documentation. For each item, record the trigger, the systems it calls, the credentials it uses and the incident fields it reads or writes. Sort integrations into three groups: those with a maintained OpenAPI description or a premade Shuffle app, those that need a new Python app, and those that depend on XSOAR-only behavior. Confirm the trigger side separately. Shuffle workflows do not receive incidents from a SIEM by default, so each detection source needs its webhook or forwarding rule rebuilt and tested against the new workflow. Also confirm that your server meets the stated minimum of 4 GB of RAM and that the deployment matches your architecture, since the default Docker Compose setup is not a scalable build without changes.
Run the two platforms side by side, one use case at a time. Pick a low-risk use case, such as phishing mail triage, build its Shuffle workflow, and let both systems process the same alerts for a fixed review period while analysts compare outcomes. Keep XSOAR authoritative for case records until the new workflow matches it. Plan for credential handling early: Shuffle encrypts saved app credentials with the SHUFFLE_ENCRYPTION_MODIFIER secret, and losing or changing that value breaks every saved app authentication, so store it in your secrets manager before the first import. Decide where cases, analyst notes and SLA tracking will live, whether in a separate case system or in a tool that ships its own cases. When you request a quote for this work, ask the provider to list the playbook count, the integrations per category, the trigger sources to rebuild and the acceptance tests each use case must pass.
Which XSOAR capabilities map to Shuffle, and which need rework
This table marks each Cortex XSOAR capability as clean, needs rework or gap when moved to Shuffle. Read the middle column as the outcome, and the last column as the work your team will carry. Playbooks and credentials are the items most likely to need planning before cutover.
| Capability | Status on Shuffle | What it means for the migration |
|---|---|---|
| Playbooks | Needs rework | Shuffle workflows are rebuilt by hand in its editor. Export XSOAR playbooks first to inventory logic, then map each task to a Shuffle action. |
| Custom scripts | Needs rework | Python scripts can be moved into Shuffle apps using the Python app SDK. JavaScript or XSOAR runtime-specific logic must be rewritten. |
| Integrations | Needs rework | Shuffle builds apps from OpenAPI specifications in the App Creator or from Python code. Each integration needs its own validation against the target tool. |
| Premade apps | Clean | Shuffle ships premade apps for many security tools. Check each vendor you use against the current app catalog before rebuilding it. |
| SIEM triggers | Needs rework | Webhook or API triggers must be re-created in the SIEM and pointed at Shuffle. Test payload fields against each workflow's start node. |
| Incident layouts and war room | Gap | Shuffle has no built-in incident layouts or war room. Plan a separate case system or accept that analyst notes move elsewhere. |
| Stored credentials | Needs rework | Shuffle encrypts saved app credentials with AES-256 using SHUFFLE_ENCRYPTION_MODIFIER. Re-enter credentials and back up that secret before any cutover. |
| RBAC and SSO | Needs rework | Shuffle supports SAML and OpenID Connect single sign-on. Confirm role mapping to your identity provider, since XSOAR role models do not transfer directly. |
| Scaling and high availability | Needs rework | Shuffle uses OpenSearch as its database and Orborus to run workflow executions. Plan an OpenSearch cluster and more than one Orborus node for production. |
What XSOAR exports and what does not transfer
The documented starting point for this migration is the export path in Cortex XSOAR 8: open Settings, then Server Settings, then Custom content, and choose Export all custom content to pull every custom item in one archive. Individual playbooks can also be downloaded from the content item menu. Treat that export as an inventory you can read, not as a file Shuffle will import. Shuffle has no importer for XSOAR playbook YAML, so every workflow, script and integration you keep has to be rebuilt as a Shuffle workflow and app. Before you start, confirm with Palo Alto Networks documentation for your exact XSOAR version and deployment (6.x on premises or 8 SaaS) which content types the export covers, since coverage differs between versions and some items may need to be exported separately. Record the result in a spreadsheet with one row per playbook, script and integration, including its trigger and the systems it calls.
Most of what does not transfer is logic tied to XSOAR's runtime. Playbook tasks that rely on XSOAR's built-in incident fields, war room entries, layouts, SLA timers or the incident context object have no direct equivalent in Shuffle, which has no built-in incident layouts or war room. JavaScript integrations and scripts depend on XSOAR's own execution environment and must be rewritten, typically as Python apps built with the Shuffle app SDK or as OpenAPI-based apps from the App Creator. Conditional branches, loops and sub-playbook calls also need to be mapped by hand, because a Shuffle workflow is a different structure. Credentials are never part of the export in a usable form, so every integration account must be recreated in Shuffle, and the saved credentials are encrypted with the SHUFFLE_ENCRYPTION_MODIFIER secret, which you must back up before loading them.
Plan the migration as a mapping exercise with three outcomes for each item: rebuild, replace with a Shuffle premade app, or retire. Give the most weight to playbooks that run on a schedule or on SIEM alerts, because those are the ones that will be missing if they stop. Test each rebuilt workflow against replayed or sample alert data in a non-production Shuffle instance, and compare outputs with the XSOAR run history before you switch the trigger. Ask your integrator or vendor to confirm which XSOAR content types your export includes and how it handles integration parameters, so the inventory is complete before any rebuild is scoped.
What to move: playbooks, integrations, credentials and triggers
A Cortex XSOAR to Shuffle move breaks into a few separate pieces, and each one fails in a different way. The cards below cover what to export, what to rebuild, what to re-enter and what to leave behind, so the cutover plan can assign an owner and a check to each item.
Playbook logic and task flow
Export every playbook from XSOAR before you touch Shuffle, using the custom content export and the per-playbook download. Shuffle workflows are not a file-level import of XSOAR playbooks, so each playbook must be redrawn as a Shuffle workflow with its branches, loops and conditions checked against the original. Treat the export as a specification to read, not a file to load. Map each task to a Shuffle action before you build anything.
Custom scripts and runtime logic
XSOAR scripts often hold enrichment, parsing or decision code that runs inside the XSOAR runtime and calls XSOAR-only context. That code has no direct equivalent in Shuffle, so each script needs a decision: move the logic into a Python app built with the Shuffle SDK, move it into a workflow step using Shuffle's variables, or retire it. Review scripts that read or write the XSOAR incident context first, since those dependencies are the most likely to break silently.
Integrations rebuilt as OpenAPI or Python apps
Shuffle apps are built either from an OpenAPI specification in the App Creator or written in Python with the Shuffle app SDK, and each app runs as a versioned Docker container. Start with the integrations your playbooks call most often, and confirm that the vendor publishes an accurate OpenAPI file for the endpoints you use. JavaScript integrations and XSOAR-specific command output formats usually need rewriting, and the output schema your downstream steps expect should be tested against real responses.
Credentials re-entered and encrypted
Saved integration credentials and API keys do not move from XSOAR to Shuffle. Each one is re-entered in Shuffle, where it is stored encrypted in OpenSearch with AES-256 using the SHUFFLE_ENCRYPTION_MODIFIER secret. Set that value once, store it in your secrets manager, and record it in the runbook for disaster recovery, because changing or losing it breaks every saved app authentication. Use service accounts with the narrowest scope each playbook needs.
SIEM triggers recreated as webhooks
XSOAR fetches incidents from its integrations, and many SIEM alerts reach it through a configured connector. In Shuffle, the same alerts must be sent to a workflow webhook or started on a schedule, which means changing the SIEM's alert action or forwarder on the other side. List every trigger, its alert source, its filter and its expected volume, then send a sample alert from the SIEM to confirm the payload fields match what the workflow expects.
Historical incidents stay in XSOAR
Shuffle does not import XSOAR incident history, and it has no built-in incident layouts or war room. Decide which closed incidents, notes and evidence must remain searchable for audit or reporting, then keep the XSOAR instance read-only for that period or export the records to an archive your retention policy covers. Confirm with your compliance owner how long the archive must be kept and who can access it.
How the cutover sequence runs, step by step
The sequence moves one use case at a time from Cortex XSOAR to Shuffle, so each automation is proven on evidence before its triggers are switched and the old content is archived. Each step ends with a named artifact that the next step depends on.
Inventory playbooks, integrations and triggers
The SOC lead and an engineer list every playbook, script, integration instance and incident trigger in the XSOAR server, and tag each with its owner, the SIEM or mailbox that feeds it, and the connected tools. Export the custom content first using Settings, Server Settings, Custom content, Export all custom content, and download individual playbooks from the content item menu. The step is done when you have an inventory list with one row per use case, flagged by whether it depends on XSOAR-only runtime logic or JavaScript integrations, which will need a rewrite rather than a copy.
Choose one use case and rebuild it in Shuffle
Select one low-risk, high-volume use case, such as phishing mailbox triage or an enrichment lookup, and rebuild it as a Shuffle workflow. Where an integration is missing from the premade apps, create it with the App Creator from the vendor's OpenAPI specification or write a Python app with the Shuffle app SDK, and check that the app runs as a versioned container. The output is a pilot workflow and a short test record showing sample inputs, expected outputs and the results of each test run against a non-production tenant.
Re-create the incident trigger and test it
Configure the SIEM or mailbox to send the pilot's alerts to Shuffle's webhook trigger in addition to XSOAR, and confirm the event fields match what the workflow expects. Keep the XSOAR trigger active so both systems receive the same alert. The step is complete when test alerts reach both platforms and the field mapping is documented, including any fields XSOAR set through incident layouts that Shuffle does not provide natively, which must be handled in your case system.
Run both systems in parallel
For an agreed observation period, let XSOAR keep acting on the alert while Shuffle runs the same logic in a mode that records what it would do without acting on the environment. Compare actions, enrichment results, ticket outcomes and any errors per alert in a side-by-side table. The output is a comparison of run results that shows where the two systems agree, where they differ and whether each difference is a defect in the new workflow or a gap in the old one.
Switch triggers on a dated cutover
After the comparison is signed off by the SOC lead and the owner of the affected tools, record the cutover date and disable the XSOAR trigger for that use case while the Shuffle trigger becomes the only active path. Keep a rollback step written down, including who can re-enable the XSOAR trigger and how. The output is a dated change record listing the use case, the owners who approved it and the rollback procedure. Repeat this sequence for the next use case rather than moving everything at once.
Decommission and archive the XSOAR content
When every use case in the inventory has either moved or been retired, disable the remaining XSOAR integrations and scheduled jobs and keep the server in read-only status for the retention period your policy requires. Store the exports from the first step, the comparison records and the change records in your evidence repository, and confirm with your records owner which copies must be kept. The output is a set of archived exports and an evidence index that a reviewer can use to trace each automation from its original XSOAR playbook to its Shuffle workflow.
Running XSOAR and Shuffle side by side, per use case
Phishing triage is usually the first use case to move because its inputs are well defined: a reported message, a mailbox search, sender and URL checks, and an analyst verdict. During the overlap, the existing XSOAR playbook keeps handling live reports while a Shuffle workflow receives a copy of the same trigger and runs its enrichment steps without taking any containment action. Analysts still close tickets from XSOAR, so Shuffle's output is a shadow result that someone compares.
- Duplicated trigger: the mail reporting mailbox or SIEM alert rule feeds both platforms, typically through a second webhook or forwarder, so each report reaches both at the same time.
- Shadow mode: the Shuffle workflow posts its verdict to a separate channel or table and does not move mail or disable accounts.
- Comparison: record the verdict, enrichment fields and time to result from both sides for the same report IDs.
- Flip rule: switch when agreement on verdicts meets a threshold the SOC lead sets in writing before the test starts.
- Cases: Shuffle does not provide incident layouts, so decide where the analyst verdict is recorded during the overlap.
Confirm with your own SOC how duplicate alerts are deduplicated so that the same report does not open two tickets or two mailbox actions.
Enrichment workflows call threat intelligence, asset inventory, identity and reputation services to add context to an alert. They are the safest use case to run in parallel because they read data rather than change it. The comparison focuses on whether the same indicators return the same context, and whether API keys and quotas behave the same way on both sides. Enrichment in Shuffle depends on app definitions for each service, which are built from OpenAPI specifications in the App Creator or written with the Python app SDK.
- Duplicated trigger: the same alert or indicator submission goes to XSOAR and to a Shuffle webhook, with no write actions on either side.
- Credential check: store the service credentials in Shuffle and confirm that each app authenticates before comparing results.
- Output diff: compare returned fields, scores and error handling for a fixed sample of indicators.
- Quota awareness: duplicate calls double API consumption during the overlap, so confirm rate limits with each provider.
- Flip rule: move the enrichment step to Shuffle once field mappings match for the agreed sample.
Confirm which services allow a second API key or a read-only key for the test period.
Containment actions such as disabling an account, isolating a host or blocking an address change the state of production systems. They should never run in both platforms for the same incident. The overlap for containment is therefore a dry run: Shuffle executes the decision logic and records the action it would take, while XSOAR keeps the live action. Once the Shuffle output matches the live actions across the agreed set of incidents, the team moves the live action and retires the XSOAR branch in a single change.
- Single actor rule: only one platform may hold the live write permission for a given action at any time.
- Dry-run output: Shuffle logs the target, action and approval step it would have taken, without calling the write API.
- Approval steps: confirm that human approvals in the existing process are reproduced in the Shuffle workflow.
- Rollback: document how a wrongly applied action is reversed and who is authorized to do it.
- Flip rule: switch only after a change window is approved and the dry-run record matches live actions.
Illustrative example: a host isolation workflow may run for two weeks in dry-run, but the write credential stays with XSOAR until the SOC lead signs the cutover. Confirm this with your change management owner.
Vulnerability response workflows pull findings from scanners, de-duplicate them, assign owners and open tickets. They run on schedules or bulk imports rather than real-time triggers, which makes the comparison straightforward but also means the overlap can take longer to produce enough samples. Ticket creation is the write action that needs care, because duplicate tickets quickly erode trust with application owners.
- Duplicated trigger: the scanner export or scheduled job is delivered to both platforms, with ticket creation disabled in Shuffle during the overlap.
- Output comparison: match finding counts, de-duplication keys, severity mapping and assigned owners for each scan.
- Ticket parity: compare the tickets each platform would open, not only the counts.
- Schedule alignment: a single scan can trigger two runs if both platforms poll the same source, so confirm which one owns the schedule.
- Flip rule: move ticket creation once a full scan cycle produces matching output.
Confirm with your ticketing system owner whether it accepts a second integration user during the overlap.
The side by side period is also an operations test. The Shuffle install guide notes that the default Docker Compose setup is not scalable without changes and needs a minimum of 4 GB of RAM. Shuffle's configuration docs recommend more than one Orborus node so that workflows keep running if one fails. Orborus polls the backend for jobs and starts a worker for each workflow execution, so a single node is a single point of failure for every workflow in the overlap. Running parallel workflows on one node can also hide capacity problems that appear at cutover.
- Orborus nodes: run at least two Orborus instances during the overlap, and test that a workflow continues after one node is stopped.
- Backend and storage: follow the high availability guidance for an OpenSearch cluster, shared files and scaled backend and frontend services.
- Secret key: back up the
SHUFFLE_ENCRYPTION_MODIFIERvalue before any restore test, since changing it breaks saved app authentications. - Monitoring: watch execution queues and worker failures on both platforms during the test.
- Flip rule: do not retire XSOAR for a use case until failover has been tested for that workflow's execution path.
Confirm your node count, sizing and failover test plan with the team that will operate Shuffle after the migration.
What drives migration effort and how to keep it down
This table lists the factors that set how much work a move from Cortex XSOAR to Shuffle will take, why each one matters, and the practice that keeps it manageable. Read each row against your own XSOAR estate, since the same driver can be small in one SOC and large in another.
| Driver | Why it raises effort | How to keep it down |
|---|---|---|
| Number of playbooks in use | Each playbook must be rebuilt as a Shuffle workflow, and XSOAR task logic does not convert automatically, so effort grows with the count of live playbooks. | Export the full inventory, then retire unused and duplicate playbooks before rebuilding. Migrate the highest-volume use cases first. |
| Custom integrations and their language | Python integrations can often be re-cut into Shuffle apps with the Python SDK, but JavaScript integrations and logic tied to XSOAR's runtime need a fresh design. Vendor integrations built from OpenAPI specifications are usually the cheapest to rebuild. | Sort integrations by language and by whether a Shuffle premade app already covers them. Generate apps from OpenAPI specifications where the vendor publishes one. |
| Number of stored credentials | Each credential must be re-entered in Shuffle, where saved app authentication is encrypted in OpenSearch with a secret key. Credential mapping errors surface only when a workflow runs. | Build a credential register with owners and scopes before cutover. Store the SHUFFLE_ENCRYPTION_MODIFIER value in your secrets manager, since losing or changing it breaks all saved authentications. |
| SIEM trigger complexity | XSOAR playbooks often start from SIEM alerts with filters, enrichment and deduplication. Each trigger has to be recreated in Shuffle and tested against real alert payloads. | Document each trigger's query, field mapping and suppression logic. Replay captured alerts through Shuffle in a side-by-side run before moving any trigger. |
| Required RBAC and SSO | Analyst roles, approval steps and per-team access in XSOAR must be mapped to Shuffle's user and permission model. Identity integration adds configuration and testing work. | List roles by function before building. Confirm with your identity team which SSO protocol you will use, since Shuffle supports SAML and OpenID Connect with SAML being deprecated on Shuffle Cloud. |
| High availability design | A production deployment needs an OpenSearch cluster, shared file storage when running several backends and more than one Orborus node. Each added component needs its own build, test and monitoring. | Decide the target architecture (single server, Docker Swarm or Kubernetes) before rebuilding workflows, so testing happens on the final topology. Confirm sizing with the Shuffle install guide. |
| Case management decisions | XSOAR incidents, layouts and the war room have no direct Shuffle equivalent, so analyst workflows may need a separate case system. Each decision changes how many workflows must be rebuilt. | Decide early whether cases stay in an external system or move to another tool. Map incident fields and analyst notes once, then reuse that map across all playbooks. |
| Parallel running period | Running XSOAR and Shuffle side by side doubles alert handling for each use case and requires agreed criteria for switching over. | Set a per-use-case cutover checklist covering alert parity, response times and rollback steps. Retire XSOAR playbooks one use case at a time. |
What usually goes wrong and how to prevent it
Most failed Shuffle migrations break in the same few places: secrets, production hosting, the incident model, parallel runs, licensing and detection triggers. Each risk below is easy to miss during a rebuild because the playbooks still appear to work in a test tenant. Check each one before you retire a single XSOAR playbook.
Losing the encryption modifier
Shuffle encrypts saved app credentials and API keys in OpenSearch with AES-256, using the SHUFFLE_ENCRYPTION_MODIFIER secret. If that value is lost or changed during a rebuild or restore, every saved app authentication stops working at once. Store the value in your secrets manager before the first import, record it in your backup runbook, and test a restore on a separate instance to confirm the credentials decrypt.
Running Compose as production
The default Docker Compose setup is not a scalable build without changes, so teams that move XSOAR playbooks onto it often find it cannot carry production load. Shuffle's architecture docs describe Docker Swarm and Kubernetes with Helm charts as alternatives. Decide the target architecture during planning, and confirm the OpenSearch cluster, shared file storage and multiple Orborus nodes your availability goals require.
Assuming incident layouts carry over
XSOAR playbooks often depend on incident types, field layouts, SLAs and the war room for analyst work. Shuffle does not provide these, so a rebuilt playbook may run correctly while analysts have no place to record notes or track ownership. Map every incident field your playbooks write to, and choose a case system before cutover, whether Shuffle's incident handling or a separate tool.
Parallel runs acting twice
Running XSOAR and Shuffle side by side is safe only when one of them owns each action. If both platforms receive the same alert, they can block the same account, open duplicate tickets or quarantine the same host twice. For each use case, define which platform is the single writer for containment actions, disable the other trigger, and log which platform acted during the overlap period.
Underestimating app-run counts
Shuffle's licensing metric counts app runs, meaning actions that actually execute in a workflow, while triggers and skipped actions are not counted. Playbooks with many enrichment calls or polling loops can consume runs faster than expected. Before you commit to a plan, replay a representative week of XSOAR incident volume through Shuffle in a test environment and count the executed actions per incident type.
Missing triggers after SIEM changes
XSOAR incident triggers are often tied to SIEM rules, webhooks or fetch configurations that were set up years ago and are not documented. When the SIEM moves to a new rule set or log source, the Shuffle workflow may never receive an alert, and nothing reports the gap. Inventory every source that starts a playbook, create a matching Shuffle trigger for each, and send a known test event through each one to confirm the workflow fires.
Deciding where incident cases live after the move
The first decision in this section is whether incident cases stay inside the automation tool or move to a separate case system. Cortex XSOAR combines playbooks with incidents, layouts and the war room, so analysts work cases where the automation runs. Shuffle covers the automation side well, but it does not ship XSOAR's incident layouts or war room, so the case record has to live somewhere else or be built on Shuffle's own incident handling. Confirm the current incident and case features of Shuffle against the Shuffle GitHub repository and its documentation before you commit, because the answer determines whether analysts need a second tool at all.
Start by mapping what XSOAR holds for each case. Inventory the incident types, their custom fields, the layouts analysts use to view them, the notes and tasks written during investigation, and any SLA timers or escalation rules tied to severity. Export the incident type and field definitions from XSOAR so the mapping works from the actual configuration, not from memory. For each item, record whether the target system needs it as a structured field, a free-text note, an attachment or a derived value, and who reads it afterwards. Notes and SLA clocks are the items most often lost, because they are rarely part of the playbook export and are easy to overlook in a side-by-side review.
Then test the chosen design against one real case type from start to finish. Create an illustrative incident with its fields, run the Shuffle workflow that enriches and closes it, and confirm that analysts can find the notes, the timestamps and the SLA state where they expect them. Check how the case record is retained, who can edit it and how it is exported for an auditor or a post-incident review. Keep a written record of these decisions, because the evidence that cases were handled consistently during the parallel run depends on it.
How the migration differs by starting point
Teams on XSOAR 6 run the server, integrations and playbooks inside their own network, so the export happens from a system they already control. The most valuable early work is the inventory: which playbooks are live, which integrations feed them and which items depend on XSOAR's runtime. Version timing also matters, because the 6.12 and 6.13 releases reach end of life on June 30, 2026, which sets a hard date for that group.
- Version check: Confirm which 6.x release runs in production. 6.12 and 6.13 reach end of life on June 30, 2026, while 6.14 remains active.
- Export scope: Record which content came from the marketplace, which was written in-house and which JavaScript integrations need rewriting.
- Runtime coupling: Playbooks that call XSOAR-specific scripts, incident fields or the war room need redesign, since Shuffle has no built-in incident layouts or war room.
- Host sizing: Give Shuffle a dedicated host that meets its 4 GB minimum, and plan OpenSearch storage from the first build.
Before you schedule cutover, confirm which XSOAR integrations have an OpenAPI definition that the Shuffle App Creator can use or a Python path with the Shuffle app SDK.
XSOAR 8 SaaS is hosted by Palo Alto Networks, so your team exports content from the tenant instead of a server it operates. Exporting all custom content from Settings, Server Settings, Custom content is the starting point, and individual playbooks can be downloaded from the content item menu. The main differences come from the split between a vendor-hosted source and a self-hosted target, which affects data handling during parallel runs and the network path between the two.
- Export path: Use Export all custom content for the full set, then download single playbooks from the content item menu when you need to check one flow.
- Tenant data during overlap: Confirm with Palo Alto Networks what incident and indicator data continues to flow to the tenant while both platforms run.
- Credentials: Expect to re-enter integration credentials in Shuffle, and confirm with the vendor what the export includes.
- Network path: Hybrid mode with a local Orborus needs no inbound firewall ports, which can simplify the network review for a self-hosted runtime.
- Pinned versions: Use a fixed Docker tag for stable Shuffle releases, and test nightly builds in a separate environment.
Confirm the data flows with your security and privacy owners before the first parallel run starts.
Disconnected networks change the install and update path more than the playbook logic. Shuffle has to run from images and app definitions loaded inside the enclave, with no outbound pulls at runtime. The sibling page on offline app loading covers the technical steps, while this section covers the planning that happens before anything is installed.
- Image transfer: Assemble the Shuffle, OpenSearch and app images, then move them through your approved import process before the first install.
- Target platform: Choose Docker or Kubernetes based on what your offline registry already supports, and mirror Helm chart dependencies if you use Kubernetes.
- Update cadence: Every Shuffle release has to cross the boundary, so pin a tag and write the upgrade procedure before go-live.
- Encryption key: Store SHUFFLE_ENCRYPTION_MODIFIER in your approved secrets process. The configuration docs warn that losing or changing it breaks all saved app authentications.
- XSOAR version support: Palo Alto Networks points disconnected sites to XSOAR 6, so verify that the release you run is still supported for the overlap period.
Confirm the transfer method and registry with your accreditation or network team before you set any cutover dates.
A single SOC usually has one tenant, one set of content owners and one approval path, so the migration can run as a single project with use cases moved in order. An MSSP serves several customers, and each one needs its own content, credentials and reporting boundaries. The pricing article says users, apps and workflows are unlimited on Shuffle, but the licensing metric counts app runs, so the cost model depends on volume and tenancy design.
- Single SOC ownership: One team owns playbooks, integrations and the cutover calendar, so parallel runs can be scheduled per use case.
- Tenant separation: For an MSSP, decide whether each customer gets its own Shuffle instance or shares one with separate workflows and credentials. Confirm how the open-source and enterprise editions handle that choice, since limits between them have been enforced since v2.1.1.
- App run volume: Estimate expected actions per customer before choosing a licensing model, because app runs are the billed unit.
- Access control: Map existing roles to Shuffle's SSO options, SAML from version 0.9.16 and OpenID Connect from 1.0.0, and confirm per-tenant enforcement fits your structure.
- Reporting: Rebuild per-customer reporting from Shuffle's execution data, and do not assume XSOAR reports carry over.
Ask the vendor to state in writing how app runs are counted for your expected workflow volume.
The Shuffle architecture sets how much platform work comes before the first playbook is rebuilt. Shuffle documents four models: a single server with Docker Compose, distributed Docker Swarm, Kubernetes with Helm charts, and a hybrid with Shuffle Cloud and a local Orborus. The Shuffle install guide states that the default Docker Compose setup is not a scalable build without changes, so the choice affects the plan from the start.
- Single server with Docker Compose: Suited to a pilot or a small SOC, with a minimum of 4 GB RAM. Plan the changes needed for production load before go-live.
- Docker Swarm: Spreads services across hosts, so backend, frontend and Orborus placement, plus shared storage, need design work.
- Kubernetes with Helm: Fits teams that already operate clusters. Plan an OpenSearch cluster, optional Memcached and NFS for shared files when running several backends.
- Hybrid with Shuffle Cloud: The local Orborus needs no inbound firewall ports, so the on-premises footprint is the runtime. Confirm which data stays on your side under this model.
- High availability: Run more than one Orborus node so workflows keep running if one fails, and test that failover during parallel runs.
Confirm which model your security and platform policies permit before you choose a target.
Questions buyers ask before moving from XSOAR to Shuffle
How long does a migration from Cortex XSOAR to Shuffle take?
No single duration fits every estate, because the time depends on how much content you actually run. Start by counting the playbooks, integrations and SIEM triggers that are in active use, since unused content is usually retired rather than rebuilt. The main drivers are the number of playbooks to rebuild, whether custom integrations need new Shuffle apps, how many detection triggers must be recreated in the SIEM, and whether you keep XSOAR running alongside Shuffle for each use case during validation. Ask any provider for a timeline in the written scope, broken down by use case, so you can see which parts depend on your own change windows and approvals.
What drives the cost of moving from XSOAR to Shuffle?
The cost is made up of several components, and each one is paid to a different party. Shuffle's open-source edition includes all features, so the software itself does not carry a license fee, but you pay for the servers that run the backend, the OpenSearch storage behind it, and the staff time to rebuild content. Shuffle's install guide sets a minimum of 4 GB of RAM, and high availability needs more nodes. Other recurring costs include app development for integrations without a premade app, paid tiers if you need their limits or support, and any retainer for upgrades and monitoring. The one-time costs are the migration work itself. When you request a quote, ask for each component separately, along with the assumptions behind it.
Can our own team migrate from XSOAR to Shuffle without outside help?
A capable in-house team can migrate, provided it has experience running containers, working with Python and managing secrets. The harder parts are design decisions rather than bulk copying: running OpenSearch and multiple Orborus nodes for high availability, protecting the secret used to encrypt saved app credentials, setting up single sign-on, and deciding where incident handling lives, because Shuffle does not ship XSOAR-style incident layouts or a war room. Many teams keep ownership of day-to-day operations and bring in outside help for fixed parts of the work. DeployOpen plans, implements and hardens self-hosted platforms in your own environment, and its engagements are fixed-scope, with scope and deliverables agreed in writing before work starts.
What does a Shuffle migration need from our side?
The migration needs your people more than your software. Plan for named owners of each playbook and integration, access to XSOAR for the export, administrator access to your SIEM so incident triggers can be recreated, and the credentials or API keys each integration uses. Analysts who run the current playbooks should validate the rebuilt workflows against real past cases, and your change board will need to approve the cutover. You also need a decision on where cases are tracked during the transition, and an owner for the Shuffle servers after go-live, including backups and upgrades. Confirm these responsibilities in the written scope before work begins.
Do XSOAR playbooks convert to Shuffle automatically?
No, playbooks do not convert automatically, so you should plan to rebuild the logic in Shuffle. XSOAR lets you export all custom content from Settings, Server Settings, Custom content, Export all custom content, and you can download individual playbooks from the content item menu. That export gives you a record of the logic, inputs and integration calls, which is useful as a specification. Shuffle workflows are created in its own editor, and integrations are rebuilt either from OpenAPI specifications in the App Creator or as Python apps using the Shuffle app SDK, then run as versioned Docker containers. Before rebuilding, inventory which playbooks and integrations are still in use, and confirm with your provider how each one will be handled.
How does Shuffle's licensing by app runs affect the budget?
Shuffle's paid licensing is priced on app runs, which means actions that actually execute inside a workflow. Triggers and skipped actions are not counted, and users, apps and workflows are unlimited. If you use the open-source edition, all features are available, so the app-run metric matters mainly when you move to a paid tier for its limits, scaling or support. Since version 2.1.1, the limits between the open-source and enterprise editions are actively enforced. To budget accurately, measure how many actions your current XSOAR playbooks execute per day, then ask the vendor to confirm how that volume maps to app runs. Shuffle's pricing article describes the metric in full.
How DeployOpen scopes and runs this migration
DeployOpen is a Chainscore Labs company that plans, implements, integrates, hardens, backs up and documents self-hosted open-source platforms inside the client's own infrastructure, whether that is a cloud account, a data center or an air-gapped network. For a move from Cortex XSOAR to Shuffle, that work covers standing up the Shuffle server and its OpenSearch store, deciding between the Docker Compose, Docker Swarm or Kubernetes architectures, configuring more than one Orborus node where workflows must keep running, and rebuilding the playbooks and integrations you choose to keep. Before any of that starts, the scope should name which XSOAR playbooks, integrations and SIEM triggers are in, which are retired, and which SOC use cases run side by side during the transition.
Most engagements are fixed-scope. Scope, deliverables and timelines are agreed in writing before work starts, and a quote follows from that written scope rather than from a published price list. When you request a quote, ask for the scope to list each playbook and integration to be rebuilt, each SIEM trigger to be re-created, the secrets and encryption setup to be handled, the parallel-run criteria and the handover documentation. Ask how the SHUFFLE_ENCRYPTION_MODIFIER value will be generated, stored and backed up, since losing or changing it breaks saved app authentications. Check which items are one-time work and which recur, and confirm any timeline with the written scope rather than with this page.
Ongoing support, upgrades and continuous testing are available as retainers, which suits teams that will keep changing playbooks after cutover or that need Shuffle upgraded between releases. Retainer terms, response expectations and what a retainer excludes should appear in the same written agreement as the migration scope, so the handover and the ongoing support model are clear before work begins. DeployOpen prepares systems, controls and evidence for compliance assessments but does not issue audit reports, attestations or certifications, so any evidence you need for an independent assessment is a deliverable to specify in advance, with the assessor named by you.
