Migrate from Splunk SOAR to Shuffle

How to migrate from Splunk SOAR to Shuffle without losing response coverage

Teams leaving Splunk SOAR usually do so because of a renewal, a licensing change or a data residency requirement, and the first thing to understand is that Shuffle is a self-hosted replacement that needs playbook rewrites, not a file import. The work is normally led by a platform or security engineering team, with the SOC as the acceptance group. Your Splunk SOAR playbooks exported as .tgz archives document the logic you run today, but Shuffle workflows are built in its own editor, and any Python custom function must be re-implemented as an app or as an action in an existing app. Plan the effort around the number of active playbooks, how many custom functions they call, and how many distinct integrations (assets) they depend on, not around file counts.

Shuffle's code is licensed under AGPL-3.0, while its workflows, documentation, apps and app specifications are under MIT, so your legal review should cover both the platform you deploy and any apps you write or modify. Use the Shuffle architecture documentation to choose a deployment model before rewriting anything, because the hybrid option with a local Orborus needs no inbound firewall ports, while a single Docker Compose server is not scalable without changes. Confirm with your own environment whether the Splunk SOAR playbooks run on hosts that will be retired, and inventory which assets hold credentials, since Shuffle stores saved app authentication encrypted with a secret that must be backed up and kept unchanged.

Keep response coverage by running both platforms in parallel for a defined set of low-risk playbooks, and by keeping Splunk or Wazuh as the alert source so that detections continue to arrive while you rebuild the response logic. Ask Splunk and your SIEM team to confirm which alert forwarding paths will point to Shuffle, and test each workflow with recorded sample alerts before switching a queue. Do not cut over a playbook until the Shuffle version has been tested against the same case outcomes as the Splunk SOAR version, and keep the Splunk SOAR instance readable until your retention and audit requirements for past cases are met. Before you start, check the current Splunk SOAR support and export options with Splunk, and confirm the Shuffle release you will deploy against the Shuffle GitHub releases page.

Which Splunk SOAR capabilities map to Shuffle, and which need rework

This table compares how each Splunk SOAR capability carries over to Shuffle. Read the status column first: clean items move with configuration, needs rework items require rebuilding, and gap items must be confirmed against Shuffle's current documentation before you plan the move. The main takeaway is that playbooks, custom Python and app connections need engineering effort, while SSO carries over more directly.

Capability	Splunk SOAR	Shuffle	Status
Playbooks	Exported as .tgz playbook archives from the playbook editor	Archives do not import as Shuffle workflows, so each playbook is rebuilt as a workflow	Needs rework
Python custom functions	Python code called from playbooks, converted to Python 3 for cloud moves	Rewritten as Shuffle apps using the Python app SDK and run as versioned containers	Needs rework
Apps and integrations	Splunk SOAR apps for vendor tools	App creator builds integrations from OpenAPI specifications; premade apps cover many security tools	Needs rework
Assets and credentials	Asset configurations stored per app in Splunk SOAR	Saved app authentication is re-entered and encrypted in OpenSearch with AES-256	Needs rework
Containers and cases	Container and case handling with analyst views	Confirm case handling and analyst views against Shuffle's current docs before planning	Gap
Scheduling	Scheduled playbook runs configured in Splunk SOAR	Recreate schedules as Shuffle workflow triggers and test each one	Needs rework
Single sign-on	Identity configuration managed within Splunk SOAR	SAML since 0.9.16 and OpenID Connect since 1.0.0, enforceable per tenant on-premises	Clean
Alert source	Splunk or another SIEM sends alerts into playbooks	Point the existing alert forwarding at Shuffle triggers and confirm each trigger type	Needs rework

What data and integrations move from Splunk SOAR, and what must be rebuilt

A Splunk SOAR migration moves playbook logic, but not the runtime around it. Playbook archives can be exported, while custom functions, asset configurations and alert feeds need deliberate rebuilding in Shuffle. The cards below separate what can be carried over from what must be recreated and verified.

Playbook archives as .tgz exports

