Replacing QRadar SOAR playbooks with an open-source alternative
Shuffle covers playbook orchestration, but the case management tool is a separate choice, and the privacy breach response tasks have no direct equivalent. That is the core of this section for a QRadar team weighing SOAR after a renewal, a cost review or a data residency requirement. IBM presents QRadar SOAR as a separate product from QRadar SIEM, offering dynamic playbook orchestration, incident response case management and privacy breach response tasks covering more than 200 regulations. Because the SOAR product stands apart from the SIEM, the decision about playbooks and cases can be made on its own timeline, without forcing a decision about the SIEM at the same time.
Shuffle is an open-source SOAR platform that began in mid-2019 for the CERT and SIRT community, and its code is licensed under AGPL-3.0. It can run in your own infrastructure through Docker Compose, Docker Swarm, Kubernetes with Helm charts, or a hybrid model with a local Orborus runtime. Its paid tiers differ in feature limits, scaling and support rather than in core functions, so confirm with Shuffle which limits apply to your planned workflow volume. Shuffle does not replace a case management tool, so the team should choose one, and confirm how it links to Shuffle workflows. The privacy breach response tasks are the part to plan around. Confirm with your privacy office which regulatory notification steps must be tracked in a case, and build them as explicit fields, checklists and approval steps in your chosen case tool rather than assuming an equivalent exists.
This page covers the playbook and case management side of QRadar SOAR, the integration rebuild, and the gaps that remain. The outcome depends on your playbook and integration inventory: how many playbooks you run, which connectors they call, which of them are triggered by QRadar offenses, and which regulated notification steps they carry. Build that inventory first, because it determines the effort, the hosting footprint and whether Shuffle fits your workflows.
Which QRadar SOAR capabilities map to open-source options
This table maps each main QRadar SOAR capability to Shuffle, a second self-hosted tool, or work your team must build or confirm. Read the coverage notes as a gap list: the entries marked for a second tool or custom work are where migration effort concentrates.
| Capability | Open-source option | Coverage notes |
|---|---|---|
| Dynamic playbook orchestration | Shuffle workflows | Shuffle covers visual workflow orchestration with branching and triggers. Rebuild each SOAR playbook as a workflow and test it against sample incidents before retiring the original. |
| Incident response case management | Self-hosted case tool alongside Shuffle | Shuffle runs automation but is not a case register for analyst work. Pair it with a self-hosted case tool such as TheHive or Cortex-compatible successors, and confirm the chosen tool's current maintenance status. |
| Privacy breach response tasks | Manual or custom procedures | No equivalent in Shuffle or typical open-source case tools. QRadar SOAR's built-in tasks covering more than 200 regulations must be rebuilt as your own checklists, notification templates and workflow steps, and reviewed by your privacy and legal teams. |
| Integrations and app creation | Shuffle apps from OpenAPI or Python SDK | Shuffle builds apps from OpenAPI specifications in the App Creator or in Python with the app SDK, and runs them as versioned Docker containers. Each QRadar and SOAR integration needs a rebuilt app or a validated API call, so inventory them before migration. |
| Single sign-on | Shuffle SAML and OpenID Connect | Shuffle supports SAML, added in version 0.9.16, and OpenID Connect, added in 1.0.0, both on-premises and in the cloud, with per-tenant SSO enforcement. SAML is being deprecated on Shuffle Cloud, so prefer OpenID Connect for new deployments and confirm the current behavior in your edition. |
| Secret and credential handling | Shuffle AES-256 encryption with SHUFFLE_ENCRYPTION_MODIFIER | Saved app credentials and API keys are encrypted in OpenSearch with AES-256. Losing or changing the modifier secret breaks all saved app authentications, so store it in a secrets manager and back it up with your keys. |
| High availability | OpenSearch cluster, shared files and multiple Orborus nodes | Shuffle documents an OpenSearch cluster, NFS for shared files across backends and more than one Orborus node so workflows continue if one fails. Your team must size and operate this layer, and confirm it meets your availability targets. |
| Playbook history and audit trail | Shuffle execution records plus case tool history | Confirm which workflow execution records and case changes Shuffle and your case tool retain, and whether they meet your evidence and retention requirements. Export these before decommissioning QRadar SOAR. |
Which open-source option fits which SOAR team
QRadar SOAR combines playbooks, case management and privacy breach response in one product, so the replacement decision starts with where your incident cases live today. The four options below range from automation only, to automation paired with a case tool, to a hybrid control plane, to a staged exit that keeps QRadar SOAR running while the new stack is built.
Shuffle alone for ticket-anchored cases
This fits teams whose cases already live in a SIEM, ticketing or ITSM system and who need Shuffle mainly to run playbooks that enrich alerts, query tools and open or update tickets. Shuffle's server runs as a single Docker Compose host, Docker Swarm, Kubernetes with Helm, or a hybrid, so the deployment choice drives your operating model. The trade-off is that Shuffle does not replace a dedicated case record with privacy breach tasks, so you must confirm that your ticketing system can hold the evidence, approvals and regulatory deadlines you need.
Shuffle paired with a case tool
This fits teams that need a system of record for incidents, with tasks, evidence, owners and audit history, and that will keep Shuffle for orchestration. Shuffle handles the automated steps, while the case tool holds the human workflow, so each playbook must write back a case identifier and status. The trade-off is a second system to host, back up and integrate, and no open-source case tool in this set is confirmed here to match QRadar SOAR's breach response templates, so confirm those features during scoping.
Hybrid with Shuffle Cloud and local Orborus
This fits teams that accept an outside control plane in exchange for less server work, with the Shuffle backend hosted by Shuffle while a local Orborus node runs the workflow workers inside your network. Shuffle documents that this model needs no inbound firewall ports on your side, which simplifies segmentation. The trade-off is a dependency on Shuffle Cloud for the control plane, so confirm where workflow definitions and credentials are stored, how an outage affects running playbooks, and whether your data residency rules permit it.
Keep QRadar SOAR during transition
This fits teams with active playbooks, regulatory breach obligations or case volumes that cannot move in one cutover. Running QRadar SOAR in parallel for a defined period lets you rebuild playbooks and integrations one group at a time and compare case outcomes before retiring anything. The trade-off is paying for two stacks while both run, so ask IBM for the current terms of your QRadar SOAR agreement and plan the exit date around renewal, not around the build schedule.
How QRadar SOAR integrations are rebuilt in Shuffle
Offense and event data is usually the first integration to rebuild, because playbooks often start from an offense, pull related events and flows, then enrich them before a case opens. Start by listing every QRadar API call a SOAR workflow makes today, including the offense, note and artifact fields it writes back. Then check the current Shuffle app catalog for a QRadar app or a generic REST app that covers those calls. If no suitable app exists, build one from the QRadar REST API specification in the App Creator, or write a Python app with the Shuffle app SDK when the logic needs custom handling. Either way, package the app as a versioned Docker container so the same build can be promoted from test to production.
- Reuse first: Check for an existing QRadar-related app before writing anything, and record its version.
- OpenAPI route: Use the App Creator when the vendor publishes a usable OpenAPI specification, and review the generated actions for authentication and pagination.
- Python route: Write a Shuffle app with the SDK for search polling, offense correlation or field mapping that a generic connector cannot express.
- Versioned deployment: Pin each app to a container tag so a change to a QRadar query cannot silently alter running workflows.
- Credential handling: Store the QRadar authorized service token in Shuffle's encrypted credential store, not in workflow variables.
Confirm with the QRadar administrator which API version and token scopes your environment supports, then test each rebuilt action against a copy of a real offense.
Ticketing and identity integrations carry case state, assignments and user lookups. They are the integrations most likely to affect who is notified and who can act, so they need the closest review by the service desk and identity teams. Inventory each action that creates, updates or closes a ticket, and each lookup against a directory or identity provider used to resolve an analyst or a user. Check whether Shuffle already provides an app for your ticketing or directory product, then rebuild only what is missing. Lookups that read identity data should use read-only service accounts, and write actions should be restricted to the minimum fields the playbook needs.
- Case and ticket sync: Rebuild create, update and close actions so each case reference is stored consistently between the case tool and the workflow.
- Directory lookups: Use read-only service accounts for user and group queries, and document which attributes the workflow reads.
- Identity actions: Treat disable-account or reset-password actions as high-impact, and add approval steps before running them.
- Authentication: Where a target supports OAuth or OpenID Connect, use it rather than long-lived passwords stored in Shuffle.
- Testing: Run each action against a staging tenant and confirm the audit trail records the same actor as the QRadar SOAR version.
Confirm with the identity and ticketing owners which fields are mandatory, which approvals apply, and whether the target system's API rate limits will affect a high-volume playbook.
Threat intelligence and endpoint tools provide enrichment and containment steps. Enrichment actions are usually low risk and read-only, while containment actions such as isolating a host or blocking an indicator change production state and need strict controls. Inventory each enrichment lookup and containment command separately, because they will be tested and approved differently. Confirm whether Shuffle has a current app for each product, and where it does not, build the app from the vendor's OpenAPI specification or write it with the SDK. Containment apps should run only from workflows that include an approval step and a logged rollback path.
- Enrichment reuse: Rebuild reputation and lookup actions first, since they are read-only and easy to validate against known indicators.
- Containment controls: Gate isolation or blocking actions behind an explicit approval and log the requesting analyst and the target.
- Rate and quota handling: Add retry and caching logic in the app where the provider limits lookups, so bursts do not stall the workflow.
- Versioning: Keep the containment app on a fixed container tag and promote changes only after a test run.
- Data handling: Confirm whether the provider is a cloud service, since indicators and file hashes sent to it leave your environment.
Confirm with the security operations lead which containment actions are permitted, which endpoint products are in scope, and how the Shuffle deployment reaches each target network.
What has no equivalent: privacy breach response tasks
The main gap in this migration is privacy breach response. IBM presents QRadar SOAR with privacy breach response tasks covering more than 200 regulations, and no equivalent is supplied for Shuffle. Shuffle gives you workflow orchestration and integrations, but it does not ship a regulation library, notification deadlines or breach-specific forms. Your team has to design that process itself and decide who owns it before cutover, because a missed notification window is a legal problem, not a tooling problem.
What you build or source falls into four groups: notification timelines for each jurisdiction that applies to your data subjects, regulator and customer notification templates, evidence capture steps (log exports, chain of custody for affected records, timestamps and approvals), and legal review gates where counsel signs off before anything leaves the organization. In Shuffle, these become workflow steps with approval actions and case fields in your case tool that record the jurisdiction, the clock start, the notification status and the evidence location. Keep the timeline logic in a reviewed table rather than hard-coded in individual workflows, so a change in law changes one place.
DeployOpen can prepare the controls, workflow design, case fields and evidence records for this process, and test that they behave as documented. DeployOpen does not provide legal advice, decide which regulations apply, or certify that your response meets any of them. Ask counsel to confirm the regulation list, the notification deadlines and the template wording in writing, and ask them to name the decision-makers for each jurisdiction. Then run a tabletop exercise against the finished workflow before you retire QRadar SOAR, so you find the gaps while the old platform is still available.
How to move playbooks, cases and credentials to Shuffle
This sequence moves QRadar SOAR automation into Shuffle in an order that protects saved credentials, keeps case history available for reference, and lets each workflow be proven before QRadar SOAR playbooks are switched off.
Inventory playbooks, integrations and triggers
The SOAR administrator lists every active QRadar SOAR playbook, the integrations and connectors each one calls, the triggers that start it (such as QRadar offenses or manual actions), and the owner who depends on it. Include functions, scripts and custom fields that playbooks read or write, because these shape how the Shuffle workflow must handle data. Rank playbooks by how often they run and how much incident response depends on them. The output is a signed-off inventory with one row per playbook and a note on whether each integration has a Shuffle app or needs a custom app built from an OpenAPI specification or the Python app SDK.
Confirm and export QRadar SOAR case history
Before any change is made to QRadar SOAR, the team confirms the export path for incident, task, note and attachment data with IBM documentation for the installed version, because the supported methods and their output formats must be verified for your release rather than assumed. Export closed and open cases that must be retained for regulatory or audit reasons, and store them in an encrypted, access-controlled archive. Record which fields and attachments did not export cleanly. The output is a verified archive with a manifest that lists case counts and any known gaps.
Build a test Shuffle deployment
The platform engineering team installs Shuffle in a non-production environment using one of the documented architectures, usually a single server with Docker Compose for a first build. They pin a specific release tag instead of the nightly tag, because the Shuffle docs reserve nightly for experimental changes. They connect a test Orborus runtime and confirm that apps start as Docker containers. The output is a working test instance where a simple workflow runs end to end and the team has recorded the release tag used.
Set the encryption secret and back it up
Before any app credential is saved, the administrator sets the SHUFFLE_ENCRYPTION_MODIFIER secret in the configuration, because Shuffle uses it to encrypt saved app credentials and API keys with AES-256 in OpenSearch. Store the value in your approved secrets manager with restricted access and a documented owner. Treat losing or changing this value as a serious incident: the Shuffle docs state that it breaks all saved app authentications, so every stored credential would need to be re-entered. Include the secret in your change control and disaster recovery records. The output is a documented, backed up secret and a test confirming that a saved credential still authenticates after a service restart.
Rebuild the highest-value playbooks first
Using the inventory, the automation engineer rebuilds the most critical playbooks as Shuffle workflows, starting with the ones that touch containment, notification or evidence collection. Re-enter each integration's credentials in the test instance, not by copying encrypted values between systems. Replace QRadar-specific logic with equivalent steps, and document any step that has no direct counterpart so the security team can decide whether to redesign it. Test with recorded sample data and with approved, non-production alerts. Where a playbook uses a feature with no equivalent in Shuffle, such as built-in privacy breach response tasks covered by QRadar SOAR's regulation library, record it as a gap for the privacy team. The output is a tested workflow set with a traceable mapping from each original playbook.
Run old and new workflows in parallel
The SOC runs the rebuilt Shuffle workflows alongside the existing QRadar SOAR playbooks for a defined observation period agreed with the incident response owner. Both paths should receive the same alerts or cases where possible, and the team compares actions taken, timing and outcomes for each one. Any difference, failed action or unexpected result is logged with a root cause and a fix. Confirm that Shuffle's execution history and case records are retained according to your policy, and that analysts know which system is authoritative for each case type. The output is a parallel-run report that a named approver signs before any playbook is retired.
Retire QRadar SOAR playbooks in stages
Once a playbook has passed the parallel run, the owner disables its QRadar SOAR trigger and moves it to a read-only or archived state, starting with low-risk groups and leaving high-impact playbooks for last. Keep the archive from the export step available for the retention period your compliance team defined, and confirm that no remaining process depends on a retired playbook. Revoke QRadar SOAR integration accounts and API tokens after the final stage, and remove stored credentials from the old platform. The output is a retirement log listing each playbook, its retirement date, the approver and the location of its archived record.
Running Shuffle beside QRadar SIEM and the rest of the stack
Shuffle sits between your detection stack and your responders, so four choices shape the whole design: how alerts arrive, where cases live, how people sign in, and how the platform survives a failure. Settle each one in writing before build work starts, because changing them later touches workflows, integrations and access.
How alerts reach Shuffle
QRadar on premises can send offenses and events to Shuffle through a webhook or a custom action that your team writes and tests against a non-production Shuffle instance. Decide which QRadar offense types trigger workflows, whether enrichment happens before or after a case is opened, and how duplicate offenses are suppressed. Confirm the exact delivery method with your QRadar version and with the Shuffle app you plan to use, because the QRadar integration is rebuilt rather than inherited from SOAR.
Where the case record lives
Shuffle runs workflows and stores execution results, but it is not a case management system with SOAR's incident lifecycle. Decide which tool owns the case, its status, assignments, timeline and evidence, and make Shuffle write back an identifier and a summary to that tool. Confirm who can edit a case, how evidence is retained for your legal hold rules, and what happens to open cases if the chosen case tool is retired.
Sign-in with SAML or OpenID Connect
Shuffle supports SAML single sign-on from version 0.9.16 and OpenID Connect from 1.0.0, both available on premises. Choose OpenID Connect for new builds, since the docs say SAML is being deprecated on Shuffle Cloud. Decide how per-tenant SSO enforcement maps to your identity provider groups, and test that disabling a user at the provider also removes access to saved app credentials and workflow editing rights.
High availability design
The documented HA pattern combines an OpenSearch cluster, optional Memcached for a shared cache, NFS for shared files when several backends run, backend and frontend scaled across servers, and more than one Orborus node so running workflows survive a node failure. Confirm the NFS performance and failover behavior with your storage team, size the OpenSearch cluster for your execution history, and plan regular backups of OpenSearch along with the SHUFFLE_ENCRYPTION_MODIFIER secret, since losing it breaks saved app authentications.
What does replacing QRadar SOAR cost and take
What are the cost components of replacing QRadar SOAR with Shuffle?
The cost falls into five components: the infrastructure to run Shuffle and its OpenSearch document database, the case management tool you pair with it, internal staff time to rebuild playbooks and integrations, app development for connectors without an existing Shuffle app, and outside support or implementation. Infrastructure and staff time are paid to your own providers and team. Shuffle's own licensing is a separate line, so confirm with Shuffle which edition and feature limits your use case needs before you size anything. Ask any partner for each component as a separate line in the written scope.
Which costs are one-time and which recur after a SOAR migration?
One-time costs include the initial build of the Shuffle environment, rebuilding each playbook and integration, testing, cutover and documentation. Recurring costs include hosting and storage for the OpenSearch cluster and the servers or Kubernetes nodes, licensing or subscriptions for any paid Shuffle tier and the case tool, backups, patching and upgrades, and ongoing maintenance of app containers as vendors change their APIs. Because Shuffle apps run as versioned Docker containers, expect upgrade and regression work to recur on every platform release.
How does Shuffle's licensing metric of app runs affect the cost?
Shuffle prices its licensing on app runs, which are actions that actually execute in a workflow. Triggers and skipped actions are not counted, and users, apps and workflows are unlimited. This means cost follows automation volume, not headcount or the number of playbooks. Playbooks with many enrichment steps that run on every alert will consume more runs than playbooks that stop early. To estimate, ask Shuffle for its current app run definition in writing, then model your alert volume against the number of executed actions per playbook.
What should I ask for in a quote for a QRadar SOAR replacement?
Ask for a written, fixed scope that lists each playbook and integration to be rebuilt, the target deployment architecture, and the high availability design, including the OpenSearch cluster, shared storage and the number of Orborus nodes. Request separate line items for infrastructure you provide, licensing, the case tool, app development per integration, testing, cutover, documentation and handover. Ask which items are one-time and which are recurring, what is excluded, and how changes to scope are priced. DeployOpen does not publish a price list, and a quote follows from that written scope.
What drives the effort up when replacing QRadar SOAR playbooks?
Effort rises with the number of integrations that lack a ready Shuffle app, the complexity of each playbook (branching, loops, error handling and approval steps), the number of distinct QRadar SOAR case types and custom fields, and the amount of data mapping between tools. Privacy breach response workflows add more work because they combine tasks that have no built-in equivalent and need legal and compliance review. Each integration you build from an OpenAPI specification or the Python SDK should be tested against the real vendor API before cutover.
Can our team replace QRadar SOAR without outside help?
Some teams can, especially where they already run Docker, have OpenSearch skills and maintain their own playbooks. A capable internal team still needs time for architecture, integration rebuilds, testing and documentation, and needs people who own the case tool and the secrets. Shuffle stores app credentials encrypted with a secret that must not be lost, so key management and backup procedures need a named owner. Assess your team against these skills honestly, and if you engage DeployOpen, the work runs on a fixed scope agreed in writing before it starts.
What does the work need from our team during a migration?
You need a process owner for each playbook who can confirm the expected outcome, an engineer who can provision servers or Kubernetes, and an administrator for the identity provider if you use SAML or OpenID Connect single sign-on. You also need access to each integrated tool's API and service accounts with the right permissions, plus people who can approve test cases and cutover windows. Plan for parallel running, where alerts go to both QRadar SOAR and Shuffle, so that analysts can compare outcomes before retiring the old playbooks.
How DeployOpen scopes and delivers a SOAR replacement
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, including the Shuffle automation platform and the case tooling that sits beside it. We start from an inventory of your QRadar SOAR playbooks and integrations, then agree the scope in writing before any build work begins.
How we scope
- Inventory every QRadar SOAR playbook, function and integration, marking which ones are active and which are retired.
- Record which privacy breach response tasks need a manual or separately built process, since no open-source equivalent is assumed.
- Agree deployment architecture, identity integration and hosting location in the written scope before work starts.
How we build
- Deploy Shuffle in the architecture your environment requires, such as Docker Compose, Docker Swarm, Kubernetes with Helm, or a hybrid with a local Orborus.
- Rebuild each integration as a Shuffle app from an OpenAPI specification or with the Python app SDK, then test it against a non-production system.
- Configure SSO through SAML or OpenID Connect and set the SHUFFLE_ENCRYPTION_MODIFIER secret under your own key handling process.
How we hand over
- Document each workflow, its triggers, its app dependencies and its owner, so the runbook matches what is deployed.
- Deliver backup and restore procedures for the OpenSearch document database and the encryption secret, tested before cutover.
- Provide a parallel-run record comparing old QRadar SOAR case outcomes with new Shuffle executions before retirement.
How we support
- Fixed-scope engagements have scope, deliverables and timelines agreed in writing before work starts, with a quote following from that scope.
- Ongoing support, upgrades and continuous testing of workflows and integrations are available as a retainer.
- Security testing of the automation platform and its integrations can be scoped separately, so that connected systems are checked after changes.
