Splunk SOAR On-premises: upgrade, move to Splunk SOAR Cloud or replace

Splunk SOAR on-premises owners facing an upgrade or a cloud push can compare three paths. Moving to Splunk SOAR Cloud requires converting custom code to Python 3 first, and self-hosted Shuffle is often the better use of that effort.

Book a callTalk to us
On this page

Why Splunk SOAR on-premises owners are reviewing their path now

If you run Splunk SOAR (On-premises) and a minor version is approaching the end of its support window, or your organization is being pushed toward Splunk SOAR (Cloud), you have three paths: upgrade on-premises, move to Splunk SOAR (Cloud), or replace the platform with self-hosted Shuffle. The deciding factor is how much custom Python and playbook logic you must carry forward, because that logic drives the cost and effort of every path. Each Splunk SOAR minor version is supported for 24 months, so the window for a given version is fixed and known, and the date you need to plan against is the one printed in Splunk's support documentation for your version.

Moving to Splunk SOAR (Cloud) is not a simple lift. Splunk documents migrating administration settings, apps, playbooks and custom functions from Splunk SOAR (On-premises) to Splunk SOAR (Cloud), and it requires converting your custom code to Python 3 before the move. Start by inventorying every custom function, app and playbook, noting which ones already run on Python 3 and which depend on older interpreter behavior. Read the migration guide for Splunk SOAR (Cloud) to confirm the current prerequisites for your environment before you size that conversion work. The on-premises upgrade path keeps your playbooks in place but still requires a change window, a tested backup and validation of every app and asset connection. Ask Splunk or your partner to confirm the target version, the upgrade procedure and the support end date for your current minor version. The option you choose should match the amount of custom logic you intend to keep, not the platform you are most familiar with.

What each path requires from your environment

Whether you upgrade, move to Splunk SOAR (Cloud) or replace, the same inventory decides the effort. Each card below is a requirement the decision imposes on your environment, and most of them come down to what code, data and access you already have.

Supported version lifecycle

Each Splunk SOAR minor version is supported for 24 months, so the age of your current on-premises release sets the urgency of any decision. Record your exact version, the date it entered support, and the end-of-support date Splunk publishes for it. Ask Splunk to confirm the dates that apply to your release, since version-specific details change and should not be taken from this page alone.

Custom code and playbook inventory

Before choosing a path, list every custom playbook, custom function and app you run, along with its owner and the last date it executed. Export playbooks as .tgz archives so you hold a copy outside the appliance. Unused content can often be retired rather than migrated, which shrinks every later option.

Python 3 readiness

Moving to Splunk SOAR (Cloud) requires converting custom code to Python 3 first, so this is a gating item rather than a later task. Run your custom functions and app code under Python 3 and list anything that depends on Python 2 behavior. Treat this inventory as the most reliable estimate of the conversion effort in your environment.

Classic editor dependencies

Splunk documents that the classic playbook editor was deprecated in 2024. Identify which playbooks were built in the classic editor and which teams still edit them there. Those playbooks need a decision on whether they are rebuilt, kept as-is until the upgrade, or retired, because the editor you use today may not be the one you carry forward.

Alert sources and SIEM connections

Map every system that sends containers or alerts into Splunk SOAR, including the SIEM, ticketing and endpoint tools, and the direction and credentials of each connection. Whichever path you take, these connections are rebuilt or repointed, so the list defines the cutover scope. Confirm with Splunk how each connection is migrated to Splunk SOAR (Cloud).

Identity, access and data residency

Document who holds administrator and analyst roles, how they sign in, and where playbook data, asset credentials and case records are stored. A cloud path changes where that data lives and who operates the platform, which may conflict with residency rules. Migrating administration settings and apps to Splunk SOAR (Cloud) is documented by Splunk, but you should confirm with Splunk which credentials and records transfer and which must be re-entered.

What a move to Splunk SOAR Cloud involves before cutover

The first step in a move to Splunk SOAR (Cloud) is an inventory, because Splunk's migration documentation covers administration settings, apps, playbooks and custom functions, and custom code has to be converted to Python 3 before it can move. Start by listing every custom function, every playbook that calls one, and the Python version each depends on. Anything that relies on Python 2 behavior, local file paths or on-premises-only libraries needs a rewrite plan. The custom code conversion is the step most likely to set the schedule, so size it from the inventory rather than from the number of playbooks alone. Keep the export of each playbook as a .tgz archive so you have a rollback copy of the on-premises version.

