Migrate from Cortex XSOAR to Tracecat

Migrate from Cortex XSOAR to Tracecat: what the move involves

If a renewal, a licensing change, a residency requirement or lock-in pressure has pushed you to look at Tracecat, be clear about what you are signing up for: the move is a rebuild of your playbooks and integrations, plus a move of incident handling into Tracecat cases. It is not a file import. Tracecat's workflows are its own, so XSOAR playbooks, scripts and integrations have to be understood, redesigned and re-tested before they run in a new tool. Expect the work to be led by security engineering, with the SOC lead deciding which response procedures matter most and an implementation partner, if you use one, handling deployment, integration and hardening. Start by inventorying what XSOAR actually does today, including which playbooks run on real alerts and which are dormant.

On effort and risk, the largest variables are the number of production playbooks, how many integrations depend on XSOAR-specific runtime logic, and how much of your incident history, SLAs and analyst notes must carry over into Tracecat cases. Custom content that uses JavaScript or depends on XSOAR's runtime will not transfer as-is, so plan to rewrite it. Use the export steps described in the Cortex XSOAR 8 manage playbook content documentation to retrieve source logic, then treat the exported files as reference rather than a finished product. Ask any implementation partner for a written scope that names the playbooks, integrations and case fields in play, and confirm timelines against that inventory.

Licensing matters here too. Tracecat is licensed under AGPL-3.0, and the repository states that code in packages/tracecat-ee and enterprise feature gates falls under a separate paid Enterprise Edition license. Multi-tenant workspace management, Git version control integration and single sign-on are listed as Enterprise features, so if your environment needs any of them, confirm with Tracecat the terms, price and support model before you design around them. Also confirm that your deployment model fits your data residency constraints, since Tracecat documents Docker Compose, AWS ECS Fargate, Kubernetes and air-gapped Kubernetes options. Running both tools in parallel until response times match is the lowest-risk path.

Which XSOAR capabilities map to Tracecat and which need rework

This table maps the main XSOAR building blocks against Tracecat's documented features and marks each as clean, needs rework or gap. Read the status column first, then check the notes for the work each item will take. Items that depend on the Enterprise Edition, especially SSO and multi-tenant workspaces, need confirmation against your own requirements before you plan the migration.

Capability	Tracecat equivalent	Status
Playbooks	Workflows with webhook triggers and actions; logic is rebuilt, not imported	Needs rework
Integrations	Prebuilt connectors (more than 100 listed) plus custom actions synced from Git; confirm each vendor you use is covered	Needs rework
Scripts	Custom actions or workflow steps; JavaScript and XSOAR runtime logic must be rewritten	Needs rework
Incident types and layouts	Cases in Tracecat case management; field and layout mapping must be designed by hand	Needs rework
War room	No direct equivalent documented; analyst collaboration must be handled in cases or an external chat tool	Gap
Tables and lists	Structured tables in Tracecat	Clean
Scheduled jobs	Confirm scheduling options in the Tracecat documentation before relying on them for recurring jobs	Needs rework
User roles	Workspace roles to be mapped; confirm role granularity against your XSOAR roles	Needs rework
SSO and multi-tenant workspaces	Documented as Enterprise Edition features under a separate paid license; confirm before planning	Gap
Custom AI agents	Custom AI agents with tools and MCP servers; new capability, not a direct XSOAR mapping	Clean

What data and integration work moves across

Playbooks and custom content can be exported from XSOAR, but an export is a starting inventory, not a finished migration. Incident data, analyst work and credentials follow different paths, and each integration has to be matched to a Tracecat capability before any workflow is rebuilt.

Export custom content first

In XSOAR 8, custom content is exported from Settings, Server Settings, Custom content, then Export all custom content, and individual playbooks can be downloaded from the content item menu. Treat the export as an inventory: list every playbook, script and integration it contains, note which ones are still in production, and record who owns each one. Ask your XSOAR administrator to confirm which versions your installation runs, since the export options can differ between XSOAR 6 and XSOAR 8.

Re-express exported playbooks

An exported playbook is XSOAR logic, not a Tracecat workflow. Each task, conditional branch and sub-playbook must be redesigned as a Tracecat workflow with webhook triggers and actions, and any scripts that depend on XSOAR's runtime must be rewritten. Plan a review step for every exported item so that the rebuilt workflow is tested against the same sample alerts before it replaces the original.

Check each integration against connectors

