Migrate from IBM QRadar SOAR to Shuffle

What moving from QRadar SOAR to Shuffle involves

Moving from QRadar SOAR to Shuffle is a rebuild of automation plus a decision about where incident records live. Playbooks, custom functions and app integrations do not transfer as files into Shuffle workflows and apps, so each one has to be inventoried and rebuilt against Shuffle's model. Most organizations start from a renewal, a licensing change, a data residency requirement or a wish to reduce lock-in. The work is usually carried out by the SOC engineering team, often with an implementation partner who builds the platform and reviews the rebuilt workflows. Effort depends on how many playbooks are actively used and how many custom functions they call, so count both before anyone estimates the project.

Shuffle's architecture and licensing differ from QRadar SOAR's per-user model, and both shape the plan. Shuffle's pricing article describes users, apps and workflows as unlimited, with paid tiers metered on app runs, so the team should confirm which edition covers its scale and support needs. Licensing is also split: the backend is AGPLv3 and workflows, apps and app specifications are MIT, so counsel should review how those terms apply to internal changes and any hosted use. On the platform side, a self-hosted server runs a frontend, a Go backend on port 5001 and an OpenSearch database, while Orborus starts workers and app containers. The install guide sets a minimum of 4 GB of RAM and warns that the default Docker Compose setup is not scalable without changes, so production planning should include the high availability layout in the Shuffle configuration docs.

Before cutover, decide which credentials move and how they are protected. Shuffle encrypts saved app credentials and API keys in OpenSearch with AES-256 using the SHUFFLE_ENCRYPTION_MODIFIER secret, and the configuration docs warn that losing or changing that value breaks every saved app authentication. Store it in the organization's secrets manager, record it in the runbook and test a restore in a non-production environment. Identity needs the same attention: Shuffle supports SAML single sign-on from version 0.9.16 and OpenID Connect from 1.0.0, so confirm which protocol the identity provider will use. Run both platforms in parallel for a defined period, with each alert source switched over one at a time and each rebuilt workflow checked against the QRadar SOAR output it replaces.

Which QRadar SOAR capabilities map to Shuffle and where the gaps are

This table maps the main QRadar SOAR capabilities to their closest Shuffle equivalents and rates each one as a clean fit, a rework item or a gap. Read the middle column first, then check the last column against your own playbooks and incident process. The main takeaway is that automation and integrations map well, while case records and task tracking need confirmation before you commit.

QRadar SOAR capability	Shuffle equivalent	Fit and notes
Playbook automation	Shuffle workflows built in the visual editor, with triggers, actions and conditions	Needs rework. Logic must be rebuilt by hand, since exports from QRadar SOAR do not convert directly into Shuffle workflows.
Custom functions and scripts	Python code run through the Shuffle app SDK as versioned Docker containers	Needs rework. Each function must be reviewed for dependencies and packaged as an app before use in workflows.
Out-of-the-box app integrations	Premade apps for common security tools, plus the App Creator that builds apps from OpenAPI specifications	Clean fit for tools with a published API. Confirm that each app you rely on exists in your Shuffle version and covers the actions you use.
Integrations without a premade app	App Creator from an OpenAPI specification, or a custom app written with the Python SDK	Needs rework. Budget time for authentication testing, error handling and version control of each app.
Users, roles and single sign-on	SAML single sign-on from version 0.9.16 and OpenID Connect from 1.0.0, with per-tenant enforcement	Clean fit for SSO. Role and permission mapping must be confirmed against your QRadar SOAR role model. SAML is being deprecated on Shuffle Cloud in favor of OpenID Connect.
Incident records and tasks	Workflow executions and stored data in OpenSearch. Dedicated case management is not the same as an incident case system	Gap to confirm. Check whether Shuffle's case and task handling meets your needs for incident fields, task ownership, audit history and closed-case retention.
Storage and credentials	OpenSearch as the document database, with saved app credentials encrypted using AES-256 and a SHUFFLE_ENCRYPTION_MODIFIER secret	Clean fit with operational care. Losing or changing the encryption secret breaks all saved app authentications, so back it up securely.
Deployment and runtime	Four documented architectures: single server with Docker Compose, Docker Swarm, hybrid with Shuffle Cloud, and Kubernetes with Helm	Needs rework. The default Compose setup is not scalable without changes. Choose the architecture that matches your VM or OpenShift estate.
High availability	OpenSearch cluster, optional Memcached, NFS for shared files, scaled backend and frontend, and more than one Orborus node	Needs rework. Multi-node design, shared storage and failover testing are your responsibility and should be tested before cutover.