The conversion then needs testing against the cloud environment, not only against your existing on-premises instance. Run converted functions and playbooks in a non-production cloud tenant, check each app version the cloud service offers against the apps you use, and confirm that every playbook still reaches its target system from Splunk's hosting. Next, remap assets and app configurations. Credentials, asset settings and app configurations do not carry over as a simple copy, so record each asset, its owner and the system it connects to, then recreate and test each one in the cloud. Plan a parallel run where alerts reach both environments before you cut over.

Because Splunk SOAR (Cloud) is hosted and managed by Splunk, the move also changes where data sits and who operates the platform. Before you commit, ask Splunk in writing which regions host your tenant, where case data, playbook run logs and stored credentials are kept, which subprocessors and support staff can access them, and how backups and deletion work. Compare those answers with your data residency, sovereignty and records retention rules, and with any contractual limits on sending security telemetry outside your boundary. If the answers do not meet those rules, the cloud path may not be viable, and the conversion work above would be wasted effort.

Upgrade, Splunk SOAR Cloud or self-hosted Shuffle compared

This table compares staying on Splunk SOAR (On-premises) with an upgrade, moving to Splunk SOAR (Cloud), and replacing it with self-hosted Shuffle. Read each row against your own playbook inventory, hosting rules and licence renewal date. The main takeaway is that the two Splunk paths keep your playbook logic in the Splunk model, while Shuffle is the only option that changes the platform you run.

FactorStay on Splunk SOAR (On-premises) and upgradeMove to Splunk SOAR (Cloud)Replace with self-hosted Shuffle
What must be converted or rewrittenLittle conversion for the platform itself, but you must confirm each custom app and function still runs on the target versionCustom code must be converted to Python 3 before migration, and administration settings, apps, playbooks and custom functions are migratedPlaybooks are exported as .tgz archives and rebuilt as Shuffle workflows, with Python custom functions rewritten as Shuffle apps
Where the workload runsYour own servers or data center under your operations teamHosted and managed by Splunk as a SaaS solutionYour own infrastructure, using Docker or Kubernetes
Licensing, as suppliedSplunk licence terms apply to the on-premises product; confirm version support dates with SplunkSplunk SaaS subscription terms apply; confirm contract scope with SplunkShuffle backend is AGPLv3, workflows, documentation, apps and app specifications are MIT, and paid tiers are priced on app runs
Infrastructure needsExisting Splunk SOAR servers and their maintenance, plus the upgrade windowNo servers to run, but you rely on Splunk's hosting and its migration planMinimum of 4 GB RAM for the install, OpenSearch as the database, and extra nodes for high availability
Operational ownershipYour team patches, upgrades and backs up the platformSplunk operates the platform, you manage content and integrationsYour team owns installation, upgrades, backups and the OpenSearch cluster, or a retainer covers them
Main trade-offsLowest change now, but the upgrade cycle and the Python and app constraints remainLess infrastructure work, but custom code still needs Python 3 conversion and data stays in Splunk's cloudRemoves the Splunk dependency and seat model, but needs playbook rewrite, new analyst habits and an OpenSearch skill set
Shuffle hosted optionNot applicableNot applicableShuffle also offers a hosted cloud service at shuffler.io as an alternative to self-hosting

Which path fits which situation

A team with a small set of playbooks and little custom Python has the least to lose from moving. The inventory is short enough to rebuild by hand, and most playbooks can be recreated as Shuffle workflows that call apps for the tools already in use. The decision then turns on whether the SOC still wants to operate Splunk SOAR at all.

  • Playbook count and triggers: Count each exported .tgz archive and note which ones fire on Splunk events, scheduled tasks or manual runs.
  • Custom functions: A handful of short functions is a small rewrite, and each one maps to a Shuffle app step or a workflow branch.
  • App footprint: List the Splunk SOAR apps in use. Shuffle's premade apps and App Creator may cover them, and any gaps become the main build work.
  • Upgrade effort: For this profile, rebuilding in Shuffle can be the smaller effort compared with an on-premises upgrade followed by a conversion. Confirm this with a dry run on two or three representative playbooks.

Check whether each playbook still matches a live response process before rebuilding it, because a short list can hide old logic that nobody uses.

How to deploy self-hosted Shuffle under your own controls