Tracecat's repository lists more than 100 prebuilt connectors, but that count does not confirm coverage for your tools. Match every integration instance in use to a prebuilt connector, a custom action synced from Git, or a generic HTTP call. Pay particular attention to integrations with custom commands, older API versions and vendors that XSOAR content packs maintain. Any integration without a clear match becomes a build item with its own owner.

Incident history and attachments

Open incidents, closed incident history, attachments and evidence stored in XSOAR do not move with the playbooks. Decide which records must stay queryable for audits or legal holds, and whether they will be exported to an archive or kept in XSOAR read-only for a defined period. Ask your compliance lead to confirm retention requirements in writing before any data is deleted.

Analyst notes and war room history

Analyst notes, war room entries and investigation timelines are the record of how decisions were made, and they are easy to lose during a cutover. Confirm which of these must be carried into Tracecat cases, which will be referenced by ID in an archive, and who signs off that the transferred notes are complete. Note that the mapping of incident fields and layouts is a separate decision covered by the case management topic.

Re-enter integration credentials securely

API keys, service accounts and certificates configured in XSOAR cannot be assumed to export in usable form. Re-enter each credential into Tracecat's secrets handling, use the least privilege the integration needs, and rotate any credential that was shared across instances. Record who issued each credential so that revocation is possible when a platform is retired.

Migration sequence from inventory to decommission

This sequence moves XSOAR automation into Tracecat one use case at a time, so each cutover is proven against live alerts before the next one begins. Each step produces a written record that your SOC, security engineering and audit owners can review.

Inventory playbooks, integrations and incident types
Export every custom playbook, script and integration from XSOAR using the custom content export in Settings, then download individual playbooks from the content item menu for review. Build an inventory register that lists each playbook, the integrations and credentials it calls, the incident types and triggers that start it, and the owner who signs off on the logic. Mark items that depend on XSOAR runtime behavior or that have no Tracecat equivalent yet. The step is done when every production playbook has a row and an owner has confirmed the list is complete.
Build and test a pilot workflow in Tracecat
Choose one bounded use case with a clear trigger and a low blast radius, such as enrichment of a single alert type. Rebuild it as a Tracecat workflow with webhook triggers, connect the required connectors, and store secrets according to your existing vault policy. Run the workflow against recorded or test alerts in a non-production workspace and compare its outputs field by field with the XSOAR results. The output is a tested pilot with a short test log that records inputs, expected outputs and any gaps you chose to accept.
Run both platforms in parallel
Send the same alerts from the SIEM to XSOAR and to the Tracecat workflow for the chosen use case, while analysts continue to work in XSOAR. Record, for each alert, the time to first action, the enrichment results, the case or ticket created, and any difference in disposition between the two platforms. Review mismatches with the playbook owner and fix the Tracecat workflow or document the accepted variance. The output is a parallel run log that shows where the two platforms agree and where they do not.
Cut over each use case with re-pointed triggers
When the parallel run log shows acceptable agreement, re-point the SIEM alert forwarding or webhook for that use case so that alerts reach Tracecat as the primary path, and disable the matching XSOAR playbook trigger. Confirm that incident handling, notifications and evidence capture for that use case now happen in Tracecat cases. Keep the XSOAR playbook in place but disabled so that rollback is a configuration change. The output is a cutover record that names the use case, the date of the change, the trigger changes made, the approver and the rollback steps.
Repeat cutover for remaining use cases
Work through the remaining rows of the inventory register in priority order, grouping playbooks that share integrations or triggers so that credentials and connectors are configured once. Apply the same pilot, parallel run and cutover checks to each group, and update the inventory register with its status. Track any playbook that is deferred, retired or left in XSOAR for a documented reason. The output is an inventory register where every row has a final status and a linked cutover or retirement record.
Confirm response times match before decommission
Compare response measures for the migrated use cases over a period you agree with your SOC leadership, using the same metrics you captured during the parallel runs. Confirm that case handling, approvals and audit trails meet the requirements your compliance owners set, and that all evidence is retained in your own storage. Ask your compliance team which records they need to keep from XSOAR before retirement. The output is a written comparison that shows response times for each migrated use case beside the XSOAR baseline.
Decommission XSOAR and record the retirement
Once the comparison supports retirement, export final archives of playbooks, incident data and logs that your retention policy requires, and store them in a location your records owner controls. Revoke XSOAR integration credentials, remove the SIEM forwarding that still points to XSOAR, and shut down the servers or subscription in line with your contract terms. Confirm the exit terms and data return or deletion steps with Palo Alto Networks or your reseller in writing. The output is a retirement record listing the archives created, the credentials revoked, the systems shut down and the sign-off from the CISO or delegate.