What moves cleanly and what needs rebuilding

The trigger, decision and action sequence of each QRadar SOAR playbook is the part that transfers as design. Before any build starts, write each playbook down as a plain sequence: what starts it (a new incident, a status change, a manual invocation), which conditions route the case, and which actions run against which systems. That document is portable. In Shuffle it becomes a workflow with a trigger node, conditional branches and app actions, and you can review it with the SOC lead before anyone opens the canvas. The supplied facts do not describe a direct importer from QRadar SOAR playbooks to Shuffle workflows, so confirm with IBM which playbook export formats your version supports, and plan a manual rebuild for each playbook regardless of what the export contains.

The elements that do not carry over are the ones tied to QRadar SOAR internals: custom Python functions, scripts that call the Resilient API directly, and vendor-specific field mappings between incident fields and external tools. Each custom function needs a decision: rewrite it as a Shuffle app, which Shuffle builds from an OpenAPI specification in the App Creator or writes in Python with the Shuffle app SDK, or replace it with an existing premade app plus a small code step. Field mappings must be re-derived from the target systems, not copied. Inventory every function and every field your playbooks read or write, and record which ones exist only inside QRadar SOAR. Those rows are your rebuild backlog and your estimate of effort.

Which data and integrations to inventory and move

Migration work splits into records, people, credentials and alert feeds, and each one moves by a different path. Inventory all four before rebuilding any workflow, because a gap in one area, such as a missing credential, stops automation even when the playbooks themselves are complete.

Incident and task records

Open and closed incidents, their notes and task history form the audit trail your SOC depends on. Shuffle is an automation platform and its execution history is not a replacement for a case record, so decide early whether closed QRadar SOAR incidents will be exported as read-only archives or kept in the existing system for the retention period. Confirm with IBM which export formats QRadar SOAR supports for incidents and tasks before you assume any data path, and test a sample incident end to end.

Attachments and evidence files

Files attached to incidents, such as malware samples, screenshots and log extracts, often sit alongside case records and are easy to miss in an inventory. Identify which attachments are still referenced by open cases, which must be preserved for legal or audit reasons, and how they will be stored once QRadar SOAR is retired. Confirm the export path for attachments with IBM, since file export may be handled separately from record export.

Custom fields and incident types

Custom fields, incident types and their mappings drive how alerts are classified and which playbooks trigger. Document each field, its data type, required status and the playbooks that read or write it. In Shuffle these become workflow variables, data structures or fields you define in the case or ticketing destination, so each one needs a named target. Gaps here usually show up as playbooks that run but write blank values downstream.

Users, roles and access

QRadar SOAR assigns roles and group permissions that decide who can edit playbooks, close incidents and see sensitive cases. Shuffle supports single sign-on through SAML, added in version 0.9.16, and OpenID Connect, added in 1.0.0, so map each QRadar SOAR role to a Shuffle group or identity provider group before go-live. Confirm with your identity team which SSO method your on-premises deployment will use, and review who holds administrator rights in Shuffle.

Saved integration credentials