This sequence takes a team from the decision to replace Splunk SOAR to a Shuffle deployment that runs inside its own infrastructure, with the encryption key, single sign-on and migrated playbooks in place before production use.

  1. Size the host and agree production sizing

    Start from the install guide's minimum of 4 GB of RAM, then agree production sizing in writing with the vendor or your implementation partner based on expected workflow volume, OpenSearch storage growth and the number of Orborus nodes. Your platform team provisions the hosts in your own cloud account, data center or air-gapped network, and records the CPU, memory and disk figures in the design document. The step is complete when the sizing is signed off and the hosts are reachable on the internal network only. Ask for the sizing assumptions in any quote so you can test them against your own alert volume.

  2. Choose Docker Compose or Kubernetes

    Select the deployment architecture before installing anything. Shuffle documents a single server with Docker Compose, distributed Docker Swarm, a hybrid model with a local Orborus, and Kubernetes with Helm charts. The install guide states that the default Docker Compose setup is not a scalable build without changes, so a single Compose host suits a pilot, while production high availability usually points to Kubernetes or a Swarm design. Your architects make the decision and document the choice with the reasons. The step is done when the target architecture and its image tag policy are recorded, with the latest Docker tag for stable releases and the nightly tag reserved for experimental work.

  3. Deploy OpenSearch as the database

    Install OpenSearch as the document database that Shuffle uses for workflows, executions and saved app data. Elasticsearch also works, according to the install guide, but confirm which one your team will support over the life of the platform. Platform engineers deploy the OpenSearch nodes with their own storage classes and backup tooling, then connect the Shuffle backend to them. The step is complete when the backend starts cleanly against the cluster, the index health is green in your monitoring, and a test workflow saves and reloads its execution history. Confirm with your own DBA or platform team how snapshots will be taken and tested.

  4. Plan high availability for the platform

    Build the high availability layout the configuration docs describe: an OpenSearch cluster rather than a single node, the backend and frontend scaled across all servers, optional Memcached for a shared cache, and NFS for shared files when several backends run. Add more than one Orborus node so that workflows keep running if one fails. Your platform team configures the cluster and load balancing, then runs a controlled failure of one backend and one Orborus node. The step is done when a workflow completes during the failure test and the team has written a runbook for node replacement. Confirm NFS performance and availability with your storage team before relying on it.

  5. Store the encryption modifier in a secrets manager

    Set SHUFFLE_ENCRYPTION_MODIFIER before any app credentials are saved. Shuffle uses it to encrypt saved app credentials and API keys in OpenSearch with AES-256, and the configuration docs warn that losing or changing it breaks all saved app authentications. Store the value in your approved secrets manager, restrict read access to the platform owners, and keep an encrypted offline backup under your documented key custody procedure. The step is done when the value is injected from the secrets manager at deployment, a restore test has recovered the key from backup, and the change process requires a full re-authentication plan before any edit. Ask the vendor for a documented rotation procedure before you attempt one.

  6. Configure single sign-on with OpenID Connect

    Connect Shuffle to your identity provider using OpenID Connect, which Shuffle added in version 1.0.0 and which works on-premises and in the cloud. The extensions docs describe per-tenant SSO enforcement, so decide whether local accounts are disabled for each tenant and document the break-glass procedure for administrators. Since SAML is being deprecated on Shuffle Cloud in favor of OpenID Connect, avoid designing new integrations around SAML. The identity team registers the client, your security team tests role mapping, and the step is complete when an analyst and an administrator can sign in through the identity provider and a locked-out test account is blocked as intended.

  7. Migrate playbooks and rewrite custom functions as apps

    Export your Splunk SOAR playbooks as .tgz archives, inventory each Python custom function, and decide which functions become Shuffle apps. Shuffle builds apps from OpenAPI specifications in the App Creator or from Python with the Shuffle app SDK, and each app runs as a versioned Docker container. Rebuild the asset and credential configuration as Shuffle app authentications, because saved credentials do not carry over automatically, and keep the Splunk or other SIEM as the alert source. Analysts and the automation team test each migrated workflow against a replayed alert set in a non-production tenant. The step is complete when every production playbook has a tested Shuffle equivalent, the outputs match the Splunk SOAR results, and each app version is recorded in your change system.

  8. Validate and cut over production

    Run the old and new automation side by side for an agreed period, comparing case outputs, actions and failure handling. Confirm that the backup plan covers OpenSearch snapshots, app definitions and the encryption modifier, and that a restore has been tested in a separate environment. Obtain sign-off from the SOC lead, platform owner and compliance function, and keep evidence of each test for your assessor. Switch the alert routing once the comparison is accepted, then retire Splunk SOAR according to your contract terms. The step is done when production workflows run on Shuffle, the rollback path is documented, and the evidence pack is filed. DeployOpen can prepare these controls and evidence, but independent auditors and certification bodies issue any formal attestation.

