Leaving Splunk SOAR as it becomes part of Enterprise Security

The packaging changed before the product did

Splunk's product page now says Splunk SOAR is a native capability within Splunk Enterprise Security, with a note that a Splunk SOAR subscription is required. The same page claims 300+ third-party tools and 2,800+ automated actions (Splunk SOAR product page) (read 2026-11-03, vendor claim). Read that as two facts. The orchestration surface moves inside ES. The licence stays separate.

For a buyer that matters in both directions. If you stay, you pay for ES and for SOAR. If you leave, do not assume that dropping SOAR leaves ES untouched, because the packaging puts the two together. Check which ES workflows in your SOC depend on SOAR actions before you cut anything.

The product page footer reads "Splunk by Cisco". The closing date of 2024-03-18 comes from D3, a competitor, and we did not read it on a Cisco page (Splunk SOAR product page) (read 2026-11-03). We found no end-of-sale or end-of-life notice for Splunk SOAR. D3 says none has been announced, and Blink says the roadmap for a standalone product is unclear without a source. Both are competitor statements (D3 Splunk SOAR guide) (read 2026-11-03, vendor claim). Absence of a notice is not a roadmap. Ask your account team for the support dates in writing.

Playbooks are Python, and the editor changed under them

Release 6.4.0 removed the classic visual editor. Existing classic playbooks still run, but you must convert them to the modern mode to edit them visually. Playbooks created in 6.4.0 and later are not backward compatible with earlier versions (Splunk SOAR 6.4.0 release notes) (read 2026-11-03). The editor generates Python, and its linter warns about changes between Python 3.9 and 3.13.

Python 3.9 matters now. The on-prem 8.7.0 release, generally available 2026-09-02, drops support for Python 3.9 (Splunk SOAR on-premises 8.7.0 release notes) (read 2026-11-03, vendor claim). If you have custom functions on 3.9, an upgrade forces rework whether or not you migrate. That rework is the first thing to price, because it is the cost of staying.

The export you have is a Splunk-to-Splunk export

The documented export downloads a playbook as a JSON file, saved at least once, and takes the latest saved version. Import takes a .tgz archive, creates a new playbook, requires a source control repository to be selected, and works only into the same or a higher Splunk SOAR version and the same editor type (Splunk SOAR Cloud export and import) (read 2026-11-03). The page does not explain how the JSON export relates to the .tgz archive. That is a gap worth asking about.

The documented migration is on-prem to Cloud only. You convert playbooks and custom functions to Python 3 first, optionally set up a Git-compatible repository, test in Cloud, and move standalone pip installs into application wheels modules (Splunk migration to Cloud) (read 2026-11-03). We found no export to another vendor.

Three destinations publish something you can check

Microsoft Sentinel. Microsoft publishes a concept map from Splunk SOAR to automation rules and Logic Apps, updated 2026-08-12. It lists Splunk containers and cases as the incident and case objects, and maps prompts to a Send approval email step. The page names no converter tool (Microsoft migration guide) (read 2026-11-03). It is a map, not a tool.

Blink. Blink claims import tooling that maps playbooks, custom functions and Splunkbase apps, in a four-week plan. No technical page backs the mapping accuracy (Blink migration page) (read 2026-11-03, vendor claim).

Tines. A Tines library story moves case records from Splunk SOAR into Tines cases with annotations and attachments. It does not move playbook logic (Tines library story) (read 2026-11-03). That is useful for history, and it shows where the line sits: cases move, logic is rebuilt.

D3 names Splunk SOAR among six sources with published porting coverage, and its guide says industry migrations often run 6 to 12 months. That duration is a seller's figure with no method behind it (D3 Splunk SOAR guide) (read 2026-11-03, vendor claim). Use it as an upper bound to test against, not as a plan.

The agents build automation, they do not decide cases

If part of the pull to stay is Splunk's new AI, read the release notes closely. Cloud release 8.6.0 added an Automation Builder agent that understands and builds playbooks, and 8.7.0 on 2026-09-02 added a Connector Builder Agent. Both are Cloud only and need Splunk Enterprise Security 8.6 or later (Splunk SOAR Cloud release notes) (read 2026-11-03). They help you author. The documentation does not describe an agent that triages cases on its own. That matters if "after SOAR" for you means agents taking alerts, because the agents here sit at build time, not run time.

Order of work for a Splunk SOAR exit

First, decide the end state. A Splunk shop that keeps ES has a different problem from a team that is also leaving Splunk. If you keep ES, a hybrid is plausible: keep Splunk SOAR for the playbooks tied to ES and move the rest. If you leave both, the Sentinel and other maps matter more.

Second, freeze Python upgrades you do not need. Every function you port to 3.13 for Splunk is work you would redo in another editor.

Third, move cases last. Case history is the one thing a library story can carry, and auditors may ask for it long after the playbooks are gone.

Checklist for the Splunk SOAR exit

• Get the ES to SOAR dependency list: which ES actions call SOAR.
• Get licence terms for the separate SOAR subscription and its end date in writing.
• List playbooks by editor type (classic or modern) and Python version.
• Price the Python 3.9 rework as the cost of staying.
• Export a sample playbook as JSON and ask Splunk how it relates to the .tgz import.
• Choose keep, translate or retire for each playbook.
• Ask each destination vendor for a written list of what does not port.
• Plan a case history export and set a retention rule for it.
• Set a parallel run that ends before your support or licence date.