Splunk SOAR inherited Phantom’s architecture and Splunk’s commercial instincts, which means it is metered in a way that penalises exactly the behaviour you want: automating more of the alert queue. Per-action or per-user pricing sitting alongside an already ingest-metered SIEM is why teams start pricing alternatives. StackStorm is the open, event-driven automation platform most often reached for, and it is important to be precise about what it is: a superb engine with no security opinions whatsoever.
That framing determines whether this migration is a good idea for you.
Decide what you are actually replacing
Splunk SOAR does two jobs. It orchestrates, calling APIs, making decisions, taking actions. And it presents, giving analysts an incident view, case metadata, artifacts, and a place to work.
StackStorm does the first job extremely well and the second not at all. So the first question is which job your team relies on. If your SOAR mostly runs unattended enrichment and containment triggered by SIEM alerts, with analysts working in a ticketing system or SIEM console anyway, StackStorm is a clean replacement. If your analysts open Splunk SOAR every morning and work the incident queue inside it, you need StackStorm plus a case platform, and the case platform is the bigger half of that project.
Answer this before scoping, because it roughly doubles the work if the answer is the second one.
Phantom’s Python heritage is your biggest advantage
Unusually among SOAR migrations, you are not starting from an opaque export. Phantom playbooks are Python: the visual editor generates code, and that code is readable, exportable, and an accurate specification of what the playbook does, including the parts the diagram hides.
Export the Python for every playbook in scope and read it. You will find the actual API calls, the actual conditional logic, the actual error handling, and, frequently, the undocumented workarounds someone added years ago. That is your migration specification, and it is far better than the diagram.
Custom code blocks inside playbooks often survive nearly intact as StackStorm Python actions, with the phantom. SDK calls swapped for direct API calls or pack actions. The structural translation, blocks and their connections becoming Orquesta tasks and transitions, is mechanical enough to be quick once you have done two or three.
The mapping
- Phantom playbooks → Orquesta workflows (YAML tasks with
nexttransitions). - Playbook blocks → workflow tasks, with filters and decisions becoming transition conditions.
- Custom code blocks → StackStorm Python actions.
- Apps and connectors → StackStorm packs (action metadata plus a Python runner).
- Assets and their credentials → pack configuration and StackStorm’s datastore or an external secrets manager.
- Containers and artifacts → workflow parameters, plus records in your case platform.
- Prompts → StackStorm inquiries, surfaced through ChatOps or your case tool.
- Scheduled playbooks → StackStorm timers.
- On-poll ingestion from the SIEM → a StackStorm sensor polling or receiving from the same source.
Sensors are where the architecture actually changes
Splunk SOAR ingests via app-specific on-poll routines, tightly coupled to the SIEM. StackStorm inverts this: sensors are long-running processes that watch something and emit triggers, and rules match triggers to actions or workflows.
Practically, this means the first thing you build is not a workflow at all. It is the sensor that receives your alerts, and the trigger schema that describes them. Get that schema right early and every subsequent workflow is easy; get it wrong and you will be reworking every workflow’s input handling later.
The pattern that works well is a webhook sensor receiving alerts pushed from the SIEM, with a normalised trigger payload containing the fields your workflows need (alert ID, severity, affected host, affected user, indicators). Normalise at the sensor, not in each workflow, exactly as you would enrich at ingest in a SIEM pipeline.
This inversion is also an improvement worth naming: because rules match triggers, one alert can fan out to several workflows, and adding a new automation later means adding a rule rather than editing a monolithic playbook.
Order of operations
- Decide whether you are replacing orchestration only, or orchestration plus the analyst workspace, and scope the case platform accordingly.
- Export playbook Python for everything in scope and rank by execution volume; retire the tail on purpose.
- Verify every integrated vendor has a documented API, independent of the Phantom app.
- Deploy StackStorm with capacity sized on peak alert rate, not average.
- Build the sensor and normalised trigger schema first, and validate it against real production alerts.
- Convert the highest-volume playbook, running it with actions stubbed to log-only.
- Compare outcomes against the live Splunk SOAR playbook until they agree over a meaningful sample.
- Enable real actions incrementally, lowest blast radius first, each with its own scoped credential.
- Wire inquiries into a response path analysts can actually reach out of hours, and test it out of hours.
- Cut over per playbook, disabling the Splunk SOAR original only after its replacement runs clean in production.
What you give up, stated plainly
No incident view. No artifact model. No case management. No security content out of the box. A much smaller library of security-vendor integrations. And no vendor to call when a pack breaks at 2am, because StackStorm’s commercial support landscape is thinner than its technical quality deserves.
Against that: no per-action meter, an engine that handles far more than security automation (many teams end up using the same StackStorm for infrastructure runbooks), a workflow definition format that lives in Git and reviews like code, and full control over an automation layer that is otherwise one of the stickiest components in a security stack.
Clearing the bar before you cut over
Every migrated workflow has run with stubbed actions and produced decisions matching the incumbent. The sensor has survived a peak alert burst without dropping triggers. Inquiries reach a human out of hours and have been tested doing so. Every action credential is newly minted and scoped. Failure paths, unreachable target system, API rate limit, malformed alert, have been deliberately exercised. And if analysts needed a workspace, the case platform is live and being used before Splunk SOAR goes away.
The short version
Splunk SOAR to StackStorm removes per-action metering and hands you an engine with no security opinions. The Phantom-to-Python heritage makes the logic translation unusually tractable; the sensor and trigger schema is the piece of architecture that decides whether the rest goes smoothly; and the analyst workspace is the thing StackStorm genuinely does not replace. Model the illustrative economics in the calculator above, count the case platform and the messaging infrastructure as part of the cost, and stub every action until the decisions match.