Splunk documents exporting and importing playbooks as .tgz playbook archives, which gives you a portable copy of each playbook's structure and logic. Export every playbook you intend to keep, including inactive ones, and store the archives under change control before any work starts. Treat the archives as a reference for logic, not as a file Shuffle will run directly, since the actions inside them map to Splunk SOAR apps that Shuffle does not execute unchanged. Confirm the export version and editor type for each playbook.

Classic editor playbooks needing rebuild

Splunk noted that the classic playbook editor was deprecated in 2024, so playbooks built in that editor carry the most rework risk. Identify which playbooks were authored in the classic editor and which used the newer editor, because the exported structure and the manual redesign effort will differ. Plan to redraw each workflow in Shuffle's workflow editor and test branch by branch against the original decision logic. Playbooks from the classic editor are the first to inventory.

Custom functions as Shuffle apps

Splunk SOAR custom functions are Python code that must be converted to Python 3 before Splunk's own cloud migration path, and that same code cannot be dropped into Shuffle. Each custom function should become a Shuffle app written with the Python app SDK, or be expressed as an OpenAPI-based app if the logic calls an HTTP API. Review every function for hard-coded hosts, local file paths and Splunk-specific helper calls, then write unit tests against sample inputs. Shuffle apps run as versioned Docker containers, so each one also needs its own image build and version pinning.

Asset configurations re-entered as app authentication

Splunk SOAR assets hold the connection settings and credentials for each integration, and these do not transfer as a set into Shuffle. Recreate each one as a Shuffle app authentication, then test it with a read-only action before enabling any response step. Keep a written inventory that maps each old asset to its new authentication, its owner and the service account it uses. Rotate credentials where the old asset was shared or long-lived, because the migration is a good point to reduce standing access.

Encryption secret that must be preserved

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 every saved app authentication, so it must be stored in your secrets manager and backed up with the OpenSearch data. Set it before the first production authentication is saved, and record it in the same vault as your database backups. Confirm the procedure for restoring a backup into a new environment that uses the same value.

Splunk or Wazuh alert feed as trigger

Playbooks in Splunk SOAR are usually started by alerts or containers pushed in from a SIEM or detection tool, so that trigger must be reconnected to Shuffle before cutover. Decide whether Splunk or Wazuh remains the alert source, then configure the forwarding path and a Shuffle webhook or trigger that receives it. Run both pipelines in parallel for a defined window and compare alert counts and workflow outcomes. Confirm whether your SIEM sends alerts as events, notable records or API calls, since that decides the trigger type you configure.

The migration sequence from inventory to decommission

This sequence moves Splunk SOAR playbooks, apps and assets to Shuffle in controlled stages, so each playbook is proven on a test install and in parallel with Splunk SOAR before any production cutover. It ends with Splunk SOAR retired only after its archives are kept and verified.