How Tracecat's self-hosted deployment fits your environment

Tracecat documents four self-hosted routes: Docker Compose on a single host, AWS ECS Fargate provisioned through Terraform, Kubernetes through a Helm chart, and an air-gapped Kubernetes deployment with no runtime internet access. The choice drives everything after it. A single Docker Compose host suits a lab or proof of concept, while a production SOC that needs redundancy, rolling upgrades and network isolation will usually land on Kubernetes or ECS. If you run XSOAR 6 on premises in a disconnected site, the air-gapped Kubernetes route is the one to examine first. Confirm the exact topology, supported versions and install prerequisites against the Tracecat documentation before you size hardware or request cloud accounts.

The stack is more than the application container. Tracecat's backend is Python with FastAPI, its frontend is Next.js, workflows execute durably on Temporal, data sits in PostgreSQL, files go to an S3-compatible object store, and nsjail sandboxes execution. Each component adds something to run. Your platform team needs to own the Temporal cluster and its persistence, back up PostgreSQL and the object store together, and decide whether to use managed or self-run versions of each. Your automation engineers need Python for custom actions and familiarity with Temporal's failure and retry behavior when a playbook step stalls. Ask the vendor or your own tests to confirm how each component scales and recovers before you commit to a topology.

Plan the operational work before the first workflow moves. Identify who will patch Temporal, PostgreSQL and the object store, how secrets for connectors reach the workers, and where logs from the sandboxed actions go. Confirm the air-gapped procedure with your own network team, including how container images and connector updates reach the disconnected cluster. Connectors that call external APIs will need a route, or a documented offline process, before any playbook can run. Treat the first environment as a test bed that proves backup, restore and upgrade procedures, since a SOAR that cannot be restored quickly will fail the first time an incident needs it.

What drives migration cost and duration

This table lists the factors that move the cost and length of a move from Cortex XSOAR to Tracecat, with why each one matters and how to keep it under control. Use it to scope a fixed-scope engagement and to ask vendors and partners the right questions before you commit to a timeline.

Driver	Why it changes cost or effort	How to keep it down
Number of playbooks and custom integrations	Each playbook and integration is a separate rebuild, test and sign-off item, so the inventory count sets the base effort. Confirm the counts with an export before quoting.	Retire unused playbooks during the inventory, merge near-duplicates and rebuild only what is still triggered by live alerts.
Share relying on XSOAR runtime logic or JavaScript integrations	JavaScript integrations and scripts tied to XSOAR's runtime do not transfer as-is, so each one needs a Python or Tracecat action rewrite and new tests. This is often the largest variable.	Classify every item early as portable, rewrite or retire. Ask for the classification in writing as part of the scoped inventory.
Incident volume and SLA rules	Higher volume means more workflow executions to validate, and SLA timers, escalation and severity rules must be re-expressed in Tracecat cases and tables.	Document SLA rules as a short table before rebuilding. Test the highest-volume alert types first.
Number of SIEM and ticketing feeds	Every SIEM, EDR or ticketing feed needs a webhook trigger, field mapping and a test path, and each one adds integration and data-quality checks.	Consolidate feeds where possible and map fields once in a shared schema for cases.
Enterprise Edition scope	Multi-tenant workspaces, Git version control, single sign-on and related features sit in Tracecat's paid Enterprise Edition under a separate license. Adding them changes the license cost and the configuration work.	Decide which enterprise features are required before design. Confirm current license terms directly with Tracecat.
Hosting and Temporal operations	Self-hosting requires running the FastAPI backend, Next.js frontend, Temporal, PostgreSQL and an S3-compatible store. Ongoing patching, backups and upgrades are recurring labor, and an air-gapped Kubernetes build adds image transfer steps.	Choose the deployment model (Docker Compose, Kubernetes Helm chart or air-gapped Kubernetes) against your existing platform skills. Ask for an operations runbook and upgrade plan in the scope.
Parallel run length	Running XSOAR and Tracecat side by side keeps two sets of licenses, infrastructure and on-call procedures active until response times match. The length of this period is the most direct driver of total cost.	Agree exit criteria per use case, such as matched response times and analyst sign-off, before the parallel run starts, and retire each use case as soon as it meets them.

What usually goes wrong and how to prevent it

Most failed XSOAR-to-Tracecat moves fail on hidden dependencies rather than on the workflow engine itself. The cards below cover the six failure points we see most often, each paired with a check to run before cutover.

Playbooks tied to XSOAR runtime