Every app connection in QRadar SOAR holds credentials for a firewall, EDR, ticketing or email system, and each must be re-entered or re-issued in Shuffle. Shuffle encrypts saved app credentials and API keys in OpenSearch with AES-256 using the SHUFFLE_ENCRYPTION_MODIFIER secret, and losing or changing that secret breaks every saved app authentication. Store the value in your secrets manager, back it up with the database, and never rotate it casually during cutover.

Alert sources from QRadar SIEM and other tools

Playbooks only run when alerts reach them, so inventory every source that currently creates incidents in QRadar SOAR, including QRadar SIEM offenses, email reporters and EDR webhooks. For each source, decide whether it will point to Shuffle webhooks or a queue, and run both paths in parallel for a short window to compare alert volumes. Confirm the exact QRadar SIEM integration method with IBM and your own configuration before changing any forwarding rule.

The migration sequence from inventory to decommission

The sequence moves QRadar SOAR automation to Shuffle in controlled stages, so each playbook, integration and alert source is proven on Shuffle before the old platform stops receiving work. It ends with a decommission that keeps closed-case records available for audit.

Inventory playbooks, functions and alert sources
Export the playbook catalog, custom functions, scripts, integrations and configured inbound alert sources from QRadar SOAR, and record each item's owner, incident types it serves, last run date and volume. Check the export against the admin console, since exports may not capture every dependency. Confirm with each owner which playbooks are still used and which can be retired. The step is done when every item has a named owner and a keep, rebuild or retire decision.
Map integrations to Shuffle apps
For each external system a playbook calls, check whether Shuffle has a premade app, whether the App Creator can build one from the vendor's OpenAPI specification, or whether a Python app is needed using the Shuffle app SDK. Record the credentials each app needs and where they will be stored. Flag gaps early, such as integrations that depend on a Python function with no equivalent API call. The output is an integration map with a build route and an owner for each gap.
Decide where cases and tasks will live
Shuffle automates work but is not a case management system in the way QRadar SOAR is, so decide where incident records, tasks, comments and attachments will be kept during and after migration. Options include keeping QRadar SOAR as the system of record for cases, or moving records to a ticketing or case tool. Document the decision with the audit and records owners. The step is complete when each data type has a named home and retention rule.
Pilot a few high-volume workflows on Shuffle
Rebuild a small set of high-volume, well-understood playbooks as Shuffle workflows on a non-production Shuffle instance, using the deployment architecture chosen for production. Run them against replayed or test alerts and compare outcomes with the QRadar SOAR results for the same inputs. Record every difference and fix it, including credential handling and error paths. The output is a signed-off pilot report listing which workflows match and which need rework.
Run in parallel with QRadar SOAR still receiving cases
Keep QRadar SOAR receiving live cases while the matching Shuffle workflows run alongside it, with outputs compared on each case. Watch for duplicated actions, such as two tickets or two containment steps for one event, and disable the duplicate path before going further. Confirm that Shuffle's runtime components, including Orborus and the app containers, stay healthy under load and that failures are alerted on. The step is done when the analysts and the owners agree the Shuffle results are reliable for each migrated playbook.
Cut over alert sources in batches
Move inbound alert sources to Shuffle in groups, starting with the lowest-risk sources and ending with the most critical. For each batch, repoint the source, confirm that events arrive and workflows trigger, and keep a documented rollback path to QRadar SOAR. Retire the old source connection only after the batch has run cleanly through an agreed observation period. The output is a cutover log for each batch showing the source, date, owner and rollback status.
Decommission QRadar SOAR and keep closed-case records
Once all alert sources are cut over and no open cases remain in QRadar SOAR, export closed-case records, attachments, audit history and playbook versions to the archive chosen in step three, and verify that the archive can be read. Confirm the retention period with compliance and legal owners before deleting anything. Then revoke integrations and credentials, and shut down the QRadar SOAR environment. The step is complete when the archive is verified and the decommission is signed off.

How the migration changes with the starting point