Evidence that proves the migration is controlled

Whichever path you choose, the same few artifacts show that the move was planned, tested and reversible. Each card below is one piece of that record, and together they let a CISO, auditor or SOC lead trace every automation from its original Splunk SOAR (On-premises) definition to its final state. DeployOpen prepares these artifacts, but independent auditors issue any audit opinion, so confirm the exact evidence list with your assessor before work starts.

Playbook and custom function inventory

A complete list of every playbook, custom function, app and asset in Splunk SOAR (On-premises), with a named owner, the business purpose and the alert sources each one depends on. Build it from the platform itself, not from memory, because playbooks that were edited in place often differ from what the team remembers. Assessors use this inventory to confirm that nothing was dropped silently during an upgrade or move. Record which items are retired, which are converted to Python 3 for Splunk SOAR (Cloud), and which are rewritten.

Pre-change export archives

Exports of every playbook taken before any upgrade, conversion or platform move, stored with checksums and a retention date outside the SOAR platform. Splunk documents exporting playbooks as .tgz archives, so keep those files alongside a record of who ran the export and when. These archives are your rollback path if a converted automation fails in production. Store them under the same access controls as the source system.

Test results for converted automations

For each playbook converted to Python 3 or rewritten as a Shuffle workflow, keep the test plan, the test inputs, the expected outputs and the actual results. Compare outcomes against the original on the same sample alerts, including failure paths and approval steps. Note any difference in action results, timing or case updates, and who accepted it. Without this record, an auditor has no way to tell a faithful conversion from an untested one.

Change records for each platform move

A change ticket for each version upgrade, cloud migration or replacement, with the approver, the rollback decision point and the production cutover window. Splunk documents that Splunk SOAR (On-premises) administration settings, apps, playbooks and custom functions move to Splunk SOAR (Cloud), so each of those transfers needs its own entry. Link the change to the test results and exports above so the trail is continuous. Confirm with your change board how emergency changes are recorded.

Secrets handling and key custody record

A register of every credential, API key and app authentication that the automations use, showing where each is stored and who can read it. For self-hosted Shuffle, document the custody of the encryption secret that protects saved app credentials, since its documentation warns that losing or changing that secret breaks all saved authentications. Record how the secret is backed up, who holds it, and how rotation is tested before use. Keep a separate note for every credential that must be reissued during a move.

Access and SSO configuration evidence

Screenshots or exported configuration showing who holds administrator, analyst and read-only roles on the automation platform, and how sign-in is federated to your identity provider. Shuffle supports SAML single sign-on and OpenID Connect with per-tenant enforcement, so record which method is active and whether it is enforced for each tenant. Compare these settings with the access list at the time of the change. Stale administrator accounts are a common finding, so include a review date.

Questions buyers ask before moving off Splunk SOAR on-premises

How much does it cost to move off Splunk SOAR on-premises?

No single figure applies, because the cost depends on which path you take and on your own environment. The main components are Splunk licensing (which is seat-based for the on-premises product and changes under a cloud subscription), the servers or cloud capacity for the replacement, OpenSearch storage for Shuffle's document database, the effort to rewrite Python custom functions and playbooks, upgrade and support work, and any partner fees. Licensing and storage recur, while the rewrite and migration work is largely one-time. Ask any quote to itemize each component, state which systems are in scope, and show the assumptions on action volume and data retention. Pricing follows from a written scope, and DeployOpen does not publish a price list.

How long does a Splunk SOAR migration take?

The duration is set by the number of playbooks, custom functions and apps, how many of them depend on Python 2 code, the number of asset configurations to remap, and how many environments (development, test, production) must be validated. Splunk's migration documentation makes clear that custom code must be converted to Python 3 before a move to Splunk SOAR (Cloud), so that conversion is often the longest step. Shuffle migrations add app creation or SDK work and a testing phase against live alert sources. Ask for a timeline that lists these items separately and names the decision points where the scope could change.

What does the internal team need to provide during the work?

