Which SOAR fits your team: Cortex XSOAR or self-hosted Tracecat
Choose Cortex XSOAR when vendor support and your existing playbook estate matter more than hosting control. Palo Alto Networks offers Cortex XSOAR 8 as SaaS or on premises, so a team can choose its hosting model without changing products. If you run XSOAR 6 on premises with many playbooks, integrations and an analyst war room in daily use, most of the migration cost sits in rebuilding that content, and staying with a vendor-supported path may be the lower-risk choice at the next renewal. Confirm with Palo Alto Networks which 6.x release is supported on your timeline and whether that support covers your disconnected sites.
Choose Tracecat when you want self-hosted workflows and case management in one tool under the AGPL-3.0 license. The core is AGPL-3.0, while code in the enterprise package sits under a separate paid license, so check which features your team actually needs before assuming the free core covers them. The documentation describes Docker Compose on a single host, AWS ECS Fargate through Terraform, Kubernetes through a Helm chart, and an air-gapped Kubernetes deployment with no runtime internet access. For a team on XSOAR 6 in a disconnected network, that last option is the first one to test in a non-production cluster before any decision is made.
The decision turns on three questions. First, how much existing content must move: XSOAR exports and Tracecat workflows are not interchangeable, so inventory playbooks and integrations before comparing license costs. Second, whether you need single sign-on and multi-tenancy, which the Tracecat documentation and repository place in the Enterprise Edition, so price that tier into the comparison. Third, whether your team can operate the Tracecat platform, which uses Temporal for durable execution, PostgreSQL for data, an S3-compatible object store and nsjail for sandboxing. Check the Tracecat documentation for current requirements, and if that capacity is missing, ask for a written scope that names who runs and patches each component.
Which option fits which situation
This table maps common Cortex XSOAR situations to the option that usually fits better, with the condition that makes each advantage matter. Read each row against your own estate, licensing dates and compliance scope before choosing, because the right answer often depends on the condition rather than the product.
| Situation | Better fit | Why it matters under that condition |
|---|---|---|
| XSOAR 6 on premises in a disconnected network | Tracecat (air-gapped Kubernetes) | Tracecat documents an air-gapped Kubernetes deployment with no runtime internet access. Confirm with the Tracecat documentation that your Kubernetes and image-transfer process meets your network rules. |
| Large estate of custom playbooks and scripts | Depends on logic type; plan a rebuild | Tracecat workflows are rebuilt, not imported, so expect effort proportional to playbook count. Stay on XSOAR while porting, and export content first to inventory it. |
| MSSP serving several clients from one platform | Tracecat with Enterprise Edition | Multi-tenant workspace management is listed as an Enterprise feature in Tracecat's repository. Ask whether the Enterprise license covers your tenant model before assuming isolation. |
| Team wants cases and automation in one tool | Tracecat | Tracecat includes case management, tables and workflows together. Shuffle has no built-in incident layouts, so it would need a separate case system. |
| Team needs SSO on day one | Confirm before choosing either open option | Tracecat describes authentication and single sign-on as enterprise features, so SSO may require a paid license. Confirm the licensing terms with the vendor before planning. |
| Mostly event-driven remediation, little analyst case work | Shuffle or StackStorm | Shuffle's app creator builds integrations from OpenAPI, and StackStorm targets event-driven remediation. Neither replaces XSOAR's analyst war room, so pair either with a case tool. |
| Need for long-running, durable automation | Tracecat | Tracecat uses Temporal for durable workflow execution, which matters when response steps wait on approvals or external systems for long periods. |
How Tracecat runs workflows on Temporal and PostgreSQL
Tracecat is built as a set of separate services, and the one that matters most for reliability is Temporal, which runs its workflow executions. The stack is a Python FastAPI backend, a Next.js frontend, PostgreSQL for application data, an S3-compatible object store for files and artifacts, and nsjail for sandboxing custom code. Durable execution means Temporal records each workflow step as it completes, so if a worker crashes or a remote API times out, the run resumes from the last recorded step rather than starting over. That matters for containment actions that must not run twice and for response workflows that wait hours for an analyst approval. Ask the vendor how retry policies are set per action and how the team tests a workflow that is interrupted mid-run.
Running this stack is the operating decision that XSOAR's delivery model changes. In Cortex XSOAR 8 SaaS, Palo Alto Networks operates the platform, while the on-premises edition is installed through a terminal installer and the customer runs the server stack, upgrades and backups itself. Tracecat is self-hosted in every option, so your team owns the Temporal cluster, the PostgreSQL database with its backups and upgrades, the object store and the workers that execute actions. The documented paths are Docker Compose on a single host, AWS ECS Fargate through Terraform, Kubernetes through a Helm chart and an air-gapped Kubernetes deployment. Confirm with Tracecat which of these the team can operate, and who will be on call for Temporal and database failures outside business hours.
Monitoring should cover four things: Temporal workflow and task queue health, including workers that stop picking up tasks, PostgreSQL capacity and replication, object store availability for case attachments, and the failure rate of custom actions. Plan for the fact that a workflow history grows as runs get longer, so set retention for Temporal and the database before volume arrives. Before cutover, run a test in which a worker is stopped during a multi-step playbook and confirm that the run finishes correctly. Where your SOC currently depends on XSOAR's own uptime, document the recovery objectives you need from this stack and check that the architecture can meet them.
Where your data sits under each option
Each option puts Cortex XSOAR and Tracecat in a different place, and that placement decides who holds case data, who controls identity and what evidence your team must gather. The cards below compare five deployment paths on those three points so you can match the hosting model to your data residency and audit obligations.
XSOAR 8 SaaS (vendor hosted)
Palo Alto Networks hosts this version, so incident data, playbook run history and stored credentials sit in the vendor's cloud rather than in your data center. Identity usually flows through the vendor's login and your identity provider, which you must confirm with the vendor. Your evidence set centers on vendor assurance reports, data processing terms, region selection and your own export and access reviews. Ask where the tenant is located and how custom content is exported if you leave.
XSOAR on premises (8 and 6)
Both on-premises versions run on servers you control, so incident records, playbooks and integration credentials stay inside your network boundary. XSOAR 8 on premises installs through a step-by-step terminal installer, while XSOAR 6 is the line Palo Alto points disconnected sites toward. Your identity integration and log forwarding are configured by your team, and your evidence includes patch records, backup tests and access reviews for the host and the application. Confirm the support status of your exact release before you commit.
Tracecat on a single host with Docker Compose
A Docker Compose install keeps the whole stack, including the Python API, Next.js frontend, PostgreSQL, the object store and Temporal, on one machine you operate. This suits a pilot or a small team, but one host is also a single point of failure for case data and workflow history, so backups and restore tests carry the weight. Authentication and single sign-on are listed as Enterprise Edition features, so plan the login model before you rely on it. Your evidence is host hardening, backup and restore records and the configuration baseline.
Tracecat on AWS ECS Fargate or Kubernetes
Tracecat documents deployment on AWS ECS Fargate through Terraform and on Kubernetes through a Helm chart, which places data in the AWS account or cluster you own and in the region you choose. Identity can be tied to your cloud IAM and cluster controls, but application sign-on still depends on the feature set of your edition. Your evidence includes infrastructure-as-code records, network policies, secrets handling and the access model for the cloud account. Confirm which managed services Tracecat's Terraform module provisions in your account.
Air-gapped Kubernetes with no internet access
The documented air-gapped Kubernetes deployment has no runtime internet access, so connectors, workflow data and case records never leave your isolated network. Identity must be reachable only inside that network, which usually means an internal directory and a documented process for updates and images brought in through a controlled transfer. Your evidence covers the transfer and change log, image provenance, offline backups and the network isolation proof. Confirm with Tracecat which connectors need outbound access and how you will handle their updates.
Licensing and editions to check before you commit
Cortex XSOAR is a commercial product, so your rights to use it come from a subscription agreement with Palo Alto Networks rather than from an open-source license. Cortex XSOAR 8 is offered as SaaS or on-premises, and the on-premises version is installed through a step-by-step terminal installer, according to Palo Alto Networks documentation. The terms that govern each deployment model, including what the subscription covers, how renewals work and what support you receive, are set in your contract and order documents.
- Deployment model: Confirm whether your subscription covers SaaS, on-premises or both, and whether moving between them is included or billed separately.
- Version scope: Check which Cortex XSOAR release your agreement covers, since the 6.x and 8.x lines carry different support windows.
- Renewal and true-up: Ask how seats, integrations or content packs are counted at renewal and what happens to usage above the purchased amount.
- Content ownership: Confirm in writing that your custom playbooks and scripts remain yours and that export is permitted under the agreement.
- Exit terms: Ask what notice period applies and how long you can keep access to exported content after the subscription ends.
Before signing, ask Palo Alto Networks or your reseller to put these points in writing and have your legal team review them.
Tracecat's core is licensed under AGPL-3.0, a copyleft license. You can run, study and modify the core code, but the license attaches conditions when you distribute modified versions or make them available to users over a network. The AGPL's network clause means that if you modify Tracecat and let other people interact with the modified version over a network, you may need to offer them the corresponding source code of your changes. Whether that applies to your deployment depends on who uses the system, whether you change the code, and how you connect it to other tools, so treat this as a question for legal counsel.
- Internal use: Running unmodified or internally modified Tracecat for your own security team is the lowest-risk pattern, but confirm your legal reading of the network clause.
- Modified and network-offered versions: If you change the code and expose it to customers, partners or an MSSP's clients, plan for source disclosure of those changes.
- Custom actions and workflows: Confirm with counsel whether workflow definitions, custom actions and AI agent configurations count as part of the program or as separate works.
- Contributions: Check whether your organization needs a contributor agreement before upstreaming fixes.
- Documentation: Keep a record of every modification and where it runs, which helps during due diligence.
Have counsel review the license text and your intended deployment before you build anything on top of the core.
Some Tracecat code sits outside the AGPL-3.0 core. The repository places code in packages/tracecat-ee and enterprise feature gates under a separate paid Enterprise Edition license, so using those parts requires a commercial agreement. The repository names multi-tenant workspace management and Git version control integration as Enterprise features, and the documentation describes authentication and single sign-on capabilities as enterprise features as well. If your plan depends on SSO or multi-tenancy, the Community build may not meet it.
- Single sign-on: Confirm whether SSO is in the edition you plan to run and which identity protocols it supports for your directory.
- Multi-tenancy: If you run separate workspaces for business units, clients or an MSSP model, confirm the tenant limits and isolation model in the Enterprise terms.
- Git version control: Check whether syncing workflows and custom actions to Git is included, since it affects change control.
- Support and updates: Ask what support, security fix timing and upgrade assistance the paid license includes.
- Feature gates: Ask for a written list of features gated in the version you intend to deploy.
Ask Tracecat for the current edition comparison and a written statement of which features your chosen version includes.
Licensing decisions interact with deployment choices and with the features you need. A team that plans air-gapped operation, a single sign-on integration or a multi-tenant SOC should map each requirement to the edition and agreement that provide it before committing budget or engineering time. Both options can change, so the terms you check today should be confirmed again at renewal or upgrade.
- Feature inventory: List every capability your playbooks rely on, such as case management, tables, AI agents, SSO and tenancy, and match each to a license tier.
- Deployment target: Confirm the deployment model your edition supports, including the air-gapped Kubernetes path documented for Tracecat.
- Support boundaries: Separate vendor support from community support and from implementation help in your contract.
- Written quotes: Ask every vendor for a written scope and license summary that names the editions, versions and features covered.
- Legal review: Route both license texts to counsel, especially the AGPL-3.0 network obligations and any paid edition terms.
No licensing terms here are legal advice, so verify them with your vendor and counsel before you sign.
What drives the cost of each option
Cortex XSOAR's cost is mostly recurring, and the largest recurring line is the subscription and its renewal. Palo Alto Networks sells XSOAR 8 as SaaS or on premises, and XSOAR 6 on premises is moving toward end of life, so the renewal date and the target version change the price. Ask the vendor for the license metric (for example, how usage is counted), the term, what is included in the on-premises installation and whether the quote covers the content packs your playbooks depend on. Your XSOAR 6 renewal may also include a version upgrade, which belongs in the comparison rather than being treated as a sunk cost.
Tracecat's open-source edition has no license fee, so its costs sit in infrastructure and staff. Plan for the hosting of the Tracecat application, its Temporal workflow engine, PostgreSQL, the S3-compatible object store and the Kubernetes cluster in an air-gapped network. Each of these runs continuously, so hosting, backups, patching and storage growth recur every month. Confirm with your platform team which of these components you already operate, because a team that already runs PostgreSQL and Kubernetes carries less new cost than one that does not. The Enterprise Edition license is a separate line: if you need single sign-on or multi-tenant workspace management, ask Tracecat for the price of that license in writing before you compare totals.
The largest cost in both options is often staff time, not software. Rebuilding playbooks as Tracecat workflows, writing custom actions, testing them against your SIEM and maintaining them after each vendor or API change are one-time and recurring efforts. Implementation and support fees from a partner are also one-time or retainer-based, depending on scope. When you request quotes, ask each party to split the figures into one-time migration work, annual license or subscription, infrastructure, staff hours, and support or upgrade retainers, with the assumptions behind each line. A quote that cannot be split this way is hard to compare.
Cost components on each side, one-time and recurring
A Cortex XSOAR total cost of ownership is split between a vendor subscription and the work around it, while a self-hosted Tracecat cost is split between infrastructure, people and optional Enterprise Edition licensing. The cards below separate one-time migration work from recurring spend, and name what moves each line up or down.
Licensing and subscription
On the XSOAR side, the recurring cost is the Palo Alto Networks subscription or license, and the price depends on the deployment (SaaS or on premises) and the contract terms. On the Tracecat side, the AGPL-3.0 Community Edition carries no license fee, but the Enterprise Edition is a separate paid license for features such as SSO and multi-tenant workspaces. Ask Palo Alto Networks for the written subscription terms and renewal conditions, and ask Tracecat whether your required features sit in the paid edition.
Infrastructure and hosting
Tracecat runs as several services: a FastAPI backend, a Next.js frontend, Temporal for durable workflow execution, PostgreSQL, an S3-compatible object store and nsjail for sandboxing. Each component adds compute, storage and backup cost that recurs every month. Costs rise with the number of concurrent workflows and the volume of case attachments. Confirm sizing with Tracecat's deployment documentation for Kubernetes or ECS, and compare it with your existing XSOAR server, database and collector footprint.
Enterprise Edition features
Multi-tenant workspace management, Git version control integration, and authentication and single sign-on are listed as Enterprise features. If your XSOAR use depends on those capabilities, the Tracecat cost is the Enterprise license rather than the Community Edition, and that license is a recurring cost to negotiate. Ask for the price, the term, the support level and what happens to workspaces and workflows if the license lapses before you sign.
Engineering time to rebuild content
This is the largest one-time cost in most migrations. XSOAR playbooks, scripts and integrations must be inventoried, exported and rebuilt as Tracecat workflows and custom actions. Cost rises with the number of playbooks, the use of JavaScript integrations and logic tied to XSOAR's runtime, and the number of incident types that need case mapping. Estimate it per playbook, and ask any partner to price it against a written list of content items.
Operations, upgrades and staff time
On XSOAR, upgrades follow Palo Alto Networks' release and end-of-life schedule, and on premises sites handle patching themselves. On Tracecat, a self-hosted team owns Temporal, PostgreSQL and object storage upkeep, upgrades and backups. This is recurring engineering time, and it grows with the number of environments and the availability you need. Ask who carries the on-call duty and how often upgrades are expected.
Training and external support
Analysts and engineers need training on Tracecat's workflow editor, case management and tables, which is a one-time cost, plus refreshers as the platform changes. External support, whether from a vendor subscription or a implementation partner under a retainer, recurs. Confirm which support tier is included in each option, the response expectations written into the contract, and whether knowledge transfer is part of the scope.
How a move from Cortex XSOAR to Tracecat unfolds
The sequence moves playbooks, integrations and incident handling out of XSOAR in controlled stages, so each use case is proven in Tracecat before XSOAR is switched off. The output is a documented inventory, rebuilt workflows and cases, and a retirement record for XSOAR.
Inventory playbooks, integrations and custom content
Your team, with the XSOAR administrators, lists every playbook, script, integration and incident type that is in use. Export the custom content from Settings, Server Settings, Custom content, using Export all custom content, and download individual playbooks from the content item menu where you need them separately. The step is complete when each item has an owner, a business purpose and a note on whether it is still triggered by a live incident source. Ask Palo Alto Networks or your reseller to confirm which export formats your XSOAR version produces before you rely on them.
Classify what transfers and what needs redesign
Sort the inventory into three groups: content that can be rebuilt as Tracecat workflows, content that maps to a Tracecat custom action or AI agent tool, and content that depends on XSOAR's runtime or JavaScript integrations. Those in the last group do not transfer directly and need a new design, so flag them early and assign an engineer to each. The output is a classified list that shows which use cases can move first and which need design work before any build starts.
Stand up Tracecat in your own infrastructure
Deploy Tracecat in the environment where your data may stay, using the Docker Compose, Kubernetes Helm or air-gapped Kubernetes option that matches your network rules. Confirm the components the deployment needs, including Temporal, PostgreSQL and an S3-compatible object store, and check that the sandboxing layer runs on your hosts. The step is done when a test workflow runs end to end, is logged, and survives a restart. Confirm the supported deployment path and hardware requirements with the Tracecat documentation before sizing.
Rebuild workflows, actions and case handling in Tracecat
Rebuild the prioritized playbooks as Tracecat workflows with webhook triggers, connect them to the prebuilt connectors or to custom actions synced from Git, and move the incident fields, statuses and analyst notes that matter into Tracecat case management and structured tables. Keep credentials in your own secrets store and record each connector you rely on. Confirm each connector in your catalog against the API version your security tools expose. The output is a set of workflows with a test record for each one, and a list of any gaps that still need a custom action.
Run both platforms in parallel for each use case
Switch one use case at a time to Tracecat while XSOAR continues to handle the same alert source, then compare outcomes. Watch for duplicate tickets or actions, confirm that the same alerts reach both systems, and have analysts record where Tracecat cases differ from XSOAR incidents. Agree the pass criteria in writing before the parallel run starts, for example matching triage outcomes and response times set by your SOC. The step closes when each use case meets those criteria and the owner signs off.
Cut over each use case and disable its XSOAR playbooks
Point each alert source at Tracecat for the use cases that passed the parallel run, then disable the matching XSOAR playbooks and integrations, keeping their exports archived. Confirm that the alert routing, on-call escalation and audit logging all work from Tracecat before the XSOAR path is removed. The output is a cutover record per use case showing the date, the owner and the rollback path. Do not disable XSOAR entirely until every use case has been cut over.
Retire XSOAR and document the new operating model
Once no use case depends on XSOAR, shut down the server, remove its integrations and retain the archived exports, incident records and configuration under your records policy. Update the runbooks, access reviews and evidence locations so they point to Tracecat. Ask your auditors or compliance team which records they need to see for the retired platform before deletion. The step is complete when XSOAR is decommissioned, its records are archived, and the operating runbooks name Tracecat as the system of record.
Questions buyers ask before choosing Tracecat over XSOAR
How much does moving from Cortex XSOAR to Tracecat cost?
The cost depends on the scope of the work, not on a figure we can publish. Tracecat's core is licensed under AGPL-3.0, so the software itself carries no license fee, but Tracecat's Enterprise Edition features are under a separate paid license. The main cost components are the infrastructure to host Tracecat, the staff time to inventory and rebuild playbooks and integrations, the time to move case handling, and ongoing support. Your current XSOAR subscription or renewal is a separate line item that ends on a date you control. Ask any quote provider to separate one-time migration effort from recurring hosting, staffing and support, and to state which Enterprise features are included and what they cost. DeployOpen does not publish prices; a quote follows from a written scope.
How long does a Cortex XSOAR to Tracecat migration take?
Timing is set by how many playbooks, integrations and incident types you run, how much of your case work depends on XSOAR layouts and the war room, and how many teams must sign off. Rebuilding each workflow in Tracecat takes less time when the logic is simple and the integrations are already available as Tracecat connectors. Custom integrations need more work, and so does moving incident handling into Tracecat cases. Running both platforms side by side until response times match the old setup usually extends the schedule, which is a deliberate choice you should plan for. Confirm the sequencing, parallel-run period and acceptance criteria in writing before work starts.
What does the team need to run a migration to Tracecat?
The team needs people who understand your current XSOAR playbooks, your SIEM and ticketing triggers, and your analysts' case practices. On the engineering side, someone must own workflow design in Tracecat, integration credentials, secrets handling and change control, including custom actions synced from Git. Security operations must agree on how cases, tables and AI agents are used before the old process is retired. Plan for time from the analysts who will test the new workflows, because their acceptance decides when XSOAR can be switched off.
Can our own team migrate from XSOAR to Tracecat without outside help?
A team with Python, workflow automation and container operations experience can migrate a small playbook set internally. The harder parts are inventorying custom content, rebuilding integrations that have no Tracecat connector, and deciding how incident data maps into cases. Many teams combine internal ownership with an external partner for the architecture, deployment and hardening, then keep operations in-house. Be honest about the skills you have today, especially for hosting Temporal and PostgreSQL in production. DeployOpen plans, implements, hardens and documents self-hosted platforms in your own infrastructure, and most engagements are fixed-scope with written deliverables.
Does Tracecat's air-gapped Kubernetes deployment work for XSOAR 6 on-premises sites?
Tracecat's documentation describes an air-gapped Kubernetes deployment with no runtime internet access, which is the deployment pattern that disconnected XSOAR 6 sites would need to consider. Whether it fits your site depends on your Kubernetes platform, how you transfer container images and Helm charts across the boundary, how you load connector updates, and whether the integrations you need can run without outside calls. Confirm these points with Tracecat and in your own test environment before you commit, and check the Tracecat documentation for the current requirements. Your XSOAR 6 version and its end-of-life date also affect how much time you have to test.
Do SSO and multi-tenancy in Tracecat require the Enterprise Edition?
Yes, based on the Tracecat materials we reviewed. The Tracecat documentation describes authentication and single sign-on as enterprise features, and the repository names multi-tenant workspace management and Git version control integration as Enterprise features. Code in the enterprise packages and feature gates sits under a separate paid Enterprise Edition license, while the core is AGPL-3.0. If your identity model or tenant separation depends on these features, ask Tracecat for the current feature list, license terms and cost, and confirm how the AGPL-3.0 obligations apply to your modifications and internal use with your legal team.
Do we need dedicated Temporal and PostgreSQL skills to run Tracecat?
You need staff who can operate them reliably, but the skill set is a planning input rather than a fixed requirement. Tracecat uses Temporal for durable workflow execution and PostgreSQL for data, and it also depends on an S3-compatible object store and nsjail for sandboxing. Someone must own backups, upgrades, capacity, monitoring and failure recovery for each of these components. If that expertise is not in-house, budget for training or outside operations support, and ask for the upgrade and backup procedures in writing. Confirm the supported versions and recommended topology with Tracecat before you size the environment.
When staying on Cortex XSOAR is the better choice
Keeping Cortex XSOAR is the better choice when the cost of rebuilding exceeds the cost of running it. That usually means a large estate of working playbooks, integrations and vendor-maintained content packs that your analysts depend on daily, or a mandate from audit, insurance or procurement that requires a named vendor to support the platform. If your SOC runs its incident process through XSOAR incident types, layouts and the war room, moving automation to Tracecat still leaves you with a case-handling rebuild, so count that effort before you commit. Confirm with your Palo Alto Networks account team which content packs and integrations your version supports, because vendor content does not transfer to an open-source tool.
The deadline is the factor that most often changes this decision. Palo Alto Networks lists 6.12 and 6.13 as reaching end of life on June 30, 2026, while 6.14 remains active and is the version it recommends for on-premises and air-gapped sites. If your estate runs 6.12 or 6.13, you must either upgrade within 6.x, move to Cortex XSOAR 8 as SaaS or on premises, or replace the platform. Staying on 6.14 is a valid option for a disconnected site, but it postpones the migration question rather than settling it. Check your support contract for the 6.14 support window and for any terms that apply to XSOAR 8.
If you plan to move to XSOAR 8, decide that before you invest in an open-source rebuild. Export your custom content from Settings, Server Settings, Custom content, using Export all custom content, and test the archive against a non-production XSOAR 8 instance to see which items import cleanly. A short inventory will show whether your playbooks depend on version-specific behavior. If the inventory shows that most of your value sits in a few analyst-facing workflows, a self-hosted Tracecat deployment may be the cheaper path, and a parallel run lets you compare response times before you retire XSOAR.
How DeployOpen helps you evaluate, implement or migrate
DeployOpen plans, implements, integrates, hardens, backs up, upgrades and documents self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For Cortex XSOAR vs Tracecat, that means working from your actual playbooks, integrations and deployment constraints rather than a generic comparison.
How we scope
- Inventory your XSOAR playbooks, integrations, incident types and triggers before choosing what moves to Tracecat.
- Agree deployment target in writing: single host Docker Compose, Kubernetes via Helm, or air-gapped Kubernetes.
- Confirm which Enterprise Edition features you need, such as SSO and multi-tenancy, before the scope is fixed.
How we build
- Rebuild priority playbooks as Tracecat workflows with webhook triggers and tested connector actions.
- Set up Temporal, PostgreSQL and the S3-compatible object store with backup and restore procedures.
- Test case handling, tables and AI agent actions against your own sample alerts in a non-production workspace.
How we hand over
- Document workflows, connector configuration, secrets handling and the deployment topology for your team.
- Export and version custom actions through Git so content stays under your control after handover.
- Run a parallel period with XSOAR where needed, then record which workflows have cut over and why.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Plan Tracecat version upgrades and test them against your workflows before production rollout.
- Prepare control evidence for your compliance assessment; independent auditors issue any attestation or certification.
