Can Shuffle replace Sumo Logic Cloud SOAR playbooks?
A SOC or platform team whose Cloud SOAR playbooks and integrations must run inside its own infrastructure, whether because of a renewal or a data residency rule, has a credible self-hosted candidate in Shuffle. Shuffle is a security automation platform licensed under AGPL-3.0, and its documentation states that all features are available in the open-source edition, with paid tiers differing in feature limits, scaling and support. The main gaps are not feature gates but integration parity, case management and the out-of-the-box actions that Sumo Logic bundles with its hundreds of pre-built integrations. Plan the migration around those three gaps rather than around the platform itself.
Start with an inventory. For each Cloud SOAR playbook, list the trigger, every action, the integration it calls and the output it writes back. Then check each integration against Shuffle's app catalog and its OpenAPI-based App Creator, or plan a Python app built with the Shuffle app SDK for anything missing. Confirm with Shuffle which apps are maintained and which you must own, because each custom app becomes a versioned Docker container your team patches. Also confirm where incident records will live, since Shuffle automates response but does not replace a case management system, and your analysts still need one of record. Note that Sumo Logic's Open Integration Framework will not carry over automatically, so every custom connector needs an owner.
Treat the credential store as a migration dependency. Shuffle encrypts saved app credentials and API keys in OpenSearch using the SHUFFLE_ENCRYPTION_MODIFIER secret, and losing or changing that value breaks every saved app authentication. Record the value in your secrets manager before the first workflow runs, and re-enter each credential in a test environment first. Pilot one high-volume playbook in a non-production environment, measure its run count against the app run metric described in Shuffle's pricing article, and rebuild the rest in waves.
Which Cloud SOAR capabilities map to Shuffle
This table maps the main Sumo Logic Cloud SOAR capabilities to what Shuffle provides, the work a migration adds, and the items to confirm with the vendor. Read each row as covered, partial or to be confirmed: partial means Shuffle has the building block but the parity depends on apps you will build or verify. The main takeaway is that the playbook logic moves well, while the catalog of pre-built integrations must be checked one by one.
| Cloud SOAR capability | Shuffle equivalent | Status and what to confirm |
|---|---|---|
| Customizable playbooks | Workflows built in the Shuffle visual editor, with branching and actions | Covered. Rebuild each playbook by hand; export of Cloud SOAR playbook logic is not a documented path. |
| Pre-built integrations (hundreds) | Shuffle apps, built from OpenAPI specifications or written in Python | To be confirmed. Ask Sumo Logic for the full integration list and check each one against Shuffle's app catalog. |
| Open Integration Framework | Shuffle app SDK and App Creator for custom apps | Partial. Custom integrations are possible, but you must write, version and maintain each app container. |
| Investigation and incident management | Workflows that enrich alerts and open tickets in external case systems | Partial. Shuffle orchestrates the steps; case records and analyst history need a separate system of record. |
| Response actions (containment, blocking, notifications) | Actions executed through apps against your security tools | To be confirmed. Each action depends on an app for your specific endpoint, firewall or identity platform. |
| Credentials for connected tools | Encrypted app credentials stored in OpenSearch with a secret key | Covered. Back up the encryption secret, since losing it breaks every saved app authentication. |
| Single sign-on for analysts | SAML and OpenID Connect on-premises with per-tenant enforcement | Covered. Confirm your identity provider supports OpenID Connect, since SAML is being phased out on Shuffle Cloud. |
| Sumo Logic log search and correlation feeding SOAR | Not part of Shuffle; use OpenSearch, Wazuh or another SIEM as the trigger source | Outside Shuffle. Plan the alert source and its webhook or API connection as a separate work item. |
Shuffle, and where other self-hosted options fit
Shuffle is the open-source SOAR platform most directly comparable to Sumo Logic Cloud SOAR, so it anchors this section. The other cards cover the options teams weigh before committing, along with the gaps each one leaves against playbooks, case handling and integrations.
Shuffle as the primary option
Shuffle is a security automation (SOAR) platform that began in mid-2019 for the CERT and SIRT community, and its code is licensed under AGPL-3.0. Shuffle states that all features are available in the open-source edition, with paid tiers differing in feature limits, scaling and support. For a Sumo Logic Cloud SOAR replacement, confirm in writing which limits apply to your planned workflow volume before you rely on the free edition.
Shuffle deployment and runtime
Shuffle runs a frontend, a Go backend API and an OpenSearch document database, with Orborus nodes that start a worker for each workflow execution. Its documented deployment options include Docker Compose on one server, Docker Swarm, a hybrid setup with Shuffle Cloud and a local Orborus, and Kubernetes with Helm charts. Map your existing playbook execution volume to these runtime components before choosing a topology.
Pricing and app runs
Shuffle's commercial licensing uses one metric, app runs, which counts actions that actually execute in a workflow, while triggers and skipped actions are not counted. Users, apps and workflows are unlimited on that model. Ask any vendor, including Shuffle, to show how a sample of your real playbooks would be metered, so you can compare it with Sumo Logic credit consumption.
High availability and credential handling
Shuffle's configuration guidance for high availability includes an OpenSearch cluster, optional Memcached, NFS for shared files across backends and more than one Orborus node. Saved app credentials are encrypted with AES-256 using the SHUFFLE_ENCRYPTION_MODIFIER secret, and losing or changing that value breaks every saved app authentication. Store that secret in a managed vault and document its recovery path before cutover.
General workflow engines
Some teams build response playbooks on a general workflow automation engine instead of a security product. This can suit teams that already operate that engine and have few security-specific actions. The gap is that case management, security-specific app catalogs and analyst-facing approval flows must then be built and maintained in-house, so count that effort against the Cloud SOAR playbooks you are retiring.
SOAR within the SIEM vendor
Some teams keep response automation inside the SIEM platform they already run, including free or bundled tiers. This keeps fewer moving parts, but it ties playbooks to that vendor's licensing and data location, which is the same lock-in question driving this migration. Confirm which automation features the free tier includes, which integrations are supported, and whether playbooks export in a documented format.
Running Shuffle alongside Sumo Logic during transition
In this model, Sumo Logic keeps detecting and raising alerts while Shuffle takes over the response actions. Shuffle workflows start from a trigger, so the Sumo Logic side has to deliver alert context in a form Shuffle can receive, usually through a webhook or an API call that Shuffle can accept. Sumo Logic still owns the detection logic, the alert fields and the scheduling of searches, so any change to those is a change that Shuffle workflows depend on.
- Trigger path: Confirm which Sumo Logic alert action or connector posts to a Shuffle webhook, and where that webhook URL is registered in your environment.
- Alert payload: Agree on the fields each workflow expects, such as alert name, severity, source host and search link, and keep them stable across Sumo Logic changes.
- Credentials: Store Sumo Logic API access in Shuffle's encrypted app credentials, and record who owns rotation.
- Playbook ownership: Decide which team edits workflows that act on Sumo Logic alerts.
- Network path: Confirm whether your Shuffle server or a hybrid Orborus node can reach Sumo Logic endpoints, and whether inbound connections to Shuffle are permitted.
Before go-live, test one alert end to end in a non-production tenant and confirm the payload, the authentication and the outbound and inbound network rules with your own security and network teams.
A parallel run keeps Cloud SOAR live while Shuffle workflows execute the same playbooks in a controlled way. The aim is to compare outcomes, not to double-act. Teams typically route a subset of alert types to Shuffle, mirror the rest in a dry-run form where the playbook records what it would do without executing actions against production systems, and review the differences before moving more alert types across. Shuffle counts app runs, so duplicated execution in both platforms also duplicates the actions your team pays for on the Shuffle side.
- Scope split: Assign each alert category to exactly one platform for response actions at any time.
- Dry-run records: Log intended actions in Shuffle and compare them with Cloud SOAR execution history.
- Duplicate action guard: Prevent both platforms from blocking the same account or isolating the same host.
- Case reconciliation: Decide where case records are written during the overlap so analysts do not search two systems.
- Exit criteria: Write down the comparison results and sign-off owners that allow each alert category to move.
Confirm with your SOC lead how long the overlap runs and who can override the split during an incident, because that decision is operational, not a vendor setting.
Full retirement starts once every playbook in use has a working Shuffle equivalent, every integration has been verified, and analysts have the case records they need. Retirement is more than disabling playbooks. Export or document the Cloud SOAR playbook logic, keep the execution history your audit or incident review requires, and remove any Sumo Logic connections that existed only for Cloud SOAR. Credentials and webhooks left behind become an unmanaged access path, so they should be revoked as part of the closure.
- Playbook inventory: List each active Cloud SOAR playbook and mark its Shuffle replacement and test date.
- Evidence retention: Preserve execution logs, approvals and incident records under your retention policy before access ends.
- Credential cleanup: Revoke Sumo Logic API keys and remove webhook endpoints that Cloud SOAR used.
- Subscription end: Confirm with Sumo Logic the notice terms and the date Cloud SOAR access stops, using your contract.
- Rollback plan: Keep the documented playbooks and a restore path for a defined period after shutdown.
Ask your Sumo Logic account team, in writing, what data and execution history remain available after the subscription ends, and how long.
Whichever situation applies, the connection between Sumo Logic and Shuffle is the most common point of failure. Sumo Logic's documentation covers how alerts and integrations are configured, and Shuffle's documentation covers how a trigger is created and how apps authenticate. What the documents cannot tell you is how your network, proxies, certificates and access policies behave, so those checks belong to your environment and should be run before any production alert depends on them.
- Reachability: Test in both directions where needed, from the Sumo Logic side to the Shuffle endpoint and from Shuffle workers to Sumo Logic APIs.
- Certificates: Confirm that TLS certificates on the Shuffle endpoint are trusted by the sending service.
- Rate and quota limits: Check any API rate limits on the Sumo Logic side against expected alert volume during a surge.
- Failure handling: Define what happens when a webhook fails, including retries and alerting on the failure itself.
- Access scope: Use an API key with only the permissions the workflow needs.
Record the results in your change ticket, and repeat the checks after any Sumo Logic or Shuffle upgrade.
How to move playbooks, integrations and cases
This sequence moves Cloud SOAR playbooks, integrations and case handling into a self-hosted Shuffle deployment that your team operates, and ends with a tested cutover where each workflow has been proven against the same inputs it handled in Sumo Logic.
Inventory playbooks, actions and triggers
Export a list of every Cloud SOAR playbook, including the triggers that start it, each action it calls, the integrations those actions depend on, and the people or systems that receive its output. Your security operations lead should own the list, with an engineer confirming the trigger sources against the Sumo Logic console. The step is done when every active playbook has a row in a shared inventory and any playbook with no owner is flagged for a decision. Ask Sumo Logic to confirm how playbook definitions can be exported, because the export format determines how much of the inventory you can generate automatically.
Classify each item as rebuild, replace or retire
For each playbook, decide whether to rebuild it as a Shuffle workflow, replace it with a different mechanism such as a scheduled search or an alert routed to a ticket queue, or retire it because nobody has run it in a long time. Involve the analysts who triage the alerts, since they know which steps are used in practice. The output is a decision register with one row per item, a reason and a named owner. Keep the register in version control so later changes are traceable during audits.
Stand up a Shuffle server
Choose a deployment layout that matches your availability needs: a single server with Docker Compose for a pilot, a distributed Docker Swarm layout, or Kubernetes with Helm charts. Shuffle's architecture uses a frontend, a Go backend API, an OpenSearch document database and Orborus runtime nodes that start a worker for each workflow execution. Pin the Docker image tag to a specific release rather than the latest tag for production, and confirm the release notes before upgrading. The step is done when the frontend loads, an administrator can log in and a test workflow runs end to end on an Orborus node.
Rebuild integrations as Shuffle apps
Recreate each integration that the retained playbooks use as a Shuffle app. You can generate an app from an OpenAPI specification in the App Creator or write one in Python with the Shuffle app SDK, and each app runs as a versioned Docker container. Start with the integrations used by the most important playbooks, and test each app against a sandbox instance of the target system before connecting production accounts. The output is a list of apps with versions, owners and the test evidence that each action returns the fields your playbooks expect.
Store credentials under a managed encryption secret
Enter each integration credential and API key into Shuffle so it is stored in OpenSearch encrypted with AES-256 under the SHUFFLE_ENCRYPTION_MODIFIER secret. Keep that secret in your existing secrets manager, restrict who can read it, and record its location in your runbook. Changing or losing it breaks every saved app authentication, so test a restore from backup in a non-production environment before relying on the stack. The step is done when a credential can be reloaded in a fresh test instance using only the secret and a backup.
Recreate out-of-the-box actions by hand
Cloud SOAR's pre-built integrations and playbook actions do not transfer automatically, so each one you still need must be built as a Shuffle app or workflow step and tested. Expect to rebuild enrichment lookups, ticket creation, notification and containment actions that you depended on without thinking about them, because the Cloud SOAR library is the vendor's code and not yours. Compare the Cloud SOAR action list with the Shuffle app catalog and log each gap. The output is a gap list that feeds the rebuild backlog, and any action with no equivalent is documented with its manual fallback.
Move cases and set up human review
Decide where case records live after cutover. Shuffle runs workflows and stores execution results, but treat it as the automation layer and confirm with your incident response lead whether cases stay in your existing ticketing or case system and are linked from workflow outputs. Define how an analyst approves a containment step, how an open case is handed over, and how historical cases are archived from Sumo Logic. The step is done when a sample incident travels from alert to case to closure with each handoff recorded.
Run parallel tests and cut over
Run each rebuilt workflow in parallel with its Cloud SOAR counterpart against replayed or recent alerts, and compare the actions taken, the enrichment returned and the case records created. Investigate every difference, fix the workflow or app, and repeat until the results match for the agreed set of alerts. Then switch triggers from Sumo Logic to Shuffle one playbook at a time, keeping the Cloud SOAR version available for rollback until the owner signs off. Confirm your Shuffle edition and limits before go-live, because Shuffle enforces limits between its open-source and enterprise editions.
Where case management lives after the move
The first thing to settle is that Shuffle orchestrates and records workflow executions, and that is not the same as owning cases. Shuffle runs playbooks, stores their execution results in its OpenSearch document database, and gives you the workflow trail for each run. Whether it also gives you case records, owners, status fields, analyst queues and SLA tracking depends on the Shuffle features and editions you deploy, so confirm each of those against the current Shuffle documentation before you design the target state. Do not assume a Cloud SOAR case will map to a Shuffle object one for one.
For most teams the practical answer is to pair Shuffle with a dedicated ticketing or case tool that you host yourself and integrate through Shuffle's app framework. In that design, the case tool holds ownership, queues, comments and closure reasons, while Shuffle attaches playbook results to the case. Decide early which system is the source of truth for case status, because two systems that both claim it will drift. Also confirm that the integration you need exists as a Shuffle app or can be built from an OpenAPI specification, and test it against your own case tool version.
Ask your Sumo Logic account team and review the Cloud SOAR documentation for how existing cases, their comments, timestamps and attachments can be exported. The facts available for this page do not describe a Cloud SOAR export path, so treat the history as unknown until someone shows you a working export. Decide with your compliance lead how much closed-case history must be retained and where it will be stored, because open cases will need to be closed or re-created in the new tool before cutover.
What does moving Cloud SOAR to Shuffle cost and take?
What drives the cost of moving Cloud SOAR playbooks to Shuffle?
The main drivers are the number of playbooks, how many integrations each one depends on, and how much of each playbook's logic must be rebuilt rather than copied. Shuffle's software licence for its open-source edition has no fee, so the one-time costs are the rebuild work, the infrastructure you run, and staff time. The recurring costs are the servers, the OpenSearch cluster, backups, upgrades and the people who maintain playbooks after go-live. Ask any quote to split these into one-time and recurring lines, and to name who performs each piece.
Does Shuffle's enterprise licence charge by app runs?
Shuffle prices its paid tiers on one metric, app runs, which means actions that actually execute in a workflow. Triggers and skipped actions are not counted, and users, apps and workflows are unlimited. Shuffle's pricing article describes the metric, but the volume you will reach depends on how often your playbooks fire and how many actions they contain. Before choosing a tier, measure your current Cloud SOAR activity, map it to likely action counts in Shuffle, and confirm the current limits and rates with Shuffle in writing.
What changed in Shuffle's open-source edition limits since v2.1.1?
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 v2.1.1, the limits between the open-source and enterprise editions are actively enforced. Plan around this by testing your target workflows against the open-source limits in a non-production environment, and confirm with Shuffle which limits apply to the version you deploy. Check this again before each upgrade, because the limits are a product decision that can change.
Can our team migrate Cloud SOAR to Shuffle without outside help?
A team with automation engineers who know both platforms can do it alone, especially for a small playbook library. The work needs people who can read Cloud SOAR playbooks, write Shuffle workflows, build or adapt app integrations from OpenAPI specifications or the Python SDK, operate Docker or Kubernetes, and run an OpenSearch cluster. If those skills are thin, a fixed-scope engagement with DeployOpen can cover planning, implementation, hardening and documentation, with the scope and deliverables agreed in writing before work starts.
What does the migration need from our own team?
Expect to supply a named owner for the security operations process, access to the Cloud SOAR playbook library and its integration credentials, a list of the actions analysts depend on, and time from the people who triage incidents to test rebuilt playbooks. You will also need infrastructure owners to provide the hosts or cluster, network rules for Orborus and the apps, and a process for storing the encryption secret. Identify these people before scoping, because delays in access are a common reason migrations run late.
How should we design Shuffle for high availability?
Shuffle's configuration documentation recommends an OpenSearch cluster, optional Memcached for a shared cache, NFS for shared files when running several backends, the backend and frontend scaled across all servers, and more than one Orborus node so workflows keep running if one fails. Choose the deployment architecture (single server with Docker Compose, Docker Swarm, hybrid with Shuffle Cloud, or Kubernetes with Helm) based on your availability target and staff skills. Each HA component adds infrastructure cost and operating work, so ask any quote to price the chosen design explicitly.
What should we ask for in a fixed-scope quote for this move?
Ask for a written scope listing the playbooks and integrations included, the number of workflows to rebuild and test, the Shuffle edition and deployment architecture, the infrastructure design and HA model, backup and upgrade responsibilities, and the handover documents. Request a list of out-of-the-box Cloud SOAR actions that will be recreated by hand, a statement of what is excluded, the testing approach for each playbook, and the acceptance criteria. Also ask who holds the SHUFFLE_ENCRYPTION_MODIFIER secret after handover, since losing it breaks every saved app authentication.
How DeployOpen scopes and delivers a SOAR module replacement
DeployOpen approaches the move from Sumo Logic Cloud SOAR to Shuffle as a fixed-scope engagement that starts with an inventory of your playbooks, integrations and case workflows. The work is planned, implemented, tested and documented inside your own infrastructure, with ongoing support available as a retainer.
How we scope
- Inventory every Cloud SOAR playbook, trigger and integration that is in active use today.
- Classify each integration as an out-of-the-box action to rebuild, a custom app to write, or a step to retire.
- Record scope, deliverables and timelines in writing before any build work starts.
How we build
- Choose the Shuffle deployment architecture that fits your environment, such as Docker Compose, Docker Swarm, Kubernetes or hybrid Orborus.
- Recreate playbooks as Shuffle workflows and package custom integrations as versioned app containers.
- Test each workflow against sample alerts and record the expected outcome before cutover.
How we hand over
- Document the workflow inventory, app versions, credential handling and the SHUFFLE_ENCRYPTION_MODIFIER backup procedure.
- Walk your SOC and platform teams through running, changing and rolling back workflows on your servers.
- Deliver runbooks for the case management process and for the actions that were rebuilt by hand.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Plan Shuffle version upgrades against the release notes and test workflows in a staging environment first.
- Confirm with us which edition limits and support terms apply to your deployment before go-live.