Inventory playbooks, apps and assets
List every playbook, custom function, installed app and configured asset in Splunk SOAR, and record for each one its trigger, the systems it calls, the credentials it uses and its owner. Export each playbook as a .tgz archive from the playbook editor so the source is preserved before anything changes. The output is an inventory register with one row per playbook, marking which ones depend on custom Python code, which need a Shuffle app, and which are no longer used. The step is done when the register has an owner and a migration decision for every row.
Classify apps and custom functions
Sort each Splunk SOAR app and Python custom function into three groups: a premade Shuffle app exists, an app can be built from an OpenAPI specification with the App Creator, or the logic must be written with the Shuffle app SDK. Confirm the current app coverage with Shuffle directly, because catalog contents change between releases. The output is a mapping table from each Splunk SOAR app and function to its Shuffle equivalent, with the people who will test each one named. The step is done when no function is left without a target.
Build a pilot on a non-production Shuffle install
Stand up a non-production Shuffle instance using Docker Compose for a single server or Kubernetes with Helm charts if your platform team already runs clusters. Note that the default Docker Compose setup is not scalable without changes, and that Shuffle needs at least 4 GB of RAM. Store the SHUFFLE_ENCRYPTION_MODIFIER value in your secrets manager before the first credential is saved, because losing it breaks every saved app authentication. Rebuild one low-risk playbook first and run it against test systems. The output is a tested workflow set with recorded run results and a note on any gaps. The step is done when the pilot workflows pass on test data.
Connect the alert source to both platforms
Keep Splunk or Wazuh as the alert source and configure it to send the same alerts to Splunk SOAR and to the Shuffle test workflows, using a copy of the alert feed rather than moving the detection content. Map each Splunk SOAR asset to a Shuffle app authentication, and confirm that Shuffle runs its executions through Orborus on the hosts you intended. The output is a documented data path for each alert type, with the credentials and asset owners recorded. The step is done when a test alert reaches both platforms.
Run both platforms in parallel
For an agreed period, let Splunk SOAR and Shuffle receive the same alerts while analysts keep acting in Splunk SOAR. Compare the outcomes of each playbook run, including enrichment results, ticket or case updates, containment actions and errors. Record every difference and decide whether it is a Shuffle rule to fix, an app to adjust or an accepted change. The output is parallel-run comparison notes with a signed-off list of differences. The step is done when each production playbook has produced matching results or an approved explanation for any mismatch.
Cut over playbook by playbook
Move production playbooks to Shuffle one at a time, starting with those that carry the least risk, and disable each Splunk SOAR playbook only after its Shuffle replacement has been approved by its owner. Keep a rollback path for each cutover by leaving the Splunk SOAR version available until the change is confirmed. Record the date, the approver, the Shuffle workflow version and any open issue in a cutover log. The output is a cutover log that covers every playbook in the register. The step is done when every row in the inventory shows either a cut over workflow or a retirement decision.
Decommission Splunk SOAR and retain archives
Once all playbooks are cut over or retired, stop scheduled runs and disable the remaining Splunk SOAR assets, then keep the .tgz archives, the inventory register, the cutover log and the parallel-run notes in an archive your records policy covers. Confirm with Splunk, through your license or support agreement, what must happen to the Splunk SOAR instance and its data before you shut it down. Check that your audit or incident response teams can still reach the archived evidence. The output is a retained archive set and a decommission record. The step is done when the archive has been verified and the decommission has been approved.

How Shuffle's architecture changes the migration design

Shuffle's architecture splits the platform into a server side and a runtime side, and that split should shape how you plan the migration from Splunk SOAR. The server side is a frontend, a Go backend API listening on port 5001, and 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 starts the app containers the workflow calls. Your playbook rewrite is therefore not only a logic exercise: each migrated playbook becomes a set of containerized app calls that need capacity, credentials and network paths of their own. Plan the OpenSearch storage and the Orborus placement before you import anything, and treat the first Shuffle environment as a pilot rather than a copy of your Splunk SOAR host.

Shuffle documents four deployment architectures: a single server with Docker Compose, distributed Docker Swarm, a hybrid of Shuffle Cloud with a local Orborus that needs no inbound firewall ports, and Kubernetes with Helm charts. The install guide says Docker and Kubernetes are supported, that the default Docker Compose setup is not a scalable build without changes, and that a minimum of 4 GB of RAM is needed. Treat 4 GB as a floor for a lab, not a sizing answer. Your actual sizing depends on the number of workflows, how often they run, the apps they call and your OpenSearch retention. Confirm these with your own load tests and with the current configuration guidance in the Shuffle configuration docs before choosing an architecture.

For high availability, Shuffle's configuration docs recommend an OpenSearch cluster, optional Memcached for a shared cache, NFS for shared files when several backends run, the backend and frontend scaled across all servers, and more than one Orborus node so workflows keep running if one node fails. Decide early whether a Splunk SOAR replacement must survive a node loss, because that choice determines whether you need the multi-node layout from day one. Ask your platform team who will operate the OpenSearch cluster, the NFS share and the Orborus nodes after handover, and whether they have monitoring for each. Keep the encryption secret SHUFFLE_ENCRYPTION_MODIFIER under the same change control as the cluster, because the docs warn that changing or losing it breaks every saved app authentication.

How the migration differs for on-premises and cloud Splunk SOAR owners

Owners of Splunk SOAR (On-premises) usually face a choice between an upgrade, a move to Splunk SOAR (Cloud) and replacement. Splunk documents migrating administration settings, apps, playbooks and custom functions to Splunk SOAR (Cloud), but that path requires converting custom code to Python 3 first. Replacement with Shuffle means exporting playbooks as .tgz archives and rebuilding them as Shuffle workflows, so the effort goes into workflow logic and app authentication rather than a platform conversion.