Some XSOAR playbooks depend on runtime behavior such as built-in scripts, the war room context, incident field lookups and task-level assignments that have no direct Tracecat equivalent. Export every playbook and script, then tag each step as a plain API call, a data transform or an XSOAR-specific function. Rebuild only the first two types as-is and redesign the third type around Tracecat workflow logic before anyone signs off.

Incident fields and SLAs lost in translation

XSOAR incident types, custom fields, layouts and SLA timers often drive analyst routing and escalation. Tracecat cases carry their own fields and tables, so a field that existed only in an XSOAR layout can disappear silently during migration. Build a field map from each incident type to a Tracecat case schema, then test a sample of closed incidents to confirm that severity, owner and timestamps survive the move.

Credentials and integrations not re-authorized

XSOAR integration instances hold API keys, service accounts and certificates that do not carry over as working secrets in Tracecat. Each connector must be configured again in the Tracecat workspace with credentials scoped to the minimum actions the playbook needs. Keep a register of every connector, its owner and its rotation date, and confirm each one returns a test result before any production trigger points at it.

Enterprise features assumed but not licensed

Teams often assume multi-tenant workspaces, Git version control and single sign-on are available in Tracecat because they were part of their XSOAR setup. 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 as enterprise features too. Before design starts, list every XSOAR capability your team uses, check it against the open-source edition, and confirm any gap with Tracecat before cutover.

Cutover without a parallel run

Switching all triggers from XSOAR to Tracecat on one date removes the baseline needed to judge whether response quality held. Run both platforms on the same alert types, log which tool handled each case, and compare time to triage and time to containment against XSOAR history. Move a use case to sole ownership by Tracecat only after the parallel results match the agreed criteria, and keep the XSOAR playbook available for rollback until then.

Analysts losing the war room habit

Analysts who worked in the XSOAR war room often rely on it for live notes, command history and handoffs between shifts. Tracecat cases hold the record, but the way analysts collaborate inside a case differs, and that change can slow triage during the first weeks. Run a short training session with the actual case views, write a shift-handoff standard for case comments, and collect analyst feedback during the parallel run so gaps are fixed before the old habit disappears.

How the migration differs by starting point

Teams running XSOAR 6 on premises usually already control the hosts, network and change process, so the main question is connectivity. If the site is air-gapped, Tracecat's documented air-gapped Kubernetes deployment, which has no runtime internet access, becomes the target shape, and the build must be staged with every image, connector and dependency brought in through your own transfer process before cutover. Because XSOAR 6 has its own end-of-life schedule, the migration work should start early enough that the team is not forced to move under the deadline.

Deployment target: Plan a Kubernetes cluster inside the enclosure, with PostgreSQL, the S3-compatible object store and Temporal all running locally.
Content transfer: Export custom content and playbooks from the XSOAR 6 server and review each item for runtime-specific logic before rebuilding.
Connector inventory: Confirm which integrations can run without internet access, since any vendor API that needs an outbound path must be reachable from inside the enclosure.
Parallel running: Keep XSOAR 6 processing live incidents while Tracecat handles a narrow set of workflows, then widen scope.
Update path: Define how new Tracecat releases and images are imported into the disconnected network.

Before committing, confirm with your network and security teams which services may cross the boundary, and ask Tracecat's documentation how the air-gapped deployment handles upgrades.

Questions buyers ask before moving from Cortex XSOAR to Tracecat

What does a move from Cortex XSOAR to Tracecat cost?

The cost is driven by the amount of custom content to rebuild, the number of integrations that need replacement, and the hosting you choose, rather than by the Tracecat software itself, which is AGPL-3.0 licensed. Plan for four cost components: the infrastructure to run Tracecat (its Docker Compose, AWS ECS Fargate, Kubernetes or air-gapped Kubernetes options each need different capacity), your internal staff time, the engineering time to rebuild playbooks and connectors as workflows, and any support or retainer you add afterward. Some costs are one-time, such as migration and testing, while hosting, patching and upgrades recur. Ask any quote for an inventory-based estimate, the list of components in scope, and whether Enterprise Edition features such as SSO or multi-tenancy are priced separately.

How long does it take to move playbooks to Tracecat?

Duration depends on how many playbooks, integrations and custom scripts you run, how many of them are business-critical, and how complex their branching logic is. Teams with a small, well-documented set usually move faster than teams with years of accumulated content and undocumented dependencies. Parallel running adds time, because you need to keep XSOAR and Tracecat both handling incidents until response times match your targets. No duration is fixed in advance, so ask for a timeline tied to a written scope with named deliverables, and confirm which of your XSOAR content is in the first phase.

What does our internal team need to provide?