Your team needs to supply access to the current Splunk SOAR instance, a list of active playbooks and their owners, documented asset credentials, and named people who can approve changes to detection and response logic. Engineers familiar with the existing Python playbooks and with the SIEM feeding them will shorten the discovery phase. Security operations staff should define which cases must keep working during cutover. Plan for time from these people during testing, since they are the only reliable source for judging whether a rewritten workflow behaves like the original.

Can our in-house team move Splunk SOAR playbooks without a partner?

Yes, an experienced in-house team can do the work, and the vendor documentation and open-source projects provide the needed references. Teams without recent experience in Docker, OpenSearch administration, OpenAPI-based app development or security testing of automation often find the scope larger than expected. A partner can be used for the whole move, for specific parts such as app creation and hardening, or for independent review before cutover. Whichever you choose, agree on ownership of documentation, runbooks and backups in writing.

What happens to our playbooks and custom Python on each path?

On Splunk SOAR (Cloud), Splunk documents that administration settings, apps, playbooks and custom functions can be migrated, but custom code must first be converted to Python 3. Playbooks can be exported as .tgz archives from the on-premises product, which also supports the reimport path. On Shuffle, playbooks are rebuilt as workflows, and custom Python logic is rewritten as Shuffle apps, either built from OpenAPI specifications in the App Creator or written with the Shuffle app SDK, then run as versioned Docker containers. Asset configurations must be recreated as Shuffle app authentications, and the SHUFFLE_ENCRYPTION_MODIFIER value must be stored securely because losing it breaks all saved credentials.

Does Shuffle Cloud at shuffler.io change the data residency answer?

Yes, it changes where workflow execution and stored data sit, so it only fits if your residency rules allow that hosting. Shuffle offers a hosted service at shuffler.io as an alternative to self-hosting, and its architecture includes a hybrid option where Shuffle Cloud is paired with a local Orborus that needs no inbound firewall ports. In that hybrid model, the runtime that starts app containers can stay in your network, but you must confirm with Shuffle exactly which components and data stay local. For regulated data, the self-hosted deployment remains the simpler way to show where data resides.

What should a fixed-scope quote for this move include?

A fixed-scope quote should list the systems in scope, the playbooks, custom functions and apps to be migrated or rebuilt, the target platform and its deployment architecture, and the environments to be built. It should state the deliverables, including documentation, backups, runbooks and test evidence, and the acceptance criteria for each playbook. Ask which items are excluded, such as SIEM changes, licenses, cloud accounts or hardware, and how changes after sign-off are priced. Confirm the handover plan, the support period, and whether an optional retainer covers upgrades. DeployOpen issues quotes only from written scope, so the more specific the scope, the more precise the quote.

How DeployOpen plans a SOAR move under your constraints

DeployOpen starts with the written scope for your Splunk SOAR On-premises environment, then plans the upgrade, cloud move or replacement around your constraints. We implement, harden, document and support self-hosted open-source platforms inside your own infrastructure, and most engagements are fixed-scope.

How we scope

  • Inventory every playbook, custom function, app, asset and scheduled container tied to your on-premises instance before choosing a path.
  • Record which playbooks rely on Python 2 code, since Splunk's cloud migration requires conversion to Python 3 first.
  • Agree the written scope, deliverables and timeline with you before any build work starts.

How we build

  • Build a proof of concept of your highest-value playbooks on the chosen target, whether an upgraded instance, Splunk SOAR Cloud or self-hosted Shuffle.
  • Rewrite or port custom code, then test each playbook against representative alert data in a non-production environment.
  • Deploy Shuffle inside your cloud account, data center or air-gapped network, with SSO and encrypted credential handling configured.

How we hand over

  • Provide documentation covering architecture, configuration, the secret used for credential encryption, and backup procedures.
  • Deliver a playbook mapping record showing each source workflow, its replacement and any behavior that changed.
  • Walk your operations and security teams through runbooks for upgrades, failover and incident handling before sign-off.

How we support

  • Offer ongoing support, upgrades and continuous testing as a retainer after handover, scoped separately from the build.
  • Plan upgrades of the platform and its components on a schedule you approve, with testing before each change reaches production.
  • Confirm with your team which support terms, response expectations and security test cadence you need before the scope is signed.

Sources and further reading

Related

Talk to our team.

Tell us what you're working on, whether it's a deployment, an audit, a security test or a cyber range. You'll speak with an engineer who can help you scope it.

  • 30-minute call: free, with no obligation.
  • NDA on request: we can sign before you share details.
  • Clear next steps: a scope and plan after the call.
Book a callhello@deployopen.com