Export before deciding: Export playbooks and record which ones depend on custom functions, since those carry the rewrite cost under any path.
Compare the two paths on the same inventory: Count the playbooks that would need Python 3 conversion for cloud and the playbooks that would need rebuilding for Shuffle.
Plan the server footprint: A self-hosted Shuffle needs its own hosting, OpenSearch storage and a minimum of 4 GB of RAM for the install guide's setup, which replaces what the Splunk SOAR server carried.
Keep the alert source separate: Splunk or Wazuh can continue sending alerts while playbooks move, so the SIEM connection is not the blocking step.
Confirm the upgrade window: Check the support timeline for your current Splunk SOAR minor version with Splunk before choosing a path.

Before committing, confirm with Splunk which Python 3 conversions your custom functions require and compare that estimate with the rebuild effort for Shuffle.

Teams already on Splunk SOAR (Cloud) do not face the platform conversion that on-premises owners do, because Splunk hosts and manages the service. Their migration to Shuffle starts from exported playbooks and the list of apps and assets configured in the cloud tenant. Exports come from the playbook editors, and each playbook must be reimported or rebuilt as a Shuffle workflow, with credentials re-entered under Shuffle app authentication.

Export the playbook set: Download each playbook as a .tgz archive and keep a record of the saved versions that run in production.
Map each app to a Shuffle app: Check whether a premade Shuffle app or an app built from an OpenAPI specification covers the same tool.
Rebuild credentials, not just logic: Saved app authentication is stored in Shuffle, encrypted with the SHUFFLE_ENCRYPTION_MODIFIER secret, so credentials are entered again in the new environment.
Decide hosting: Shuffle Cloud at shuffler.io is available, or the team can self-host with Docker or Kubernetes, which changes who operates the platform.
Run in parallel: Keep Splunk SOAR (Cloud) active until the rebuilt workflows produce matching results on live alerts.

Confirm with your Splunk account team how long exports remain available before you start, and inventory every asset the playbooks depend on.

What usually goes wrong when moving playbooks to Shuffle

Most failed Splunk SOAR to Shuffle moves fail on operational details rather than on playbook logic. The cards below cover credentials, undocumented behavior, parallel running, runtime availability, run-based cost and identity setup, with a prevention step for each.

Lost encryption modifier

Shuffle encrypts saved app credentials and API keys in OpenSearch with AES-256, keyed by the SHUFFLE_ENCRYPTION_MODIFIER secret. If that value is lost or changed during a rebuild, every saved app authentication stops working at once. Before cutover, record the secret in your vault, confirm it is identical on every backend, and test one authenticated app action in a restored copy of the environment. Treat the value as a key that must survive backups and disaster recovery.

Undocumented playbook logic

Splunk SOAR playbooks often carry decisions that exist only in filter conditions, custom functions or an analyst's habit, such as suppression rules or exceptions for specific asset groups. Exporting a .tgz archive preserves the workflow but not the reasoning behind it. Before rebuilding each playbook in Shuffle, have the owning analyst walk through its branches and write down the expected output for sample alerts. Compare those outputs against the new workflow during testing.

Duplicate alerts during parallel run

Running Splunk SOAR and Shuffle against the same SIEM alert feed can open two cases, send two ticket updates or block the same host twice. Duplicates erode analyst trust and can trigger containment actions on production systems. Choose one owner per alert source and period, route the second platform to a test queue or a read-only mode, and define the cutover date for each playbook in writing before the parallel run starts.

Single Orborus node failure

Orborus polls the Shuffle backend for jobs and starts a worker for each workflow execution, so one Orborus node is a single point of failure for every automation. If it stops, workflows queue silently while alerts keep arriving. The Shuffle configuration docs recommend more than one Orborus node so workflows keep running after a failure. Deploy at least two, monitor job backlog and execution health, and test a node loss before going live.

Unscoped app run costs

