Which SOAR fits your SOC: QRadar SOAR or self-hosted Shuffle?
If your renewal is driven by per-user licensing, or you want the automation logic in infrastructure you control, the question is which platform your SOC can run well over the next several years. QRadar SOAR fits better when your case workflows are already established and tied to the IBM stack, when your team relies on vendor support obligations, and when your incident process depends on the Playbook Designer and the integrations IBM maintains. Those are real reasons to stay, especially if your analysts know the case model and your audit evidence already lives there. Confirm with IBM which integrations and on-premises versions your contract covers before you assume continuity.
Self-hosted Shuffle fits better when you want broad analyst access to build and edit workflows without adding a seat for each person, and when app-run pricing and the open-source edition change how you think about growth. Shuffle's licensing is based on app runs, meaning actions that actually execute, and users, apps and workflows are unlimited under its pricing model. Its architecture asks more of your team: a single server runs on Docker Compose, but the documentation says that setup is not scalable without changes and needs at least 4 GB of RAM. High availability means an OpenSearch cluster, a shared cache, shared files, and more than one Orborus node, and your team must own the upgrade cycle and the SHUFFLE_ENCRYPTION_MODIFIER secret that protects saved app credentials.
The decision turns on four things you can measure now: how many people must build or run automation, how many playbooks you will keep and how often they execute, whether your team has the operational capacity to run OpenSearch, workers and backups, and how many of your tools have an existing Shuffle app or an OpenAPI definition for a custom one. Count each in your environment and map it against QRadar SOAR's current playbook and integration inventory. Then ask Chainscore's implementation team, or your own engineers, to pilot your two highest-value playbooks on a test instance before you commit to either platform.
Which platform fits which SOC scenario
This table matches common SOC conditions to the platform that usually fits better, with the reason and the condition that would reverse the choice. Read each row against your own analyst count, playbook volume, data rules and staffing before you decide. The main takeaway is that per-user licensing and data residency favor Shuffle, while container skills and an existing QRadar estate can keep IBM QRadar SOAR the simpler choice.
| Scenario | Better fit | Why | The other option wins when |
|---|---|---|---|
| Large analyst pool on per-user licenses | Shuffle | Shuffle's pricing article says users are unlimited and licensing is based on app runs, so adding analysts adds no seat fee. | Run volume is high enough that app run charges exceed seat savings. Model both with Shuffle and IBM before deciding. |
| Small team with few playbooks | Shuffle, single-server pilot | A Docker Compose pilot on one server can prove value before a production design, but the default setup is not scalable without changes. | Few playbooks and a working QRadar SOAR setup mean migration effort may outweigh the gain. Keep IBM until playbook count grows. |
| Regulated site needing on-premises data | Shuffle, fully local components | Shuffle can run its backend, OpenSearch and Orborus inside your own network. Confirm the deployment meets your residency rules. | An approved on-premises or OpenShift QRadar SOAR baseline already satisfies the assessor and changing it adds audit work. |
| Existing IBM QRadar SIEM estate | IBM QRadar SOAR | Staying in the same vendor family keeps offense-to-case handoffs on known integrations. Confirm the current integration version with IBM. | QRadar SIEM is being reduced and alerts come from several tools. Confirm Shuffle apps cover your sources before moving. |
| Team without container operations skills | IBM QRadar SOAR on its existing platform | Shuffle depends on Docker or Kubernetes, starts app containers for each run and needs an OpenSearch cluster for high availability. | The team hires or trains container skills, or uses the hosted shuffler.io service with a local Orborus under the hybrid model. |
| Heavy custom integrations with internal tools | Shuffle | The App Creator builds apps from OpenAPI specifications and the Python SDK produces versioned containers, which suits in-house APIs. | Most integrations are vendor-maintained content that your team would otherwise rebuild. Count those before choosing. |
Where incident data lives and who controls the platform
Moving from IBM QRadar SOAR to Shuffle changes where case records, playbook logic and saved credentials sit and who can change them. The four cards below cover the hosting models Shuffle documents, the license split that governs internal changes, and the identity and compliance work that follows whichever model you choose.
Single server with Docker Compose
This is the simplest Shuffle deployment: one host runs the frontend, the Go backend and OpenSearch through Docker Compose, with Orborus on the same machine. All incident-related data stays on that host, so backups, disk encryption and access to the server become your responsibility. The install guide states the default Compose setup is not scalable without changes and needs at least 4 GB of RAM. Confirm with your own architects whether a single host meets your availability target before you plan the cutover.
Distributed Docker Swarm
Swarm spreads the Shuffle backend, frontend and workers across several hosts. Shuffle's high-availability guidance adds an OpenSearch cluster, a shared cache and NFS for shared files, and more than one Orborus node so running workflows survive a node failure. Your team then owns cluster membership, storage and network policy for the Swarm, which is a larger operating surface than a single server. Ask who will patch the hosts and rotate the OpenSearch certificates.
Hybrid with local Orborus
In the hybrid model the control plane runs on Shuffle Cloud while a local Orborus executes workflows inside your network. Shuffle documents that this needs no inbound firewall ports, because the local runtime polls the backend for jobs. Your app credentials and the containers that call internal tools still run in your environment, but case and workflow metadata sit with the hosted service. Confirm exactly which records the cloud component stores before you classify this model for data residency.
Kubernetes with Helm charts
Shuffle also documents deployment on Kubernetes using Helm charts, which suits organizations that already operate a cluster with their own backup, policy and identity tooling. Data placement then depends on your storage classes and the OpenSearch volumes you provision. Keep the SHUFFLE_ENCRYPTION_MODIFIER secret in your secrets store, because losing or changing it breaks every saved app authentication. Ask your platform team which controls they will map to the cluster for audit evidence.
How Shuffle's architecture changes the operating model
Running Shuffle on your own infrastructure means operating a multi-part system rather than a single application. The server side has a frontend and a Go backend API listening on port 5001, backed by an OpenSearch document database (Elasticsearch also works). The runtime side is Orborus, which polls the backend for jobs, starts a worker for each workflow execution, and that worker launches the app containers that do the actual work. QRadar SOAR's on-premises virtual appliance hides most of this from the administrator. With Shuffle, your team owns each tier, so the first decision is which deployment architecture you choose: a single server with Docker Compose, distributed Docker Swarm, a hybrid with Shuffle Cloud and a local Orborus, or Kubernetes with Helm charts. Confirm which of these your security and change-control processes can support before comparing costs.
The default Docker Compose setup is suitable for evaluation, not production scale. The install guide states it is not a scalable build without changes, and it needs a minimum of 4 GB of RAM. Plan the minimum for the backend, frontend, OpenSearch and Orborus, then size up for your alert volume. For high availability, the configuration docs describe an OpenSearch cluster, an optional Memcached instance for a shared cache, NFS for shared files when several backends run, backend and frontend services scaled across servers, and more than one Orborus node so workflows keep running if one node fails. Each of these is a component your team patches, monitors and backs up. Ask your provider or internal platform team to confirm the sizing and failover tests they will run before go-live.
Two operational details deserve early attention. First, 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 store it in your secrets manager and include it in your backup and recovery runbook. Second, the configuration docs cover SSO through SAML and OpenID Connect, and SAML is being deprecated on Shuffle Cloud in favor of OpenID Connect. Confirm which option your identity provider supports and document the decision. Together these items move effort from licensing into platform engineering, which is a shift your budget and staffing plan should reflect.
What each platform costs to own, by component
Owning either platform costs more than the license or the software. The cards below separate the recurring commercial charges from the infrastructure, staffing and migration work that sits on your side of the contract. Use them to structure quote requests so both options are priced on the same components.
QRadar SOAR per-user licensing
IBM QRadar SOAR is licensed per Authorized User, with an annual subscription and support fee. Your cost rises with every analyst, responder or integration account that needs access, so the count of named users is the main driver. Ask IBM to confirm how service accounts, read-only auditors and API users are classified, and whether the subscription renews automatically and at what uplift. This is a recurring cost.
QRadar SOAR platform hosting
The QRadar SOAR software runs as a virtual machine or on OpenShift in your environment, so you also pay for compute, storage, backups and the hypervisor or cluster licenses underneath it. These costs recur with each hardware refresh or cluster renewal and grow with the number of sites you run. Confirm which infrastructure licenses IBM expects you to hold and which parts of the upgrade cycle your team must staff.
Shuffle app-run metering
Shuffle's paid tiers price on app runs, which count only actions that execute inside a workflow. Triggers and skipped actions do not count, and users, apps and workflows are unlimited. Cost therefore follows alert volume and how many automated steps each playbook performs, so review a sample of your busiest workflows before comparing tiers. Ask Shuffle to show the app-run count for those workflows and how overages are billed.
Shuffle infrastructure and OpenSearch
The open-source edition runs on your servers, and the install guide sets a minimum of 4 GB of RAM for the platform. Production use also needs an OpenSearch cluster, more than one Orborus node and shared storage for multi-backend setups, which adds nodes, backups and monitoring. These are mostly one-time build costs plus recurring compute. Size the cluster against your execution volume and alert retention, not against the minimum.
Migration labor
Moving from QRadar SOAR means inventorying playbooks, functions and integrations, rebuilding them as Shuffle workflows, and reconnecting alert sources. This work is mostly one-time and is usually the largest early cost, so it is the item most worth scoping in writing. Ask for a fixed list of workflows, integrations and cutover steps, and confirm whether the quote covers parallel running and rollback.
Staff who maintain workflows and apps
On Shuffle, your team or a partner owns the workflows, the OpenAPI-built apps and the upgrades, so the recurring cost is people time and support. Each new integration or Shuffle release adds maintenance. Credentials depend on the encryption secret, so losing it breaks saved app authentications. Estimate the time your analysts and engineers will spend on this against what IBM's support covers today, and ask whether a retainer would cover upgrades.
What moving from QRadar SOAR to Shuffle involves
The sequence moves playbooks, app integrations and incident records from QRadar SOAR into a self-hosted Shuffle environment, with each stage proven before the next begins. The end state is Shuffle running live response work, with QRadar SOAR retired and closed cases still retrievable for audits.
Inventory playbooks, functions and app integrations
The team lists every active playbook, custom function, scripted action, integration and connected alert source in QRadar SOAR, along with the owner and the last date each ran. This work is done by the SOAR administrator with input from the analysts who use the playbooks. It is done when each item is tagged as rebuild, retire or replace, and the list is signed off by the SOC lead. Ask IBM or your own admin team for an export of the playbook and function definitions so nothing is missed from memory.
Rebuild automation as Shuffle workflows
Each retained playbook is rebuilt as a Shuffle workflow. Integrations with a published OpenAPI specification can be generated in the App Creator, while the Shuffle app SDK in Python covers tools that need custom logic. Engineers test each app against the vendor's sandbox or a lab system and version the apps as Docker containers. The step closes when every workflow has passed a test run with recorded inputs and outputs that match the old playbook's behavior.
Decide where incident records and tasks will live
Shuffle is an automation platform, so the team must decide where cases, tasks, comments and evidence will be recorded going forward. The options include an existing ticketing or case tool that analysts already use, or a separate case store. The SOC lead, the compliance lead and the data owner make this decision together, because it sets the retention and access rules for incident data. The step is complete when a written data flow shows each record type, its system of record and who can read it.
Set up the Shuffle environment and protect secrets
The platform team deploys Shuffle on the chosen architecture, whether Docker Compose on a single server, Docker Swarm, a hybrid setup with local Orborus, or Kubernetes with Helm. Saved app credentials are encrypted with the SHUFFLE_ENCRYPTION_MODIFIER value, so that value must be generated, stored in the organization's secrets process and backed up before any credentials are entered. Losing or changing it breaks every saved app authentication. The step is done when a test workflow runs end to end and the encryption key is confirmed to exist in two separate secure locations.
Run Shuffle and QRadar SOAR in parallel
For a defined period agreed in advance, both platforms process the same alerts. The analysts compare the actions each platform takes, the case records each creates and any failed runs. Differences are logged as defects and fixed in the Shuffle workflows, and the team checks that high-impact actions such as containment or account changes are not triggered twice. The step closes when the SOC lead signs off that the gaps are resolved and that every active playbook has a passing comparison.
Cut over alert sources from QRadar SIEM and other tools
The alert feeds from QRadar SIEM and any other detection tools are repointed to Shuffle, one source at a time, starting with the lowest-risk source. The platform team updates the webhook or API configuration in each source and confirms that alerts arrive, trigger the expected workflow and are logged. Rollback steps are written down for each source before its switch. The step is complete when each source sends alerts to Shuffle and no source still depends on QRadar SOAR for triggering.
Retire old playbooks and keep closed cases for audit
Once cutover is confirmed, QRadar SOAR playbooks are disabled, then removed from active use while the platform is kept for a retention window set by the compliance lead. Closed incident records are exported or archived in a readable format and tested for retrieval, so auditors can see the history of past cases. Ask your auditor or compliance team which record types and retention periods they require before deciding the archive scope. The step closes with a signed retirement record and a tested archive restore.
Questions buyers ask before switching SOAR platforms
What does it cost in effort and money to switch from IBM QRadar SOAR to Shuffle?
The main cost is people time, not the software itself, because Shuffle's open-source edition carries no per-user fee. Expect one-time costs for inventorying playbooks, rebuilding them as Shuffle workflows, writing or adapting apps, testing and cutover. Recurring costs include the servers or Kubernetes capacity Shuffle runs on, OpenSearch storage, backups, and the engineers who maintain workflows and upgrades. The effort rises with the number of playbooks, custom Python functions and integrations that have no matching app. Ask DeployOpen and any other implementation partner for a fixed-scope quote built from your written inventory, and ask IBM to confirm your current subscription and support terms before you plan the exit date.
How long does a migration from QRadar SOAR to Shuffle take?
The pace is set by the size and complexity of your playbook library, how many integrations need new or adapted apps, and how many alert sources must be re-pointed. Playbooks that call well-supported tools are quicker because Shuffle ships premade apps for many security tools and can build apps from OpenAPI specifications. Playbooks with custom Python functions, unusual data mappings or strict change control take longer. Your analysts' availability for parallel testing also matters, since running old and new automation side by side usually sets the final timeline. Ask for a schedule that is tied to a written scope with milestones for inventory, build, test and cutover, rather than a single end date.
Can a small in-house team run Shuffle on its own?
Yes, in many cases, but it depends on the skills you already have. Shuffle has documented deployment options, including a single server with Docker Compose, Docker Swarm, a hybrid model with Shuffle Cloud, and Kubernetes with Helm charts. The install guide states that the default Docker Compose setup is not scalable without changes, so production use needs planning for high availability, which the configuration docs describe as an OpenSearch cluster, more than one Orborus node and scaled backends. Your team must own patching, backups, secrets and workflow ownership indefinitely. Confirm with Shuffle which features and support levels your chosen tier includes, and decide whether to build that capacity or buy ongoing support as a retainer.
What do we need from our own team for a Shuffle migration?
Three inputs drive most of the work. First, a complete playbook inventory: every QRadar SOAR playbook, function, custom field, incident type and integration, with its owner and last-run date. Second, named infrastructure owners who can provision the servers or Kubernetes cluster, DNS, certificates, identity provider connections and firewall rules, including whether a hybrid Orborus needs no inbound ports. Third, analysts who can run test incidents, validate outputs and sign off on each workflow before cutover. Without these, scope estimates are unreliable. Ask any implementation partner to list the inputs they need in writing before work begins.
Does Shuffle's open-source edition cover the features we use, and how do the enforced limits apply?
Shuffle states that all features are available in its open-source edition and that paid tiers differ in feature limits, scaling and support. Since version 2.1.1, the limits between the open-source and enterprise editions are actively enforced, so you should not assume that a feature you saw in a demo is unlimited on your tier. Map each capability you use, such as case management, SSO, scaling or support hours, against the current open-source article and configuration docs, and get the enforced limits in writing from Shuffle before you commit. The current Shuffle release on GitHub is v2.3.0, and the docs recommend pinning the Docker tag you test against.
Does Shuffle's app-run pricing grow as our alert volume grows?
Shuffle's paid licensing is based on a single metric, app runs, which counts actions that actually execute in a workflow. Triggers and skipped actions are not counted, and users, apps and workflows are unlimited, according to its pricing article. That means cost can grow with automation volume, so estimate app runs from your alert rates and the number of actions per playbook, and compare that with your current per-user model. Ask Shuffle to confirm how app runs are counted for your workflows, whether the open-source edition has any run limits, and how overages are billed.
How are the encryption modifier and backups handled in a self-hosted Shuffle setup?
Shuffle encrypts saved app credentials and API keys in OpenSearch with AES-256, using the SHUFFLE_ENCRYPTION_MODIFIER secret. The configuration docs warn that losing or changing this value breaks all saved app authentications, so store it in your secrets manager, record it in your change process and never regenerate it casually. Backups must cover the OpenSearch data, the workflow definitions and the encryption secret together, because a database restore without the matching secret leaves credentials unusable. Test restores in a separate environment and confirm with Shuffle how your chosen deployment expects backups to be taken.
When staying on QRadar SOAR is the right call
Staying on QRadar SOAR is often the right decision when the SOC depends on IBM-supported integrations and contractual vendor support that a self-maintained platform cannot match. If your playbooks call IBM-maintained connectors, if your audit or procurement rules require a named vendor to answer for defects and security fixes, or if your incident process is tightly coupled to an existing QRadar SIEM estate, the switching risk sits in the integrations and the support contract, not in the workflow logic. Before you decide, export your integration inventory and check each connector against what Shuffle ships as premade apps or can build from an OpenAPI specification. Any connector that exists only as an IBM-maintained component needs a replacement plan with a named owner, or it stays where it is.
The cost comparison can also favor IBM once you count the operating side of Shuffle honestly. Shuffle's own documentation describes several deployment patterns, and its high-availability guidance recommends an OpenSearch cluster, a shared cache, shared file storage when several backends run, and more than one Orborus node so workflows keep running if one fails. Its install guide also notes that the default Docker Compose setup is not scalable without changes and needs at least 4 GB of RAM. If your team cannot staff that platform engineering work, or if your volume is low enough that per-user licensing costs little relative to the infrastructure, a like-for-like cost model may not favor migration. Ask IBM for the current per-user pricing and subscription terms in writing, and compare them with a costed Shuffle design covering servers, storage, backups, upgrades and maintainer hours.
Confirm the on-premises upgrade cycle with IBM before you treat staying as a long-term option. Support windows for each on-premises release, and whether your OpenShift or virtual machine deployment has a specific upgrade path, should come from IBM's current lifecycle documentation and your account team, not from this page. Once you have those dates, use the IBM QRadar SOAR on-premises upgrades: keep current or replace decision page to weigh the upgrade effort against a migration. Document the decision, the review date and the trigger that would reopen it, such as a support end date or a change in integration needs.
How DeployOpen helps you evaluate, implement or migrate Shuffle
DeployOpen is a Chainscore Labs company that plans, implements, hardens, backs up, upgrades and documents self-hosted open-source platforms inside your own infrastructure, including your cloud accounts, data centers or air-gapped networks. For Shuffle, the work usually starts with an evaluation: an inventory of your QRadar SOAR playbooks, functions and app integrations, sorted into those that map cleanly to Shuffle workflows, those that need a custom app built from an OpenAPI specification, and those that depend on IBM-specific behavior you may choose to retire. The output is a written fit check that tells you which automations move, which need rework and which should be dropped before any migration budget is committed.
Implementation covers the deployment architecture you choose from the four Shuffle documents describes, whether a single server with Docker Compose or Kubernetes with Helm charts, along with the high availability pieces the configuration docs recommend: an OpenSearch cluster, more than one Orborus node and shared files for multiple backends. Hardening includes SSO through SAML or OpenID Connect, handling of the SHUFFLE_ENCRYPTION_MODIFIER secret that protects saved app credentials, and backups that include that secret and the OpenSearch data. Every engagement is fixed-scope, so deliverables, environment details and acceptance criteria are agreed in writing before work starts. Ask any vendor, including us, to show exactly which items sit inside that written scope.
Migration support covers rebuilding playbooks as Shuffle workflows, configuring app connections, and cutting over alert sources in phases so that running automations are not interrupted. DeployOpen also prepares documentation and evidence for your compliance readiness work, but it does not issue audit reports, attestations or certifications; independent auditors and certification bodies perform those. Ongoing upgrades, patching and continuous security testing are available as optional retainers, so you can keep Shuffle current after go-live. DeployOpen does not publish a price list. A quote follows from the written scope, so ask for the scope items, the environment assumptions and the recurring versus one-time components before you compare it with your current IBM renewal.