Your team needs to supply knowledge and access, not just approvals. The main inputs are an inventory of playbooks, scripts and integrations with owners, the list of SIEM and ticketing sources that trigger them, credentials and API access for each downstream tool, and a sign-off person who can judge whether a rebuilt workflow behaves correctly. You also need someone who understands your incident types, severity definitions and escalation paths, because these shape how cases and tasks are modeled in Tracecat. Ask the implementation partner to confirm exactly which of these inputs are needed in your environment before work begins.

Can our own team do the migration without a partner?

Yes, a capable internal team can migrate, provided it has engineers who can read XSOAR playbooks, write Python or work with API integrations, and operate Tracecat's stack, including PostgreSQL, Temporal and the object store. The export path is documented, since XSOAR 8 lets you export all custom content and download individual playbooks, but not everything transfers cleanly, so expect manual rework. Most teams weigh the internal hours against the time needed to stay on schedule with live incident response. An external partner is usually scoped for specific phases, such as the inventory, a pilot playbook or hardening, rather than the whole program.

Do cases move with the workflows into Tracecat?

Workflows and cases are separate things to migrate. Tracecat includes built-in case management, structured tables and webhook triggers, so incident records can live in the same tool as the automation that handles them. Migrating existing XSOAR incidents, layouts, war room notes and SLA fields is a distinct task, and it is not automatic. Decide early whether historical incidents are archived for reference, imported, or left in XSOAR for the retention period your policy requires, and map incident fields to Tracecat case fields before rebuilding any analyst workflow.

Are SSO and multi-tenancy included in open-source Tracecat?

Not in the open-source edition. The Tracecat repository names multi-tenant workspace management and Git version control integration as Enterprise features, and its documentation describes authentication and single sign-on as enterprise features as well. The code in its Enterprise Edition directory and feature gates is under a separate paid license. If your XSOAR deployment depends on SSO for analysts or on separate tenants for business units or customers, include those requirements in your evaluation and confirm the licensing terms with Tracecat directly before you plan the architecture.

How do we run XSOAR and Tracecat side by side safely?

Run them in parallel by use case rather than by whole SOC, so one playbook at a time moves to Tracecat while XSOAR keeps handling everything else. Route alerts through a single trigger source during the overlap, or use distinct ones so you never process the same alert in both tools. Compare outcomes, such as time to triage, containment actions taken and false positive rates, for each migrated use case before retiring the XSOAR version. Keep write actions in one system at a time, and document the cutover criteria in your change record so auditors and incident leads can see when responsibility moved.

Which Tracecat deployment fits a regulated or air-gapped network?

Tracecat documents self-hosted deployment on a single host with Docker Compose, on AWS ECS Fargate through Terraform, on Kubernetes through a Helm chart, and an air-gapped Kubernetes deployment with no runtime internet access. For a disconnected network, the air-gapped Kubernetes option is the one to evaluate, but you must confirm how connectors, updates and container images get into the environment. Your security team should also review the sandboxing approach, which uses nsjail, and the data stores, which use PostgreSQL and an S3-compatible object store, against your own data classification and retention rules.

How DeployOpen scopes and runs the migration

DeployOpen is a Chainscore Labs company that plans, implements, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure. For a move from Cortex XSOAR to Tracecat, we start with a written inventory of your playbooks, integrations and incident handling, then rebuild and run the work in your environment, with the side-by-side period agreed in advance.

How we scope

Inventory every XSOAR playbook, script and integration, and mark which ones are used by live incident types.
Agree in writing which playbooks move to Tracecat workflows and which stay on XSOAR during the overlap.
Confirm Tracecat deployment target, such as Docker Compose, Kubernetes or air-gapped Kubernetes, and the Enterprise features you need.

How we build

Rebuild prioritized playbooks as Tracecat workflows with webhook triggers, connected to your existing alert sources.
Move incident handling into Tracecat cases and map XSOAR incident fields to case fields agreed with your analysts.
Test each rebuilt workflow against recorded alerts and compare outputs with the XSOAR results before switching it live.

How we hand over

Deliver the workflow inventory, mapping documents, runbooks and configuration records for your operations team.
Document what did not transfer, including XSOAR-specific runtime logic, so owners can decide on replacements.
Run a planned side-by-side period and record response-time measurements so you can judge readiness yourselves.

How we support

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
Ongoing support, upgrades and continuous testing of the Tracecat deployment are available as a retainer.
Quotes follow from the written scope, so ask for line items covering inventory, build, testing, handover and support.

Migrate from Cortex XSOAR to Tracecat