A small team with a handful of playbooks on one QRadar SOAR virtual machine has the shortest path. Shuffle's single-server Docker Compose architecture fits this footprint, but the install guide states that the default Compose setup is not scalable without changes and needs a minimum of 4 GB of RAM. Most of the effort goes into rebuilding a few workflows and cutting over one or two alert sources, and most of the risk sits in credential handling.

Host sizing: Plan for at least 4 GB of RAM on the Shuffle host, and confirm that figure against the workload you expect before reusing an existing VM.
Scaling caveat: The default Compose file is a starting point. Growing beyond one node means changing the setup, which is a separate piece of work.
Small inventory: Export and list each playbook, its functions and its app connections. A short list usually means a short rebuild.
Credential key: Store SHUFFLE_ENCRYPTION_MODIFIER in your secrets store before the first run, because changing or losing it breaks all saved app authentications.
Parallel run: Keep QRadar SOAR available through the cutover window so you can compare the outputs of old and new workflows.

Check whether a single node meets your availability expectations, since one host also means one point of failure for automation.

What drives migration cost and duration

This table lists the factors that raise or lower the effort of moving from QRadar SOAR to Shuffle, with the reason each one matters and how to keep it under control. Read it before asking for a quote, because the scope of each driver is what a fixed-scope proposal should price. Shuffle's licensing is by app runs, with users and workflows unlimited, so licence cost does not grow with headcount, and the main costs are the migration work and the infrastructure you run.

Driver	Why it changes effort	How to keep it down
Number and complexity of playbooks	Each playbook has to be read, redesigned as a Shuffle workflow and tested, and branching logic, loops and error handling multiply that work.	Retire unused playbooks first, then rebuild the most-run ones and simplify logic where the outcome is the same.
Number of custom functions	QRadar SOAR Python functions have no direct equivalent, so each one must be rewritten as a Shuffle app action or a script step.	Group functions by target system so one reusable app serves several workflows.
Integrations needing new Shuffle apps	Shuffle ships premade apps for many security tools, but any tool without one needs an app built from an OpenAPI specification or the Python SDK and tested in a container.	Inventory every integration against Shuffle's app catalog before scoping, and confirm the coverage for each of your tools.
Volume and type of alert sources	Each alert source, including QRadar SIEM, email feeds and ticketing tools, needs a new trigger, field mapping and cutover test.	Cut over sources in batches and keep the QRadar SOAR feed running in parallel until each batch is verified.
High availability design	An OpenSearch cluster, shared Memcached, NFS for shared files and more than one Orborus node add infrastructure to build, patch and monitor.	Decide the availability target with your operations team first, and size the cluster only to that target.
SSO setup	Connecting Shuffle to your identity provider through SAML or OpenID Connect requires role mapping, tenant settings and access testing.	Agree the identity provider and role model before the build starts, and reuse your existing group structure.
Audit retention needs	Closed QRadar SOAR incidents, their tasks and notes may need to remain retrievable for audits, which requires an archive or export design alongside the new platform.	Confirm the retention period and evidence format with your compliance team, then export closed cases in a format you can retrieve.
Credential and encryption key handling	Saved app credentials are encrypted with the SHUFFLE_ENCRYPTION_MODIFIER secret, so the key must be stored and backed up before any credential is entered.	Store the key in your approved secrets manager and document how it is restored before go-live.

What usually goes wrong and how to prevent it

Most failed SOAR migrations do not fail on the first playbook. They fail on secrets that are lost, custom code that was underestimated, alerts that moved before the new platform was proven, and workflows nobody owns after handover. Each card below names one of these risks and the step that prevents it.

Losing the encryption modifier secret

Shuffle encrypts saved app credentials and API keys in OpenSearch with AES-256, using the value of the SHUFFLE_ENCRYPTION_MODIFIER secret. If that value is lost or changed after the first start, every saved app authentication stops working, and the workflows that depend on them fail at the next run. Before loading any credentials, store the value in your secrets vault, record which environment it belongs to, and confirm that backups of the OpenSearch data are restorable together with that value.

