Which fits your team: Splunk SOAR or self-hosted Tracecat for security automation
Splunk SOAR fits best when your SOC already runs on Splunk, your playbooks and apps are stable, and you can accept a managed or hosted model. Splunk SOAR (Cloud) is hosted and managed by Splunk, while Splunk SOAR (On-premises) runs inside your own network. Choose it when analysts depend on its existing case handling and app ecosystem, and when retaining Python playbooks is worth more to you than changing platforms. Teams with long-lived playbooks can export them as .tgz archives and keep that investment while they decide what comes next, as described in the Splunk export and import guide.
Self-hosted Tracecat fits when a residency or sovereignty rule requires automation to run in your own infrastructure, or when you want custom actions versioned in Git and reviewed like application code. Its documented deployments include Docker Compose on a single host, AWS ECS Fargate through Terraform, Kubernetes through a Helm chart, and an air-gapped Kubernetes option. Its use of Temporal for durable workflow execution matters when long-running response steps must survive restarts. Confirm which Git sync features sit in the open-source edition, because the repository lists Git version control integration as an Enterprise feature. The Tracecat documentation sets out the current boundaries.
The decision turns on three things. First, playbook volume: a small set of stable playbooks favors a migration only if the rewrite effort is justified, while a large estate makes the rewrite the main cost. Second, identity and tenancy: SSO and multi-tenant workspaces are Enterprise features in Tracecat, so ask for the Enterprise Edition license scope in writing before you plan around them. Third, in-house engineering capacity: a self-hosted Tracecat stack includes Temporal, PostgreSQL, an S3-compatible object store and a sandbox layer, and someone must patch, back up and upgrade all of them. Ask Splunk and Tracecat for their licensing terms and support boundaries in writing.
Which option fits each buyer scenario
This table maps six common buyer situations to the option that usually fits better and the condition under which that holds. Read each row against your own licensing, hosting and identity requirements, because the answer changes if a requirement in your environment points the other way.
| Scenario | Better fit | Why |
|---|---|---|
| Staying on Splunk SOAR Cloud with no hosting change | Splunk SOAR (Cloud) | Splunk hosts and manages the platform, so it fits if your data handling terms already cover the SIEM and SOAR data you send and your team has no plans to run the platform itself. |
| On-premises Splunk SOAR facing an upgrade | Tracecat, if you are willing to rebuild playbooks | Upgrading or moving to Splunk SOAR (Cloud) requires converting custom code to Python 3 first, so Tracecat fits when rewriting workflows and custom actions is already on the roadmap and you can plan that work as a migration. |
| Community License limits reached | Tracecat open-source edition | Tracecat's AGPL-3.0 core has no per-action limit in its license, so it fits teams that can run Docker Compose or Kubernetes themselves. Confirm current feature and limit details in the Tracecat documentation before deciding. |
| Data must stay in your own infrastructure | Tracecat, self-hosted | Tracecat supports Docker Compose on a single host, AWS ECS Fargate, Kubernetes via Helm and an air-gapped Kubernetes deployment, so it fits when your hosting model must stay inside your network. Confirm the air-gapped setup against your own architecture. |
| SSO or multi-tenant workspaces required | Tracecat Enterprise Edition, or Splunk SOAR if its features already meet your need | Tracecat documents SSO and multi-tenant workspace management as enterprise features under a paid license, so this holds only if you accept that license cost. Confirm the feature set and terms with Tracecat before relying on it. |
| Python engineers who want Git-based change control | Tracecat, with custom actions synced from Git | Tracecat syncs custom actions from Git, but Git version control integration is listed as an Enterprise feature, so the advantage holds on the open-source edition only if your team accepts managing sync manually. Confirm which Git workflow your team needs before deciding. |
How Tracecat deploys compared with Splunk SOAR hosting models
Docker Compose on a single host is the simplest self-hosted Tracecat option. It suits pilots, small teams and proofs of concept where all components, including the Python API, the Next.js frontend, Temporal, PostgreSQL and the S3-compatible object store, run on one machine that your organization controls. Data stays on that host and in your storage, so the data residency question is answered by where that host sits.
- Operations: your team patches the host, the container images, the database backups and the object store, and owns restarts after failures.
- Availability: a single host is a single point of failure, so recovery depends on your backup and restore process.
- Scaling: capacity is bounded by one machine, and growing beyond it means moving to a cluster-based environment.
- Comparison: Splunk SOAR (On-premises) also runs on hosts you manage, but its vendor-supported installation paths differ from Tracecat's Compose setup.
- Sandboxing: confirm with the vendor how nsjail sandboxing behaves on your host operating system before you rely on it for custom actions.
Before choosing this option, confirm backup and restore procedures for PostgreSQL and object storage against the Tracecat documentation.
The AWS ECS Fargate deployment, provisioned through Terraform, runs Tracecat in your own AWS account rather than on hardware you rack. It suits teams that already standardize on AWS, want infrastructure defined as code and need Tracecat's data inside a region and account they govern. Your cloud account owns the data, the keys and the network boundary.
- Operations: your team maintains the Terraform state, the AWS networking, IAM roles, logging and the upgrade path for the module.
- Data control: storage, databases and encryption keys sit in your account, which helps with residency and access review.
- Recurring cost: AWS compute, database, storage and network charges recur, and they scale with usage.
- Splunk comparison: Splunk SOAR (Cloud) removes this operating layer because Splunk hosts and manages the service.
- Confirm: ask the vendor which Terraform module version matches your target Tracecat release and how major upgrades are handled.
Review the deployment guide in the Tracecat documentation and map its resources to your existing AWS controls before provisioning.
The Kubernetes deployment, using the Helm chart, fits organizations that already run clusters and want Tracecat managed alongside other services. It separates the application from the infrastructure, so it can run on your private cloud, a managed Kubernetes service or on-premises clusters. The data location is whatever your cluster and storage classes provide.
- Operations: your platform team owns the cluster, ingress, certificates, persistent volumes, secrets and Helm release lifecycle.
- Availability and scaling: replicas and node pools are configured by your team, so design choices affect resilience directly.
- Skills: expect to need staff who can operate Kubernetes, Helm and the database and object store behind them.
- Splunk comparison: Splunk SOAR (On-premises) is installed on a host you manage, so this option shifts more of the platform work into your cluster operations.
- Confirm: check which Helm chart version pairs with your Kubernetes version and which dependencies the chart installs or expects you to supply.
Start from the Helm instructions in the Tracecat documentation and agree on ownership of each cluster component before go-live.
The air-gapped Kubernetes deployment runs with no runtime internet access. It suits classified, critical infrastructure or highly restricted networks where automation must keep working without outbound connections. Playbook execution, integrations and case data stay inside the isolated network, and the organization decides every route that data can take.
- Image and dependency transfer: your team must move container images, chart artifacts and updates through an approved process into the enclosed network.
- Integrations: connectors that call external services need internal endpoints or approved proxies, so review each action's reachability before you commit.
- Operations: patching, vulnerability review and backups all depend on internal mirrors and processes you run yourself.
- Splunk comparison: Splunk SOAR (Cloud) cannot meet this requirement because it is hosted by Splunk, while Splunk SOAR (On-premises) can be operated in restricted networks subject to its own installation and licensing terms.
- Confirm: ask the vendor which air-gapped artifacts are published, how they are verified and how updates are delivered.
Before committing, read the air-gapped section of the Tracecat documentation and test an offline install in a non-production enclave.
Where your data sits and who controls it under each option
These four cards separate where your security automation data is stored, who authenticates users, who produces compliance evidence, and which code you can use without a commercial agreement. Each one points to a decision you can verify before a migration begins.
Data location and residency
Splunk SOAR (Cloud) is a SaaS platform hosted and managed by Splunk, so case records, playbook run data and asset details sit in Splunk's hosted environment. Tracecat runs where you deploy it: on a single Docker Compose host, on AWS ECS Fargate through Terraform, on Kubernetes through a Helm chart, or on an air-gapped Kubernetes cluster with no runtime internet access. Its data lives in PostgreSQL and an S3-compatible object store that your team operates. Confirm the storage region, backup location and which logs leave your network before you sign.
Identity and single sign-on
The Tracecat documentation describes authentication and single sign-on as Enterprise features, so connecting your identity provider requires a paid Enterprise Edition license. Multi-tenant workspace management is also an Enterprise feature, which matters if different business units need separate case queues. Ask Tracecat which login and access controls the open-source build includes, and whether your identity provider's group mapping can assign analyst and administrator roles. Compare that with the identity options in the Splunk SOAR deployment mode you use, and confirm them in writing with Splunk.
Audit and compliance evidence
DeployOpen can prepare controls, configuration baselines and evidence for a compliance assessment in either environment. It does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make that determination. Ask each vendor for its own evidence: access logs, change history for playbooks and custom actions, and retention settings. For Tracecat, custom actions synced from Git give a reviewable change trail, but Git version control integration is an Enterprise feature, so confirm which parts your workflow needs.
Licensing and enterprise code
Tracecat is licensed under AGPL-3.0, which allows you to run, modify and self-host the open-source code. The license also requires you to publish source changes if you offer a modified version to users over a network, so check how your team plans to deploy internal changes. Code in packages/tracecat-ee and features behind enterprise gates fall under a separate paid Enterprise Edition license. Have legal counsel review both licenses before a gated feature becomes part of your process. Splunk SOAR is a commercial product with its own community and paid license terms.
What AGPL-3.0 and the Enterprise Edition change for your team
Tracecat's core is licensed under AGPL-3.0, but code in packages/tracecat-ee and the enterprise feature gates falls under a separate paid Enterprise Edition license. Before you commit, map every capability your team needs to one side of that boundary. The Tracecat repository names multi-tenant workspace management and Git version control integration as Enterprise features, and the documentation describes authentication and single sign-on the same way. Custom actions synced from Git appear among the core workflow features in the documentation, so confirm in writing that your planned Git workflow does not depend on the Git version control integration. Pin the version you evaluate against. Tracecat 1.2.0 was released on October 16, 2026, so check the release notes for that version and any later release before you finalize the feature list.
AGPL-3.0 adds obligations beyond ordinary open-source use. If you modify Tracecat and let users interact with the modified version over a network, the license's network-use provision requires you to offer those users the corresponding source code of your modifications. Internal, unmodified use carries a much lighter obligation. A modified instance that a partner, a customer portal or a managed service provider reaches over the network can trigger the requirement. Whether custom actions, workflow content or connector code count as modifications of the covered work is a legal question, not a technical one. Ask counsel to review your intended deployment model, your hosting arrangements and any plans to embed Tracecat in a product, and record the decision before go-live.
The Splunk SOAR Community License limits are quantitative: 100 licensed actions per day, 1 tenant and 5 open cases. Commercial Splunk SOAR licensing is seat-based, so cost grows with the number of people who use the platform. Tracecat's AGPL-3.0 terms do not set a seat count or an action cap for the open-source core, so a team that outgrows the Community limits can move to self-hosted Tracecat without changing its license model. The cost moves elsewhere: infrastructure for PostgreSQL, Temporal and an S3-compatible object store, staff to operate them, and any Enterprise Edition fees if you need multi-tenancy or SSO. Request a written quote that lists exactly which Enterprise features are included and whether the license covers your hosting model.
Cost components on each side and what drives them
Splunk SOAR and Tracecat cost different things to own. One side is mostly a license and vendor relationship, the other mostly infrastructure, engineering and operations that you hold yourself. Use the cards below to build a like-for-like comparison and to know what to put in a written quote.
Licenses and subscriptions
Splunk SOAR is priced through seats or a cloud subscription, so this line recurs for as long as you run it. Ask Splunk for the written terms for your chosen model, including what counts toward the limit and what happens at renewal. Tracecat's open-source edition has no license fee, but the AGPL-3.0 terms apply to you. If you need SSO or multi-tenant workspaces, price a Tracecat Enterprise license separately and ask for it in writing, since those features sit behind that license.
Servers and cloud resources
A self-hosted Tracecat deployment runs PostgreSQL, Temporal, an S3-compatible object store and worker processes. These are recurring compute, storage and backup costs in your own cloud account or data center. Sizing depends on alert volume, workflow concurrency and retention, so ask your team or DeployOpen to size each component against your expected load. Keep Temporal and PostgreSQL highly available in mind, because a single-host Docker Compose setup is not a production topology for most teams.
Playbook and custom action rewrites
Splunk SOAR Python playbooks and custom functions must be re-expressed as Tracecat workflows and custom actions synced from Git. This is mostly one-time engineering effort, but it recurs whenever a playbook changes. Count the playbooks, custom functions and assets you plan to move, then separate the simple ones from those that rely on Splunk-specific container or artifact logic. Ask any implementation partner to price these as a fixed scope with named deliverables.
Platform upgrades and maintenance
Splunk SOAR upgrades are handled through the vendor's release process and its support windows, which keeps routine version work mostly with Splunk. Tracecat upgrades are your responsibility when self-hosted, covering the Python backend, Next.js frontend, Temporal, PostgreSQL and the object store. Plan for recurring time to test each release against your custom actions before rollout. Ask whether a retainer covers upgrades and continuous testing, and what it excludes.
Support and monitoring
Splunk support is included in a commercial agreement, and its level should be confirmed in writing. With Tracecat, you pay for support through a vendor agreement, an internal platform team or an external provider, and you own monitoring for workers, Temporal queues and database health. Ask what response times and escalation paths are contracted, who gets paged for a failed workflow run, and how logs and metrics are retained for your audit needs.
How a move from Splunk SOAR to Tracecat usually unfolds
The sequence turns Splunk SOAR playbooks, apps, assets and cases into Tracecat workflows, custom actions and cases, with each stage checked against the previous one before the old platform is switched off. Effort depends mostly on how much custom Python the existing playbooks contain.
Inventory playbooks, apps, assets and open cases
Start by listing every active playbook, the Splunk SOAR apps they call, the assets and credentials bound to each app, and the open cases that analysts still work. Mark which playbooks are scheduled, which are triggered by container events, and which depend on custom functions. The output is a register that shows what must be rebuilt, what can be retired and who owns each item. Confirm the list with the analysts who run the playbooks, because undocumented behavior usually surfaces here.
Export playbooks as .tgz archives
Export each playbook from Splunk SOAR (On-premises) as a .tgz playbook archive, using the export options in the playbook editor, and store the archives in version control with the inventory. Check which saved version each archive contains, since only the saved version is exported. The archives serve as the reference for rebuilding logic, not as a file to import into Tracecat. Confirm the export with the playbook owner before any Splunk SOAR configuration is changed.
Map Python custom functions to Tracecat
Review each custom function and decide whether its logic becomes a Tracecat workflow step or a custom action synced from Git. Functions that call external APIs usually fit a custom action with a reviewed repository and tests, while routing logic usually fits a workflow with conditions. Expect the largest share of effort here when playbooks chain many custom functions or depend on Splunk-specific data structures. The output is a mapping table with one target per function and an agreed owner for each custom action.
Rebuild asset configurations and credentials
Recreate each integration in Tracecat with its own credentials, scoped to the least access the playbook needs. Splunk SOAR asset settings do not transfer as-is, so every endpoint, certificate and service account must be entered again and tested against a non-production target. Store secrets in the platform's secret handling or your existing secrets manager, and record who approved each service account. The step is complete when each integration returns a successful test call from the Tracecat environment.
Move case handling into Tracecat cases
Decide which open Splunk SOAR cases close in place and which carry over as Tracecat cases. Recreate the case fields, severities and analyst assignments the team relies on, and confirm that case tables and tags support the reporting you need. Keep an export of closed Splunk SOAR cases for the retention period your policy requires. The step is complete when analysts can open, update and close a test case in Tracecat with the fields they used before.
Reconnect the SIEM as the alert source
Point the alert source at Tracecat's webhook triggers while the existing SIEM keeps sending alerts. Confirm the payload fields that each workflow reads, because a renamed or missing field can silently stop a playbook. Keep the Splunk SOAR ingestion path disabled for the test alerts so the two platforms do not act on the same event. The output is a documented trigger map for each workflow, agreed with the SIEM owner.
Run parallel validation
Run the rebuilt Tracecat workflows beside the Splunk SOAR playbooks against the same replayed or sampled alerts, and compare actions, case updates and notifications for each. Record every difference, decide whether it is a defect or an intended change, and fix the defects before the next run. Include failure paths, such as an unavailable integration or a timeout, because those are where durable execution and error handling differ most. The step closes when the agreed test cases produce matching outcomes and the owners sign off.
Cut over and retire Splunk SOAR workflows
Switch the alert triggers to Tracecat, disable the matching Splunk SOAR playbooks, and watch the first live alerts with the analysts who will own the workflows. Keep the Splunk SOAR archives and configuration backup available for the period your records policy requires, then decommission the platform. Confirm with your license and support contacts how Splunk SOAR contract terms end. The move is complete when every production alert is handled in Tracecat and the decommission record is signed.
Questions buyers ask before switching from Splunk SOAR to Tracecat
What drives the cost of moving from Splunk SOAR to Tracecat?
The biggest driver is how much custom Python and how many apps and assets you run today, because each playbook and custom function has to be rebuilt as a Tracecat workflow or custom action. Costs fall into three groups: the platform itself (a self-hosted Tracecat deployment has infrastructure and staff time, and an Enterprise Edition license if you need its gated features), the migration work (inventory, rebuilding playbooks, reconnecting assets and testing), and ongoing operations (upgrades, backups, monitoring and on-call). Splunk SOAR's license is the recurring cost you are replacing, so the comparison should net out what you stop paying. Ask any implementation partner for a fixed-scope quote built from a written inventory of your playbooks, apps, assets and cases.
How long does a move from Splunk SOAR to Tracecat take?
Duration depends on the size of your playbook estate, how much of it is custom Python, how many integrations need new configuration and how many cases must be carried over or closed out. The Splunk SOAR export format (.tgz playbook archives) helps you inventory playbooks, but it does not convert them, so each one needs review and rebuilding. A practical approach is to run both platforms in parallel for a defined set of playbooks, then cut over in stages. Tracecat's Docker Compose option on a single host is simpler to stand up than Kubernetes or AWS ECS Fargate, but production readiness depends on your data retention, high availability and backup targets. Ask for a timeline in the written scope rather than relying on general estimates.
Can our internal team migrate to Tracecat without outside help?
Yes, many teams do this in-house, but the work requires skills in Python, workflow design, API integrations and running containerized services. Your team needs to rewrite each playbook as a Tracecat workflow, decide which custom functions become custom actions synced from Git, and set up Temporal, PostgreSQL and the S3-compatible object store that Tracecat uses. Teams with limited platform capacity often bring in outside help for the deployment, backup and hardening work, then keep the playbook rebuild in-house. DeployOpen plans, implements, customizes, integrates, hardens, backs up and documents self-hosted platforms in your own infrastructure, typically under a fixed-scope agreement. Whichever route you choose, the decision should follow an honest skills assessment of your team.
Which Tracecat features require the Enterprise Edition?
Tracecat's open-source edition is licensed under AGPL-3.0, while code in its enterprise packages and feature gates is under a separate paid Enterprise Edition license. According to the Tracecat repository, multi-tenant workspace management and Git version control integration are Enterprise features. The Tracecat documentation also describes authentication and single sign-on as enterprise features. Before you commit, confirm with Tracecat which features your environment needs, such as SSO with your identity provider, role controls, audit requirements and workspace separation, and get the license terms in writing. Note that Git-synced custom actions are a key part of the migration plan, so confirm whether your chosen setup depends on the Git integration that is gated.
Can we reuse our Splunk SOAR playbooks directly in Tracecat?
No, you should not expect a direct import. Splunk SOAR playbooks are exported as .tgz archives and rely on Splunk SOAR apps, assets and Python custom functions, while Tracecat uses its own workflow model, integrations and custom actions. The logic, decision points and response steps usually transfer well, but the implementation has to be rebuilt. Start by listing each playbook's triggers, the apps it calls, the assets it depends on and any custom Python it runs. Splunk's own migration documentation to its cloud service notes that custom code must be converted to Python 3 first, which is a useful checklist even when the destination is different. Treat the exported archives as the reference for logic, not as a deployable package.
What does the work require from security and platform staff?
Security staff own the response logic: which alerts trigger which workflows, what approvals are needed, how cases are triaged and which actions are allowed to change systems. Platform staff own the environment: container or Kubernetes hosting, PostgreSQL, the object store, Temporal, secrets handling, TLS, backups, monitoring and upgrades. Both groups should agree on the alert source (Splunk or another SIEM) and how credentials for each integration are stored and rotated. Expect to test each rebuilt workflow against realistic alert samples in a non-production environment before cutover, and keep Splunk SOAR running for rollback until you are confident. Document the design and the evidence from testing, since compliance assessors will ask for it.
Is Tracecat's open-source edition enough for our current case volume?
It depends on your case volume, number of concurrent workflows, integrations and how much you depend on gated features. Splunk SOAR's Community License limits (100 licensed actions per day, 1 tenant and 5 open cases) are a different measure from Tracecat's open-source limits, so do not compare them one for one. Instead, measure your current action counts, open case load and peak workflow concurrency over a representative period, then load-test a self-hosted Tracecat deployment against those numbers. Confirm with Tracecat which capabilities of the open-source edition cover your needs and which require the Enterprise Edition. Your answer should come from your own measurements and the written license terms, not from assumptions.
How to evaluate Tracecat against Splunk SOAR before committing
Before committing to Tracecat, run a time-boxed proof of concept that answers one question: can your team operate the platform with the playbooks you actually depend on? Pick two or three representative playbooks, ideally one high-volume alert triage flow, one that opens and updates cases, and one that calls a vendor API with an asset-level credential. Rebuild each as a Tracecat workflow with webhook triggers, and record every step where the rebuild needed a workaround, a new integration or a change to how your analysts work. Those gaps, not the happy path, determine the migration effort.
Next, test one custom action synced from Git. Write a small action in Python, commit it to the repository your team already reviews, and confirm that a change merged to the tracked branch reaches the workflow as expected. Check how a failed sync, a rollback and a credential rotation behave, and whether the audit trail shows who changed what. Also confirm which of these steps need the Enterprise Edition, because multi-tenant workspace management and Git version control integration are listed there, and single sign-on is described as an enterprise feature in the Tracecat documentation. If your Splunk SOAR use depends on one of those controls, put that dependency into the evaluation rather than assuming the free edition will cover it. Measure operating load during the trial, not only build speed. Track how many services the chosen deployment needs (Docker Compose on a single host, the Helm chart on Kubernetes, or the air-gapped option), how much time goes to upgrades and Temporal and PostgreSQL maintenance, and who on your team can diagnose a stuck workflow. DeployOpen plans, implements and hardens self-hosted platforms in your own infrastructure under a written, fixed-scope agreement, so the planning, implementation and hardening can be defined in writing before the proof of concept starts. Ask for those deliverables, and their boundaries, in writing.
Steps to test Tracecat against your Splunk SOAR playbooks
This sequence moves a Splunk SOAR estate to a documented go or no-go decision on Tracecat, covering scope, environment, licensing, playbook rebuild and named sign-off. Each step ends with an output your reviewers can check.
Define the playbook scope to test
Inventory every Splunk SOAR playbook, custom function and app connection, then select a representative subset that covers your highest-volume alerts, your container and case handling, and at least one playbook that calls a custom Python function. Record which playbooks are in scope and which are retired. Your security operations lead owns this list, and the step is done when each in-scope playbook has a named owner and a documented trigger, such as a webhook, SIEM alert or manual case action.
Choose the Tracecat deployment environment
Use the Docker Compose option on a single host for evaluation, since Tracecat documents it for that purpose. Plan a Kubernetes deployment through the Helm chart for any production path, and check whether an air-gapped Kubernetes deployment is required by your network rules. Your platform engineering lead makes the choice. The step closes when the target environment, its PostgreSQL and S3-compatible object store dependencies, and the Temporal-based execution layer are written into a short architecture note.
Check the licence against Enterprise features
Compare each in-scope requirement with the feature list in the Tracecat documentation and the repository. Single sign-on and authentication features are described as enterprise features, and multi-tenant workspace management and Git version control integration are named as Enterprise features in the repository. Ask Tracecat for a written statement of which features the AGPL-3.0 edition covers and what the Enterprise Edition license includes and costs. The step is done when your compliance lead signs a table mapping each requirement to a licence tier.
Rebuild the scoped playbooks as Tracecat workflows
Rebuild each in-scope playbook as a Tracecat workflow with webhook triggers, case management and custom actions, and keep custom action code in a Git repository so it syncs into the workspace. Map each Splunk SOAR app action to a Tracecat integration or a custom action, and re-enter asset credentials through the vault or secrets process you use. Your automation engineers do the rebuild. The step closes when each workflow runs against a test alert and its output matches the Splunk SOAR result for the same input.
Run the test cases and record results
Replay recorded alerts from your SIEM through both the Splunk SOAR playbooks and the Tracecat workflows in a test environment. Compare actions taken, case records created, error handling and timing. Log every gap, including any Splunk SOAR app with no Tracecat equivalent, which must be built as a custom action or dropped. Your security engineers own the test log. The step is complete when every in-scope playbook has a pass, fail or rework entry with evidence attached.
Hold the go or no-go review
Convene a review with named owners: the head of security operations for analyst workflow fit, the platform engineering lead for operating model and hosting, the compliance lead for licence and data residency, and the Splunk SOAR owner for the cutover plan. Review the licence table, the test log and the rebuild effort. The decision is recorded in writing as go, no-go or conditional, with the conditions and a named owner for each open gap. Ask DeployOpen or your implementation partner for a fixed-scope quote only after this record exists.
How DeployOpen helps you evaluate, implement or migrate
DeployOpen is a Chainscore Labs company that plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For Splunk SOAR versus Tracecat, we start by mapping your playbooks, case volumes and identity requirements to a written scope before any build work begins.
How we scope
- We inventory existing Splunk SOAR playbooks, custom Python functions, apps and assets to see what moves and what is retired.
- We check which Tracecat features your identity and tenancy needs require, including whether Enterprise Edition licensing applies.
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before any work starts.
How we build
- We deploy Tracecat in your environment using the Docker Compose, Kubernetes, AWS ECS Fargate or air-gapped option that fits your constraints.
- We rebuild priority playbooks as Tracecat workflows and custom actions, with Git sync configured so changes are reviewed.
- We connect your existing SIEM as the alert source and test webhook triggers, case handling and rollback paths before cutover.
How we hand over
- You receive architecture notes, runbooks, a playbook mapping register and a record of each test and its result.
- We walk your security operations and platform teams through case handling, workflow changes and the Git review process.
- We document the controls and evidence your compliance assessors may ask for, while independent auditors issue any formal opinion.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- We track Tracecat releases, test upgrades in a staging environment and document the changes before they reach production.
- Retainer scope, response expectations and upgrade cadence are set in writing so you can confirm them before signing.