Shuffle's paid licensing counts app runs, meaning actions that actually execute in a workflow, while triggers and skipped actions are not counted. Loops, polling triggers and enrichment steps that run on every alert can multiply run volume faster than expected. Before launch, map each playbook's expected executions per day, set the open-source or enterprise edition you need, and ask the vendor to confirm how the metric applies to your workflow patterns in writing.

SSO gaps between SAML and OIDC

Shuffle added SAML single sign-on in version 0.9.16 and OpenID Connect in 1.0.0, with per-tenant enforcement, and SAML is being deprecated on Shuffle Cloud in favor of OpenID Connect. Teams that configured SAML from an older guide may find role mappings, group claims or enforcement settings incomplete after switching. Decide which protocol your identity provider will use, configure it on the on-premises instance, and verify that admin, analyst and read-only groups map correctly before retiring local accounts.

What drives the cost and duration of a Shuffle migration

This table lists the factors that move the cost and effort of moving from Splunk SOAR to Shuffle, with the reason each one matters and how to keep it under control. Read it as a checklist to take into a scoping conversation, since no duration figure is given here and the real effort depends on your own inventory. Shuffle licensing is metered on app runs, so the main recurring cost driver is execution volume rather than headcount.

Driver	Why it moves cost or effort	How to keep it down
Number and complexity of playbooks	Each playbook must be rebuilt as a Shuffle workflow, and branching, loops and error handling add design and test time.	Inventory playbooks by use, retire unused ones, and rebuild the high-volume ones first.
Custom Python functions	Python custom functions must be rewritten as Shuffle apps using the app SDK or built from OpenAPI specifications, which is usually the largest rewrite effort.	Count functions per playbook, reuse one app across several workflows, and check whether a premade app already covers the integration.
Apps and assets to reauthenticate	Each Splunk SOAR asset must be recreated as a Shuffle app authentication, and every credential must be re-entered and tested.	Build a list of assets with owners and target systems before the cutover, and rotate credentials during the move, not after.
SIEM and alert source integrations	Keeping Splunk or Wazuh as the alert source means configuring trigger paths and checking payload fields in each workflow.	Confirm which SIEM feeds each playbook, and migrate one source at a time with a parallel run.
High availability requirements	Shuffle recommends an OpenSearch cluster, shared storage for several backends, and more than one Orborus node, which adds servers and configuration work.	Decide the availability target first, then size only the components it requires.
OpenSearch storage sizing	OpenSearch stores workflow data and encrypted app credentials, so retention settings and execution history drive disk and backup needs.	Set retention periods early, and test storage growth with realistic execution volumes before production.
App run volume (licensing)	Shuffle licensing is metered on app runs, meaning actions that execute in a workflow. Triggers and skipped actions are not counted, and users, apps and workflows are unlimited (Shuffle pricing article).	Reduce unnecessary actions in workflows, and ask the vendor how app runs are estimated for your expected alert volume.
Testing and validation	Each rebuilt workflow needs test runs against sandbox systems, and assessors may expect evidence of the results.	Reuse a standard test checklist for each workflow and record outcomes as you go.
Ongoing support and upgrades	Self-hosting makes your team responsible for upgrades, backups and patching, and this effort recurs after go-live.	Agree on the upgrade cadence and support scope in writing before the work starts.

Common questions before moving off Splunk SOAR

How much effort and cost does moving from Splunk SOAR to Shuffle involve?

The effort depends on how many playbooks, custom Python functions, apps and assets you run, not on the platform license alone. Cost comes from four components: the people who inventory and rewrite playbooks, the servers or cluster that host Shuffle, the OpenSearch storage behind it, and ongoing upgrades and support. Licensing is a separate line: Shuffle's open-source edition includes all features, and its paid tiers differ in limits, scaling and support, with licensing based on app runs. Setup and rewrite costs are one-time, while hosting, storage and support recur. Ask any implementation partner for a written scope that lists each playbook and function, the target architecture and the hosting assumptions before comparing numbers.

How long does a Splunk SOAR to Shuffle migration take?

No duration is given here because it depends on the inventory and the target design. The main variables are the number of playbooks and custom functions that need rewriting, how many apps and asset configurations must be recreated as Shuffle app authentications, whether you need a high-availability design, and how much testing your SOC requires before cutover. A fixed-scope written plan sets the timeline, with deliverables and milestones agreed before work starts. Ask for the schedule to be tied to that inventory rather than to a generic estimate.