Underestimating custom function rebuilds

Playbooks are often the easy part of a QRadar SOAR migration. The Python functions and scripts behind them, along with any custom fields used for routing, usually need to be rewritten as Shuffle apps or workflow logic. Inventory every function and the playbooks that call it, then estimate the rebuild per function rather than per playbook. Ask the implementation partner to list which functions can map to existing apps and which need a custom app built from an OpenAPI specification or the Python SDK.

Cutting over before parallel run validation

Moving alert sources from QRadar SIEM or another tool to Shuffle before the workflows have been validated creates silent gaps, because missed alerts do not show up as errors. Run both platforms on the same alert stream for an agreed period, compare the case or workflow outcomes for each alert type, and switch one source at a time. Record the criteria for each switch in writing, including who signs off and how a rollback is triggered.

Single Orborus node as a hidden outage

Orborus polls the Shuffle backend for jobs and starts a worker for each workflow execution. Running one Orborus node means that a single failure stops every automation at once, and the failure may not be obvious until incidents pile up. Shuffle's configuration guidance recommends more than one Orborus node, an OpenSearch cluster, and shared files for multiple backends. Confirm the target topology before cutover and test a node failure in staging.

Losing closed-case history

Closed QRadar SOAR incidents, tasks, notes and timestamps are often the evidence an auditor or legal team asks for months later. Shuffle is a workflow platform, so it does not replace an incident record in the same way, and migrating only open cases leaves gaps. Decide with your compliance lead how closed cases will be exported and retained, keep a read-only archive that can be searched, and confirm the retention period with the teams that rely on it.

Unclear workflow ownership after handover

Once the migration is complete, workflows still need owners who approve changes, review failed runs and update apps when vendor APIs change. Without named owners, workflows drift, credentials expire unnoticed, and nobody knows which automation is safe to edit. Assign an owner to each workflow group, define a change process that covers app versions and nightly tag use, and agree who handles on-call escalation for the platform itself before the old SOAR is switched off.

Questions buyers ask before moving from QRadar SOAR to Shuffle

What does a migration from QRadar SOAR to Shuffle cost, and what drives it?

Shuffle's open-source edition has no license fee, so the cost is the infrastructure you run, the migration labor and the people who maintain workflows afterward. The biggest variables are the number of playbooks, how many functions and custom scripts they call, how many integrations you depend on, and whether each integration already has a Shuffle app or needs one built from an OpenAPI specification. Infrastructure cost depends on whether you run a single server or a high-availability layout with an OpenSearch cluster and several Orborus nodes. Ask any implementation partner for a quote built from a written inventory of playbooks, integrations and environments. Confirm with Shuffle which features your edition includes, since its pricing article describes paid tiers that differ in feature limits, scaling and support.

How long does a QRadar SOAR to Shuffle migration take?

Duration depends mainly on the size and complexity of your existing automation, not on the platform alone. Teams with a small set of well-documented playbooks and mostly prebuilt integrations finish far sooner than teams with dozens of playbooks, heavy custom Python functions and unsupported third-party connectors. Other factors include the number of alert sources to cut over, the level of testing your change process requires, and how many environments (test, staging, production) you maintain. No fixed duration is documented here, so ask for a timeline in the written scope and check it against your own inventory before agreeing to it.

What must our team provide during the migration?

Your team supplies the knowledge the migration depends on, and the work stalls without it. Expect to provide access to the current QRadar SOAR instance and its exports, a list of playbooks with their business purpose and owners, credentials and API access for each integration, test data or sandbox alert sources, and an approver for each cutover step. Security operations staff must also validate that rebuilt workflows make the same decisions as the originals. Plan for the people who will own Shuffle workflows after handover, because they need to understand the app credentials, the encryption secret and the update process.

