IBM QRadar SOAR on-premises upgrades: keep current or replace

Staying current costs more than the license line. The recurring costs are the IBM subscription and support, which are priced per Authorized User, plus the virtual machine or OpenShift capacity that hosts the site. Each upgrade also consumes staff time: someone must read the release notes, copy production data into a test environment, retest every playbook and custom Python function, and get change approval. IBM supports each on-premises version for at least twelve months from general availability, so the cycle repeats on a predictable rhythm. Costs rise with the number of playbooks, the number of custom functions and the number of integrated tools, because each one is a regression risk. Ask your team to estimate the hours for one full upgrade cycle, including testing, so you can compare that recurring effort with the one-time cost of a migration.

The duration depends on scope, and no reliable timeline can be given without an inventory. The main drivers are the number of playbooks, how many custom functions must be rewritten as Shuffle apps, how many integrations need credentials and test data, how many alert sources must be cut over, and how much case history must be kept or migrated. Shuffle apps can be built from OpenAPI specifications in its App Creator or written in Python with the app SDK, so integrations that already have an API specification are usually simpler to rebuild. Ask for a fixed-scope estimate in writing. A sound estimate should list the inventory deliverable, the number of workflows in scope, the integrations to rebuild, the test cases, the parallel-run period and the cutover window. DeployOpen agrees scope, deliverables and timelines in writing before work begins, so the estimate should come from that written scope.

A replacement needs at least three decision points and one owner for each. The playbook owners, usually senior analysts or the SOC engineering lead, must confirm which automations are still needed, which are obsolete and what each should do in Shuffle. The infrastructure owner must decide where the Shuffle server, its OpenSearch database and the Orborus runtime nodes will run, and who patches them. A security approver must sign off on credential handling, network exposure, single sign-on, data retention and the cutover plan. Integration owners for each connected tool, such as the SIEM, ticketing system, identity provider and email gateway, must confirm API access and test accounts. If your organization has a records or audit function, that group should also approve how closed incidents and their evidence are kept. Naming these owners before the inventory starts prevents most delays.

Yes, for a small playbook set with stable integrations and few custom functions. A team with Docker or Kubernetes experience can stand up Shuffle from the install guide, which lists a minimum of 4 GB of RAM and supports Docker and Kubernetes. The hard part is usually the inventory, not the workflow building. Your team must list every case type, field, role, task, custom function, integration and scheduled job, and must identify which of them the business still relies on. Credentials need a separate plan: Shuffle encrypts saved app credentials with the SHUFFLE_ENCRYPTION_MODIFIER secret, so the value must be backed up in a secure store before the first workflow runs, because losing or changing it breaks every saved authentication. Closed-case retention also needs a decision before cutover. If the inventory is incomplete, workflows will be rebuilt against the wrong assumptions, which is why many teams hire help for that phase only.

It changes the cost mix. Shuffle's open-source edition includes all features, and its paid tiers differ in feature limits, scaling and support. Since version 2.1.1, those limits are enforced between the open-source and enterprise editions, so you should confirm which edition covers your intended scale. Shuffle's pricing article describes its paid licensing as based on app runs, meaning actions that execute in a workflow, while triggers and skipped actions are not counted, and it states that users, apps and workflows are unlimited. Your operating cost will therefore come from servers, storage, the OpenSearch database, backups, high-availability components and the staff who maintain workflows. Shuffle's configuration guidance recommends an OpenSearch cluster, shared cache and more than one Orborus node for high availability. Ask the vendor to confirm how app runs are counted for your expected alert volume, and model that figure against your current per-user subscription.

Several checks should pass in a staging environment before any production alert is routed to Shuffle. Confirm the backend API on port 5001 is reachable only from the networks that need it, and that the frontend is protected behind your standard controls. Test the OpenSearch cluster, including restore from backup, and confirm the number of Orborus nodes can keep workflows running if one fails. Verify that the SHUFFLE_ENCRYPTION_MODIFIER value is stored and recoverable. Check single sign-on: Shuffle added SAML in version 0.9.16 and OpenID Connect in 1.0.0, and the Shuffle extensions documentation notes that SAML is being deprecated on Shuffle Cloud in favor of OpenID Connect. Run each rebuilt workflow against recorded sample alerts and compare the outcome with the QRadar SOAR result. Keep the old platform read-only for a defined period so you can roll back.

A useful quote states scope in terms your team can check. Ask for the inventory deliverable first, listing playbooks, custom functions, integrations, case types, fields and scheduled jobs, with a decision for each item: rebuild, retire or keep as-is. Ask for the list of environments included, such as staging and production, and the test plan that defines what passes. Require a named cutover and rollback plan, the parallel-run period, and the conditions that end it. Confirm how credentials, encryption secrets and single sign-on are handled and documented. Ask what knowledge transfer is included and what the handover documents will contain. Clarify what is excluded, such as data migration of closed cases, changes to alert sources, or Shuffle licensing. Finally, ask whether ongoing support, upgrades and testing should be a separate retainer, and how each is priced. DeployOpen prepares a quote from the written scope, so the clearer the inventory, the more precise the quote.