What does the migration require from our internal team?

Your team must provide access to the existing Splunk SOAR instance, a complete export of playbooks and custom code, a list of active apps and assets with their owners, and people who understand which playbooks are used in live incident response. Security and platform engineers must also decide hosting, identity integration and secret handling. Expect subject-matter experts to review rewritten workflows and validate results against past cases, because they know which outcomes matter to the SOC.

Can our internal team migrate from Splunk SOAR to Shuffle on its own?

Yes, a team with Python, container and SIEM experience can do it, and Shuffle's documentation covers its architecture, configuration and app SDK. The practical question is capacity and risk: the team must rewrite custom functions as Shuffle apps, run OpenSearch and the Orborus runtime reliably, and test every workflow before cutover. Consider a hybrid model where internal staff own the workflows and an outside team handles the platform build, hardening and upgrades. Check your team's time against the inventory before deciding.

Can Splunk or Wazuh remain the alert source after the move?

Yes. Shuffle receives alerts through its triggers and apps, so Splunk or Wazuh can keep forwarding alerts while the response logic moves to Shuffle. Confirm the exact trigger and app configuration for your Splunk or Wazuh version in the Shuffle documentation, and test alert payload mapping against real examples. Plan for a period when both platforms receive alerts so you can compare outcomes before retiring the Splunk SOAR container and asset feeds.

Do Splunk SOAR .tgz playbook archives import directly into Shuffle?

No, they do not import directly. Splunk documents exporting and importing playbooks as .tgz archives inside Splunk SOAR, but Shuffle uses its own workflow format and app model. You can use the archives as the inventory and specification for each playbook, then rebuild the logic as Shuffle workflows. Custom Python functions must be rewritten as Shuffle apps using the app SDK or built from OpenAPI specifications in the App Creator. Verify each playbook's logic, decision branches and error handling after rebuilding it.

What happens to credentials saved in Splunk SOAR assets?

Saved credentials do not transfer automatically. Splunk SOAR assets must be recreated as Shuffle app authentications, and each service account or API key should be reissued or rotated under your secrets policy. Shuffle encrypts saved app credentials and API keys in OpenSearch with AES-256 using the SHUFFLE_ENCRYPTION_MODIFIER secret. Store that secret securely and back it up, because losing or changing it breaks all saved app authentications. Record who owns each credential before cutover.

How DeployOpen scopes and runs a Splunk SOAR to Shuffle migration

DeployOpen plans, implements, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside the client's own infrastructure, whether that is a cloud account, a data center or an air-gapped network. For a Splunk SOAR to Shuffle move, that means the Shuffle deployment, its OpenSearch data store, the Orborus runtime nodes, the secrets handling and the connection to Splunk or Wazuh as the alert source are all planned and built in your environment, with your team holding the access and the decisions. Before any work starts, the first written deliverable should inventory every playbook, custom function, app and asset, and record which of them run in production and which are dormant.

Engagements are fixed-scope. The scope, deliverables and timelines are agreed in writing before work starts, so the inventory, the playbooks to rebuild, the target deployment architecture, the acceptance tests and the cutover window are each named and owned. A quote follows from that written scope. DeployOpen does not publish a price list, so the cost depends on how many playbooks have Python custom functions to rewrite as Shuffle apps, how many app authentications must be recreated, and whether high availability is required. Ask for the quote to break out those components separately and to state which items are one-time work and which recur.

Ongoing support, upgrades and continuous testing are available as retainers, which fits teams that expect to keep adding playbooks after cutover. Before signing, confirm with the vendor and your own environment which Shuffle version and Docker tag your standard will pin, and who records the SHUFFLE_ENCRYPTION_MODIFIER value so saved credentials can be restored. Decide whether the retainer covers upgrades, backup restore tests and playbook changes, and make sure the written scope names the responsibilities of your staff and of DeployOpen for each. DeployOpen prepares systems, controls and evidence for compliance assessments, but independent auditors and certification bodies issue any audit reports or attestations.