Can our own team migrate from QRadar SOAR to Shuffle without a partner?

Yes, a capable internal team can do the migration, provided it has the skills and time. Shuffle's documentation covers Docker and Kubernetes deployment, OpenAPI-based app creation and a Python SDK for custom apps, so engineers with container and scripting experience can start quickly. The risks are usually in the less visible work: mapping QRadar SOAR functions to Shuffle apps, securing credentials, configuring high availability and proving that cutover does not drop alerts. Many teams combine internal ownership with outside help for the inventory and the first production workflows. Decide which parts you can staff before you choose.

How do we keep closed QRadar SOAR cases available for audits?

Decide this before cutover. Closed incident records in QRadar SOAR are evidence, and retention rules usually come from your internal policy and the regulations you follow. Options include keeping the QRadar SOAR instance read-only for the retention period, exporting closed cases to an archive you control in a documented format, or moving case history to a system built for case records. Shuffle's documentation describes its own document store, but confirm with Shuffle whether it is meant as a long-term case archive for your retention needs. Whichever option you choose, test that an auditor can retrieve a sample case with its timeline, tasks and attachments. DeployOpen prepares systems and evidence for compliance assessments, but auditors and certification bodies issue the findings.

How does Shuffle's open-source edition differ from its paid tiers?

Shuffle states that all features are available in the open-source edition, and its paid tiers differ in feature limits, scaling and support. Since version 2.1.1, the limits between the editions are enforced. Its pricing article says licensing is based on app runs, meaning actions that actually execute in a workflow, while triggers and skipped actions are not counted, and that users, apps and workflows are unlimited. Before you plan volume, model your expected app runs against those definitions and confirm the current limits and support terms with Shuffle in writing. Also review the license split: the backend is AGPL-3.0 and the workflows, apps and specifications are published under MIT, so have your legal team confirm how it applies to your use.

What security settings must we get right in Shuffle?

Start with the encryption secret. Shuffle encrypts saved app credentials and API keys in OpenSearch with AES-256 using the SHUFFLE_ENCRYPTION_MODIFIER value, and losing or changing that value breaks every saved app authentication. Store it in your secrets management system, back it up with the rest of your recovery material and document how it is rotated. Also configure single sign-on: Shuffle supports SAML and OpenID Connect, with per-tenant enforcement, and SAML is being deprecated on Shuffle Cloud in favor of OpenID Connect. Restrict network exposure, since the hybrid model needs no inbound firewall ports for a local Orborus, and validate every custom app before it runs with privileged credentials.

How DeployOpen scopes, runs and supports the migration

DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For a move from IBM QRadar SOAR to Shuffle, we start with a written inventory of playbooks, functions and integrations, then agree scope, deliverables and timelines before any build work begins.

How we scope

Inventory of QRadar SOAR playbooks, custom functions, integrations and incident types, agreed in writing before work starts
Decision record on where incident records, tasks and closed cases will live after cutover
Fixed-scope engagement with deliverables and timelines confirmed in writing, followed by a quote based on that scope

How we build

Rebuild prioritized playbooks as Shuffle workflows, with apps created from OpenAPI specifications or written with the Shuffle app SDK
Deploy Shuffle in your environment using Docker or Kubernetes, with secrets such as the encryption modifier stored under your control
Test workflows against sample alerts from each source and document expected results before any alert source is switched

How we hand over

Runbooks covering deployment, Orborus node operation, backups of the OpenSearch data store and credential rotation
Workflow documentation and a mapping of each retired QRadar SOAR playbook to its Shuffle replacement
Cutover plan for alert sources from QRadar SIEM or other tools, with a rollback path and records retained for audits

How we support

Ongoing support, upgrades and workflow changes available as a retainer after handover
Security testing of the Shuffle deployment and its integrations on request, within the agreed scope
Ask us to confirm response arrangements, upgrade procedures and the support scope in the written proposal before you sign