Migrate from Splunk SOAR to Tracecat

Docker Compose on a single host is the lightest documented option. It suits evaluation, a proof of concept, or a small team that wants to run Tracecat next to its existing Splunk or other SIEM feed while playbooks are rebuilt. All components, including the API, frontend, workflow engine and data stores, share one machine, so the host is also the single point of failure and the capacity ceiling.

• Best fit: pilots, lab environments and migrations where the rebuild runs in parallel with the live Splunk SOAR instance.
• Operational load: one host to patch, back up and monitor, with no cluster skills required.
• Scaling limit: capacity and recovery depend on that one machine, so plan a larger-scale target before production cutover.
• Data stores: confirm how PostgreSQL and the S3-compatible object store are persisted and backed up on the host.
• Alert feed: confirm the webhook path from your SIEM can reach the host through your firewall rules.

Before relying on this target for production, confirm with the Tracecat documentation that the single-host layout meets your availability and backup expectations.

The AWS ECS Fargate path deploys Tracecat through Terraform into an AWS account you control. It fits organizations that already run security tooling on AWS, have Terraform practices and want managed container hosting without managing Kubernetes nodes. Your team owns the cloud account, networking, IAM roles, secrets and the Terraform state, so the shared responsibility split is explicit.

• Best fit: AWS-hosted environments with existing infrastructure-as-code review and change control.
• Managed compute: Fargate removes node patching, while your team still manages the surrounding AWS services.
• Data services: decide whether PostgreSQL and the object store are AWS-managed services or self-run components, and confirm the Terraform module supports your choice.
• Network placement: keep the webhook endpoint reachable from the SIEM and restrict administrative access to private paths.
• Recurring cost: compute, managed database, storage and logging are billed by AWS, so get a per-component estimate in writing.

Confirm the Terraform module version, the required AWS services and the Temporal deployment model against your own account and data residency rules before approving this target.

The Kubernetes option installs Tracecat with a Helm chart onto a cluster your platform team operates. It suits organizations with an established cluster, GitOps tooling and the skills to manage ingress, storage classes, secrets and upgrades. It is the usual choice when Tracecat must run beside other internal services with shared monitoring and policy controls.

• Best fit: teams with a production cluster, standard ingress and centralized observability.
• Stateful components: PostgreSQL, Temporal and object storage need persistent volumes or external services, which must be sized and backed up.
• Upgrades: version changes arrive through the chart, so pin versions and test them in a staging namespace first.
• Secrets and identity: route credentials through your existing secrets manager rather than values files in source control.
• Skills required: plan for cluster administration time, which recurs after go-live.

Confirm the chart version, the Temporal and PostgreSQL topology, and your storage backup targets with your platform team before committing to this path.

The air-gapped Kubernetes deployment is documented for environments with no runtime internet access. It serves regulated or classified networks, isolated security zones and operators who cannot allow outbound calls from the automation platform. Everything the platform needs at runtime, including container images and dependencies, must be staged into the isolated network through an approved transfer process.

• Best fit: isolated security enclaves where outbound connectivity is prohibited by policy.
• Artifact transfer: build a controlled process to bring images and chart dependencies across the boundary, with recorded approvals.
• Integrations: prebuilt connectors that call external SaaS APIs will not reach them from the enclave, so confirm which integrations must target internal endpoints.
• Updates: patching becomes a scheduled import, so align upgrade cadence with your change board.
• Evidence: keep records of every imported artifact for your assessors.

Confirm with Tracecat which components and integrations the air-gapped documentation covers, and validate the transfer process in your own environment before cutover.

A small team with a handful of playbooks on the Community License has the shortest inventory and the lowest cutover risk. The playbook count is small enough that each one can be read, rebuilt as a Tracecat workflow and tested against a sample alert before anyone depends on it. Much of the work sits in connections, because each app login and asset has to be recreated as a Tracecat integration and the alert source pointed at a webhook trigger.

• Inventory: list each playbook, the apps it calls and the assets it targets. A spreadsheet is usually enough at this size.
• Rewrite scope: short flows of lookups, enrichment and notifications are practical to rebuild by hand.
• Case handling: decide whether open cases are closed in Splunk SOAR before cutover or carried over as records in Tracecat case management.
• Cutover risk: run both systems in parallel for a short window, send the same test alerts to each and compare outcomes.
• Credentials: enter new API keys in Tracecat and retire the old ones in Splunk SOAR after cutover.

Before starting, confirm with your Splunk SOAR administrator which Community License limits apply to your instance and which playbooks run on a schedule, since scheduled playbooks are easy to miss in a manual inventory.

A large on-premises estate with many apps, assets and custom Python functions carries the most inventory and rewrite effort. Custom functions do not map one to one onto Tracecat, so each one needs a decision: rebuild it as a custom action, replace it with an existing connector or retire it. The cutover itself is usually better planned in waves than as a single switch, because each wave exposes a different set of dependencies.

• Inventory: export playbooks and catalog custom functions, internal libraries and Python dependencies before estimating anything. Ask for this inventory from the team that owns each app.
• Rewrite scope: Tracecat custom actions are synced from Git, so decide early how repositories, review and rollback will work.
• Cutover risk: group playbooks by business function and move one group at a time, keeping Splunk SOAR as the fallback for the group still in production.
• Operations: Tracecat uses Temporal for durable workflow execution, PostgreSQL and an S3-compatible object store, so the platform team needs to run those components alongside the application.
• Enterprise features: SSO, multi-tenant workspaces and Git version control integration are listed as Enterprise Edition features, so confirm licensing before designing access for each team.

Ask the Tracecat team which deployment model fits your estate, then confirm how much of the Python logic can move into actions without changes to internal dependencies.

A team already preparing a move to Splunk SOAR (Cloud) faces two migrations at once unless it chooses a target first. Splunk documents moving administration settings, apps, playbooks and custom functions to Splunk SOAR (Cloud), and it requires custom code to be converted to Python 3 before that move. Work done for the Cloud move is useful to a Tracecat move, but it is not a substitute for rewriting the code into Tracecat's action model.

• Decision point: choose the target before converting custom code, so the Python 3 effort is not repeated for a second platform.
• Reusable work: Python 3 code, documented inventories and tested playbook logic can be carried forward into Tracecat rewrites.
• Scope freeze: agree which playbooks, apps and assets are in scope for each path, and stop changes to the rest until the target is set.
• Export format: the classic playbook editor was deprecated in 2024, so confirm which playbook format your exports use before rebuilding them.
• Parallel running: keep the Cloud or on-premises instance available until the Tracecat cutover is verified.

Review the Splunk migration documentation with your Splunk contact, and confirm in writing which items the Cloud migration carries across and which items you must rebuild.