Does self-hosting IBM QRadar SOAR cost less with Shuffle?
Self-hosting Shuffle often removes the largest line item in a QRadar SOAR renewal, the per-user license, but the total cost moves rather than disappearing, so the answer depends on your own numbers. IBM QRadar SOAR is licensed per Authorized User with an annual Subscription and Support charge, and it runs on a virtual machine or OpenShift that your team also pays to operate. Shuffle's open-source edition has no per-user fee. According to the Shuffle pricing article, its paid tiers are priced on app runs, meaning actions that execute in a workflow, while users, apps and workflows are unlimited. Model automation volume, not headcount, when you estimate that line.
The costs that move to your side are infrastructure, migration and staff time. Shuffle needs at least 4 GB of RAM per its install guide, and the default Docker Compose setup is not scalable without changes. For high availability, the configuration docs recommend an OpenSearch cluster, Memcached, NFS for shared files and more than one Orborus node, so a production build needs more servers, storage and monitoring than a single appliance. Migration is largely one-time work: inventorying playbooks and integrations, rebuilding them as workflows and testing them. Recurring effort is the person or team who maintains workflows and apps. Back up the SHUFFLE_ENCRYPTION_MODIFIER value with the same care as your database, because losing it breaks every saved app credential.
Before you compare totals, request a written QRadar SOAR renewal quote that states the Authorized User count, the Subscription and Support term and the hosting costs for your VM or OpenShift environment. Then size the Shuffle deployment against the Shuffle architecture docs, estimate monthly app runs from your current automation volume and record the staff hours your team spends on workflow upkeep today. Ask any implementation partner for a fixed scope in writing that lists migration and hardening work separately from ongoing support. A fair comparison is built from your own quote and your own staffing, not from a generic per-seat figure.
Which cost components change when you move from QRadar SOAR to Shuffle
This table sets each QRadar SOAR cost component against its Shuffle counterpart and marks whether it is one-time or recurring. Read it as a checklist for building a like-for-like quote, since the largest shifts come from who maintains the platform and who pays for the workflow migration. The main takeaway is that licence savings are only one side of the comparison, and the self-hosted side carries sizing, high availability and staff time that must be priced explicitly.
| Cost component | IBM QRadar SOAR (commercial side) | Shuffle (self-hosted side) | One-time or recurring |
|---|---|---|---|
| Subscription and support | Annual Subscription and Support, licensed per Authorized User | Open-source edition has no per-user fee; confirm current paid tier terms and app-run limits with Shuffle if you need enterprise features | Recurring |
| VM or OpenShift platform | Virtual machine or OpenShift cluster that hosts the QRadar SOAR instance | Host or cluster for Shuffle, deployed by Docker Compose, Docker Swarm, or Kubernetes with Helm charts | Recurring (infrastructure) and one-time (initial build) |
| Servers and storage for Shuffle | Covered within the platform line above | Frontend, Go backend, OpenSearch, and one or more Orborus nodes; minimum of 4 GB RAM per the install guide, and the default Docker Compose setup is not scalable without changes | Recurring; sizing grows with execution volume and HA design |
| High availability design | Depends on the chosen QRadar SOAR deployment and platform redundancy | OpenSearch cluster, shared cache, NFS for shared files, and more than one Orborus node, per Shuffle configuration docs | One-time design and build, then recurring run cost |
| Implementation | Installation and configuration of the QRadar SOAR environment, typically through IBM or a partner, confirm with your provider | Platform build, SSO setup, secrets handling, and network design, scoped in writing with an implementation partner or internal team | One-time |
| Migration of playbooks and integrations | Existing Playbook Designer workflows, functions and integrations stay in place until rebuilt | Inventory, then rebuild as Shuffle workflows and apps (App Creator or Python SDK); cost depends on playbook count and custom functions | One-time, sized by inventory |
| Support, retainers and upgrades | IBM support under the subscription; upgrade effort on each on-premises release cycle | Community support or paid tiers; upgrades, patching and monitoring are your responsibility or a retainer with a provider | Recurring |
| Internal skills and workflow upkeep | Administrators and playbook authors on the QRadar SOAR platform | Staff to run OpenSearch, Orborus, container hosts, and maintain workflows and apps; confirm skills before cutover | Recurring |
What moves the comparison most
Five factors decide whether self-hosted Shuffle costs less than IBM QRadar SOAR over time. Some scale the commercial license, some scale the infrastructure you run, and some scale the people who keep both working. Check each one against your own environment before comparing quotes.
Number of authorized users
QRadar SOAR is licensed per Authorized User, so the count of analysts who log in and act on cases sets the license base, and that base recurs through the annual Subscription and Support term. Shuffle's pricing article says users, apps and workflows are unlimited on its licensing model, so user growth does not add a per-seat fee there. Confirm with IBM how Authorized Users are defined in your contract, including read-only, service and integration accounts, before you count them.
Workflow execution volume
Shuffle's paid licensing is priced on app runs, meaning actions that actually execute in a workflow. Triggers and skipped actions are not counted. A high alert volume that triggers many workflows but runs few actions costs less than the same volume running long enrichment chains. Pull a sample month of execution logs from your current platform and count the actions that run, not the alerts received, before you ask Shuffle for a quote.
High availability requirements
Shuffle's configuration docs recommend an OpenSearch cluster, optional Memcached for a shared cache, NFS for shared files across several backends, and more than one Orborus node so workflows keep running if one fails. Each of those adds servers, storage and monitoring that you pay for and operate. A single-host Docker Compose install is simpler and cheaper, but the docs say it is not scalable without changes. Decide the availability target with your SOC leads first, then price the matching topology.
Edition and feature needs
Shuffle says all features are available in the open-source edition, and its paid tiers differ in feature limits, scaling and support. Since v2.1.1 those limits are enforced. Single sign-on is a feature to check: SAML arrived in version 0.9.16 and OpenID Connect in 1.0.0, and SAML is being deprecated on Shuffle Cloud. Compare the QRadar SOAR features you rely on, such as SSO, support tiers and scaling, against the edition that provides them, and get the paid tier in writing if you need it.
Platform and infrastructure ownership
A self-hosted Shuffle install runs on servers, storage and a container runtime in your own environment, and those costs recur. Compare the VM or OpenShift footprint that QRadar SOAR already needs with the Docker, Swarm or Kubernetes hosts Shuffle would need, and include backups of the OpenSearch data. Ask your infrastructure team which hosting capacity is already paid for and which would be new spend.
In-house skills to run workflows
Under the commercial model, IBM delivers much of the operating support, while self-hosting moves that work to your staff or to an implementation partner. Shuffle workflows, apps built from OpenAPI specifications and Docker-based app runtimes need people who can maintain them and handle the encryption key used for saved credentials. Count the hours your team can give to workflow upkeep each month, and ask any partner for a written scope before you assume the gap is covered.
How QRadar SOAR licensing and its platform add up
QRadar SOAR is licensed per Authorized User, and the license carries an annual Subscription and Support component, so the recurring line on your IBM quote scales with how many people can open and work cases. Count named analysts, engineers and any administrators who log in, and confirm with IBM how it defines an Authorized User, whether service accounts or read-only reviewers are included, and what happens to the rate when headcount changes mid-term. Ask for the per-user rate, the support terms, the renewal uplift and the notice period in writing, and do not rely on public price references, which may not match your contract.
The license is only part of the bill. QRadar SOAR runs on a virtual machine or on OpenShift, so the platform costs sit in your infrastructure budget: hypervisor capacity or cluster nodes, storage for incident attachments and the database, backups, monitoring, and the staff time to patch the operating system and the application. For each line, identify the owner and whether it is one-time (hardware, initial build, migration) or recurring (compute, storage growth, support hours). Shuffle's own costs follow the same structure: servers, storage, the people who maintain workflows, and any subscription if you move to its paid tiers. Compare on this basis, not on the license alone.
On-premises QRadar SOAR versions receive support for at least twelve months from general availability, so you will need to upgrade on a regular cycle whether or not you migrate. Schedule each upgrade as a recurring cost in your model, including test environments, playbook regression checks and integration testing. If you plan to move to a self-hosted platform, a cycle that is already due is a natural point to decide, because upgrading now and migrating later means paying for the same work twice.
How to build the comparison with your own numbers
This sequence turns the cost components into a model built on your own contract, footprint and automation volume, so you can compare QRadar SOAR and self-hosted Shuffle on the same three-year basis. The output is a worksheet your finance and security leads can review together.
Collect the current QRadar SOAR contract
Pull the current IBM QRadar SOAR order form or subscription statement, including the Subscription and Support terms, the renewal date and the number of Authorized Users licensed. Ask your IBM account team or reseller to confirm in writing which users count as Authorized Users under your agreement, since that count drives the license line. Record any add-on modules, support tiers and price escalation clauses. The step is done when you have one sheet showing the license cost per year, the user count and the renewal terms, each linked to the source document.
List the platform footprint under QRadar SOAR
Inventory everything the product runs on: the virtual machines or OpenShift project, their CPU, memory and storage allocation, database and backup components, load balancers, and the staff time spent patching and upgrading the on-premises version. Include the operating system and virtualization licenses that only exist to support SOAR. Your infrastructure team owns this list, and the security operations lead should confirm which items are dedicated to SOAR and which are shared. The step is done when every server, license and recurring maintenance task has an owner and a yearly cost estimate from your own records.
Size Shuffle servers against its requirements
Start from the Shuffle install guide, which sets a minimum of 4 GB of RAM and notes that the default Docker Compose setup is not scalable without changes. Then apply the high availability recommendations in the Shuffle configuration docs: an OpenSearch cluster, a shared cache, shared file storage when running several backends, and more than one Orborus node. Choose a deployment architecture from the single-server, Swarm, hybrid or Kubernetes options that fits your environment. Confirm sizing with the Shuffle team or a qualified integrator before purchasing hardware. The step is done when you have a node list for production, a standby and a test environment, with the compute and storage each one needs.
Estimate app runs from current automation volume
Shuffle's licensing for its enterprise tiers is based on app runs, meaning actions that actually execute in a workflow, so you need a monthly count. Export or sample the number of playbook executions and the actions each one performs from your QRadar SOAR logs, and exclude triggers and skipped actions as the Shuffle pricing article describes. Note that the open-source edition includes all features, so this count matters only if you compare against a paid Shuffle tier. The step is done when you have a monthly app run figure for current workload, with the method and date range documented.
Price the migration as a fixed-scope project
Inventory playbooks, functions and app integrations, then ask one or more implementation partners to quote against a written scope listing the workflows to rebuild, the integrations to create or adapt, the data to move and the testing and cutover work. Ask each bidder to separate one-time work from any ongoing support or retainer. Also ask whether the quote includes the server build, hardening, backup design and documentation. DeployOpen works from fixed written scopes and does not publish a price list, so request a quote from the scope rather than comparing headline rates. The step is done when you hold comparable written quotes, each tied to the same inventory and deliverables.
Assign staff hours for workflow maintenance
Estimate the hours your team will spend each month on workflow changes, app updates, troubleshooting, Shuffle version upgrades and access reviews, and compare that with the hours spent on QRadar SOAR administration today. Name the roles involved, such as a platform engineer, a security automation author and an on-call responder, and note which tasks can be shared with a support retainer. Shuffle's app creator builds integrations from OpenAPI specifications, which can shorten some integration work, but confirm that against your own tools. The step is done when each role has a monthly hour estimate and a loaded cost, based on your internal salary data.
Model three years with one-time and recurring costs
Build a three-year table with two blocks. The one-time block holds migration project fees, hardware or cloud setup, initial testing and training. The recurring block holds QRadar SOAR subscription and support, the infrastructure for both platforms during any parallel run, operating staff time, and any Shuffle support or retainer you choose. Keep the parallel-run period as an explicit line, because running both platforms costs more than either alone. Use the figures from the earlier steps and mark every assumption. The step is done when the model shows a yearly total for each platform and a cumulative total for three years.
Run two or three user growth scenarios
Because QRadar SOAR licensing scales with Authorized Users, repeat the model for at least two or three user growth cases, such as flat headcount, moderate growth and a larger expansion, and hold infrastructure and staffing assumptions constant unless a case changes them. Also test a case where the license price changes at renewal, using the terms you collected in the first step. Share the scenarios with finance and the security leadership team and record which assumptions drive the result most. Illustratively, a model may show the license line dominating at high user counts while staff time dominates at low ones, so confirm the actual pattern with your numbers. The step is done when each scenario has a three-year total and the top three cost drivers are documented.
Which Shuffle deployment shapes the server bill
The single server model runs the frontend, backend, OpenSearch and Orborus on one host with Docker Compose. It is the lowest-cost starting point because one virtual machine or one physical host covers the whole platform. The install guide sets a minimum of 4 GB of RAM, but that is a floor, not a sizing guide, and OpenSearch memory use grows with stored executions and documents. The default Compose setup is not a scalable build without changes, so this shape suits evaluation, a small SOC or a lab.
- Infrastructure: one VM or host, its disk for OpenSearch indices, and backup storage for the encryption secret and data volumes.
- Recurring cost: compute and storage only, plus your own patching and backup time.
- Operating effort: low to start, but a single failure stops all workflows.
- Scaling limit: adding capacity means moving to a larger host or a different architecture.
- Hosted comparison: the hosted service at shuffler.io removes the server bill entirely, so price it against your VM and staff time.
Before you commit, confirm with your own sizing test how much RAM and disk your alert volume needs, and ask whether your risk model accepts a single point of failure.
The distributed Docker Swarm model spreads Shuffle services across several servers. Adding nodes raises the server bill, but it lets you scale backends and runtime capacity without rebuilding the platform. The architecture documentation describes it as a step up from a single host, and the configuration guidance expects shared services such as NFS when several backends run together.
- Infrastructure: several Linux servers, a shared file service, and a network path between nodes.
- Recurring cost: more compute nodes, storage for shared files, and network capacity between them.
- Operating effort: moderate, since you run Swarm membership, rolling updates and node replacement.
- Failure handling: a single node loss no longer stops every workflow, provided the other services are replicated.
- Hosted comparison: a managed service shifts Swarm operations to the vendor, but you still need to size data egress and local runtime needs.
Ask your platform team who owns Swarm upgrades and whether they have run it in production before. Confirm the sizing with a load test, since the documentation does not give per-workflow resource figures.
The hybrid model keeps the Shuffle control plane in the hosted cloud at shuffler.io and runs a local Orborus on your own infrastructure. Orborus is the component that starts workflow workers and the app containers they call. Because Orborus polls the backend for jobs rather than receiving inbound connections, the local side needs no inbound firewall ports. This lowers the server bill for the management layer and keeps execution where your tools are reachable.
- Infrastructure: one or more local hosts for Orborus and its app containers, with outbound access to the cloud backend.
- Recurring cost: the subscription for the hosted control plane and the compute for local runtime.
- Operating effort: lower than a full self-hosted stack, since you skip OpenSearch and backend operations.
- Data location: workflow execution and app credentials handling depend on the design, so review where data is stored.
- Resilience: the documentation recommends more than one Orborus node so workflows keep running if one fails.
Confirm with the vendor which data leaves your network, where saved app credentials are stored, and whether your policy allows a cloud control plane for security automation.
The Kubernetes model deploys Shuffle with Helm charts on a cluster. It has the highest fixed platform cost if you do not already run Kubernetes, but it is the natural choice for organizations that already operate clusters, storage classes and monitoring. The architecture documentation lists it as one of the four options, and the high availability guidance (an OpenSearch cluster, Memcached, shared files and multiple Orborus nodes) maps well onto cluster primitives.
- Infrastructure: a cluster with enough worker nodes for OpenSearch replicas, the backend, frontend and Orborus, plus persistent volumes.
- Recurring cost: cluster nodes, persistent storage, load balancing and backup tooling.
- Operating effort: highest, covering chart upgrades, OpenSearch tuning, certificates and cluster security.
- Shared cost: if your platform team already runs the cluster, the marginal cost may be small.
- Hosted comparison: the hosted service avoids cluster operations but not your cluster duties if you keep a local Orborus.
Ask your platform team how many nodes they reserve for security tooling, and whether the chart version you deploy matches the release you have tested. Confirm the release tag in the GitHub releases page before you pin it.
Questions buyers ask before comparing costs
How much effort does a self-hosted Shuffle deployment take, and can our team do it alone?
A single-server Shuffle install is a manageable task for a team with container experience, but a production setup is more than one container. Shuffle documents four architectures: a single server with Docker Compose, distributed Docker Swarm, a hybrid with Shuffle Cloud and a local Orborus, and Kubernetes with Helm charts. The install guide says the default Docker Compose setup is not scalable without changes and needs at least 4 GB of RAM. High availability adds an OpenSearch cluster, shared cache and file storage, and more than one Orborus node. Ask your team whether it has owners for OpenSearch, container orchestration, backups and secret handling before deciding whether to build it in house.
What drives the implementation and migration cost of moving off QRadar SOAR?
The main cost components are the staff hours to design and test the platform, the servers or cluster that run it, the rebuild of existing automation, and ongoing maintenance. Costs rise with the number of playbooks, the number of custom functions and app integrations that must be rewritten as Shuffle apps or workflows, the number of alert sources that need cutover, and the depth of high availability you require. Costs fall when playbooks are simple, integrations already exist as premade Shuffle apps, and the team reuses its existing container and monitoring tooling. Ask any vendor or partner for a quote that lists each of these items separately.
How does the number of playbooks affect migration time?
The playbook count is a driver of effort rather than a fixed duration. Each playbook needs an inventory, a decision on whether its logic maps to a Shuffle workflow, a test against a sandbox, and a plan for the cutover. Playbooks that call custom Python functions take more work, because Shuffle apps are built from OpenAPI specifications in the App Creator or written with the Shuffle app SDK. Before you estimate, export the playbooks and functions, group them by integration, and count how many depend on the same connector. Those groups set the order of work and show where a small set of apps covers a large share of the automation.
What skills and hours does the work need from our staff?
Plan for three skill areas: container and orchestration operations (Docker, Swarm or Kubernetes), database operations for OpenSearch, and automation engineering for workflows and app integrations. Security analysts who know your current playbooks must also be available to validate outcomes. Shuffle apps can be written in Python with the app SDK, so a developer who knows Python will handle most custom integrations. Hour counts depend on your environment, so ask for a written breakdown by role and by phase. Note that Shuffle encrypts saved app credentials with the SHUFFLE_ENCRYPTION_MODIFIER secret, and losing or changing that value breaks all saved app authentications, so key management needs a named owner from day one.
Is Shuffle's open-source edition enough, or when do paid tiers apply?
Shuffle states that all features are available in the open-source edition, and that its 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. Shuffle's licensing is priced on app runs, meaning actions that execute in a workflow. Triggers and skipped actions are not counted, and users, apps and workflows are unlimited. Read the Shuffle open source article and pricing article to confirm which limits apply to your expected run volume, and check the configuration docs for the current enforcement behavior before you assume the open-source edition covers your use.
Should we get outside help with the migration and ongoing operation?
Outside help makes sense when your team lacks capacity or experience with the required skills, or when a migration must finish before a renewal date. DeployOpen plans, implements, integrates, hardens, backs up, upgrades and documents self-hosted open-source platforms inside your own infrastructure. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ongoing support and upgrades are available as retainers, and a quote follows from the written scope. Ask any provider to split the quote between one-time build work and recurring support so you can compare it against the internal staff cost.
What recurring costs remain after a self-hosted Shuffle deployment goes live?
After go-live, the recurring costs are the servers or cluster capacity, storage and backups, OpenSearch operations, security patching and version upgrades, and the staff time that keeps workflows and app integrations working as source APIs change. The Shuffle release process means you should choose a Docker tag deliberately, since the docs recommend the latest tag for stable releases and the nightly tag for experimental changes. Compare these recurring items with the annual Subscription and Support and per-user charges you would stop paying, and write the comparison down with the assumptions you used.
When staying on QRadar SOAR is the cheaper choice
Staying on QRadar SOAR can be the lower-cost option when the user base is small, the playbook set is stable and the team already runs IBM tooling well. Per-user licensing works in your favor when few people open cases or edit playbooks, because the annual Subscription and Support fee scales with authorized users rather than with workflow volume. In that situation, the cost of moving is hard to recover: you would pay for a new platform, server capacity, migration engineering and parallel running, and gain little if the existing playbooks rarely change. Before deciding, count the authorized users who actually log in each quarter, list how many playbooks changed in the last year, and ask IBM to confirm the current Subscription and Support terms and the platform costs that remain on your side.
An existing QRadar SIEM estate with trained analysts is the second case where the commercial product keeps its advantage. If your alerts, offenses and case handling already flow through IBM components, the integration work is smaller and the staff already know the Playbook Designer and its integration framework. Migration would then add retraining, new alert routing and a second system to explain to auditors during the transition. Check how many of your playbooks depend on QRadar-specific actions, and whether the staff who maintain them would need to learn a different workflow model. If most of the value sits in those integrations, the migration case weakens.
The third case is a team without the capacity to run an orchestrator. Self-hosted Shuffle needs someone to own the server, the OpenSearch database, the orchestration runtime, credential encryption keys and upgrades, and someone to maintain workflows as tools change. Shuffle's install guide notes that the default Docker Compose setup is not scalable without changes, so a small team should plan for that work before committing. If no one on your staff can absorb that operating load, paying IBM for a managed-quality experience can be the sounder decision, provided you negotiate the renewal with the user count you actually need.
How DeployOpen scopes a fixed-price migration from QRadar SOAR to Shuffle
DeployOpen is a Chainscore Labs company that plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For a move from IBM QRadar SOAR to Shuffle, we start by agreeing on the cost components and migration scope in writing, then build and hand over the platform before any cutover.
How we scope
- We inventory your QRadar SOAR licenses, Authorized User counts, VM or OpenShift footprint and integrations before writing a scope.
- The written scope lists which playbooks, functions and app integrations move to Shuffle workflows and which are retired.
- We agree in writing on deployment target, whether a single server, Docker Swarm or Kubernetes, and who operates each component.
How we build
- We deploy Shuffle in your own cloud account, data center or air-gapped network, following the architecture your scope approves.
- We rebuild priority workflows in Shuffle, creating apps from OpenAPI specifications where no premade app fits your tools.
- We test each workflow against replayed alerts and document results before any alert source is pointed at the new platform.
How we hand over
- We document the deployed architecture, configuration keys, backup procedures and the handling of the SHUFFLE_ENCRYPTION_MODIFIER secret.
- We run a knowledge transfer with the analysts and engineers who will maintain workflows after handover.
- We deliver a cost comparison and run-cost model that your finance and procurement teams can check against vendor quotes.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after the fixed-scope work closes.
- A retainer can cover Shuffle version upgrades, such as moving between tagged releases, after you review each change.
- Ask us to confirm in the quote which support tasks, response expectations and testing cycles are included before signing.
