Which SOAR fits a SOC that mainly needs cases and automation
QRadar SOAR fits SOCs that value IBM's supported case workflow and the integrations they already run, and that can keep paying per authorized user plus the VM or OpenShift platform beneath it. Tracecat fits SOCs that want a self-hosted, AGPL-3.0 licensed case and automation platform that also runs AI agents, and that need the data to stay on servers they control. The renewal or a residency requirement usually triggers the review, so first write down which one is driving it. Tracecat's core is open source, but several features sit under a separate paid Enterprise Edition license, so the comparison has to map those features before the decision is made.
Three factors decide the outcome. The first is which Enterprise features you need. Tracecat's repository names multi-tenant workspace management, Git version control integration, and authentication and single sign-on as Enterprise features. Git version control matters most for teams that want reviewed, versioned playbooks, even though custom actions can be synced from Git. Single sign-on is usually the first item a SOC needs, because it determines whether analysts sign in with the corporate directory or with local accounts. Ask Tracecat in writing which edition includes each feature, and check the Tracecat documentation for the current boundary.
The second factor is how many people will build workflows. Under per-user licensing, each builder is a cost line, while a self-hosted platform shifts cost toward infrastructure and the staff who run it. The third factor is whether your team can operate the stack. Tracecat uses Temporal for durable workflow execution, PostgreSQL for data and an S3-compatible object store. It documents Docker Compose on a single host, AWS ECS Fargate through Terraform, Kubernetes through a Helm chart, and an air-gapped Kubernetes option. A team that already runs Kubernetes and those three services can absorb the platform, while a team without them should cost that operating work before choosing.
Which platform fits which SOC scenario
This table matches five common SOC conditions to the platform that fits each one better, and names the reason tied to that condition. Read each row against your own team size, deployment standard and data boundary, because the better fit changes when those conditions change. Most rows depend on details you should confirm with IBM and with Tracecat before committing.
| Scenario | Better fit | Why it matters under this condition |
|---|---|---|
| Single-team SOC using cases with light automation | QRadar SOAR, if IBM's case model and integrations already match your workflow | A case system with stable, well-understood tasks gains little from new tooling, and migration effort is hard to justify when most work is manual case handling. Tracecat fits better only if you want to self-host and cut licensing per user. |
| SOC needing AI agents and MCP tools | Tracecat | Tracecat documents custom AI agents with tools and MCP servers and lists more than 50 hosted MCP servers. Confirm which of these capabilities are in the edition you plan to run, since some features are gated behind the Enterprise Edition. |
| Team with a strict OpenShift standard | QRadar SOAR on OpenShift, unless your OpenShift policy also permits Kubernetes Helm deployments | IBM offers an OpenShift option for QRadar SOAR, which fits an existing platform standard without a new deployment pattern. Tracecat documents Kubernetes deployment through a Helm chart, so the choice depends on whether your OpenShift rules accept that chart and its dependencies. |
| Air-gapped environment | Tracecat, if it can run offline on your Kubernetes cluster | Tracecat documents an air-gapped Kubernetes deployment with no runtime internet access. Confirm with the vendor how updates, connectors and container images reach the isolated network before relying on it. |
| Multi-tenant MSSP | Neither as a default, and confirm enterprise terms first | Tracecat names multi-tenant workspace management as an Enterprise feature, so it needs a paid license. Ask IBM and Tracecat how each handles tenant isolation, per-client access and licensing before you choose. |
Where data lives and who controls the platform
Tracecat runs entirely inside the infrastructure you choose, so the data location question comes down to which deployment model you pick and who operates it. The cards below cover hosting options, identity, and the evidence an assessor will ask for on either side of a move from IBM QRadar SOAR.
Hosting models Tracecat supports
Tracecat documents four self-hosted paths: 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. Each path puts case data, workflow state and logs in a different place. Confirm which path matches your current QRadar SOAR network zoning before you pick one, because the single-host option has a different availability profile from a cluster.
Where Tracecat stores data
Tracecat keeps relational data in PostgreSQL, stores files in an S3-compatible object store, and uses Temporal for durable workflow execution. Each of these is a separate backing service you must place, back up and encrypt. Map which service holds case attachments, workflow history and action outputs, and confirm where each one lands in your environment.
Vendor-hosted data in QRadar SOAR
QRadar SOAR is deployed as a virtual machine or on OpenShift in your environment, so incident data already sits under your control. The change in control comes from the upgrade cycle and the licensing relationship, not from where the database lives. Document where your current QRadar SOAR data resides, including any vendor support access, so the comparison with Tracecat reflects your real starting point.
Identity and SSO boundaries
The Tracecat documentation describes authentication and single sign-on as enterprise features, so confirm which identity options your current Tracecat edition includes before you design access. Map QRadar SOAR user roles and group membership to Tracecat workspaces and roles, and check how service accounts for automation are issued and rotated. Plan for the identity provider you already use rather than assuming SSO comes with the community build.
Air-gapped operation considerations
The air-gapped Kubernetes option removes runtime internet access, which affects connectors, MCP servers and any custom actions that pull code from Git. Tracecat lists more than 100 prebuilt connectors and more than 50 hosted MCP servers, and those external calls need an internal route or a mirrored alternative. Test each integration you rely on from inside the isolated network before cutover.
Compliance evidence to gather
DeployOpen prepares controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications; independent auditors and certification bodies do. Gather configuration baselines, access reviews, backup and restore test records, change history for playbooks and workflows, and logs showing who ran which automation. Ask your assessor which of these they expect for SOAR in your scope before you finalize the design.
Which Tracecat features need the Enterprise Edition
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. For a SOC comparing it with IBM QRadar SOAR, the practical question is which capabilities sit on the paid side of that line. The Tracecat repository names three as Enterprise features: multi-tenant workspace management, Git version control integration, and authentication and single sign-on, which the Tracecat documentation also describes as enterprise features. Case management, webhook-triggered workflows, custom AI agents and custom actions synced from Git are presented as part of the platform, so confirm with Tracecat which of these, if any, depend on an Enterprise license in the version you plan to run.
Budget for this before you commit to a design. If your SOC needs single sign-on against your identity provider, which most regulated environments will, the Enterprise Edition is likely part of the cost model from day one. The same applies if you plan to run several isolated workspaces for different business units or customers, or to keep playbook and custom action code under Git review. Ask Tracecat for a written statement of which features are in the Community build, which require the Enterprise license, and whether the license terms cover self-hosted air-gapped or Kubernetes deployments.
QRadar SOAR charges per Authorized User under an annual subscription, so its cost grows with the number of analysts who hold a seat. Tracecat's split works differently: the core is open source, and the paid component is tied to specific capabilities rather than headcount. Neither model is inherently better, but they reward different planning. Model the Tracecat quote against the features you truly need, the number of workspaces and the identity integration, and model the QRadar SOAR quote against the seats you will license. Ask each vendor what changes at renewal and how the license is measured.
What drives cost on each side
Cost on both sides splits into licenses, the platform underneath, and the people who keep workflows running. QRadar SOAR bills recurring license and subscription fees, while Tracecat's core is open source, so the larger differences sit in infrastructure, staffing and migration effort.
QRadar SOAR licensing and subscription
QRadar SOAR is licensed per Authorized User, and support is typically bought as an annual subscription. This is recurring spend that rises with headcount, including analysts who only read cases. Ask your IBM representative exactly which users count as Authorized Users, how the subscription renews, and whether add-on integrations or additional sites carry separate charges.
QRadar SOAR platform hosting
On-premises QRadar SOAR runs as a virtual machine or on OpenShift, so you also carry the hypervisor or cluster, storage, backups and the upgrade cycle that comes with each release. These costs recur and are often budgeted under infrastructure rather than security. Confirm which OS, database and cluster versions IBM certifies for your chosen deployment before you size hardware.
Tracecat open-source core and Enterprise Edition
The core Tracecat code is licensed under AGPL-3.0, so there is no per-user fee for the open-source features. Code in the Enterprise Edition directory and enterprise feature gates requires a separate paid license. Multi-tenant workspace management, Git version control integration, and single sign-on are listed as enterprise features, so check whether your requirements depend on them before you budget.
Kubernetes cluster and Temporal operations
Self-hosted Tracecat runs on a single host with Docker Compose, on AWS ECS Fargate through Terraform, or on Kubernetes through a Helm chart. Its durable workflow engine, Temporal, and its PostgreSQL database and S3-compatible object store all need capacity, patching and backups. For production, the recurring cost is mainly the engineering time to operate these services, plus the cloud or hardware they run on.
Migration and playbook rebuild
This is largely a one-time cost. It covers inventorying QRadar SOAR playbooks and Python functions, mapping incident types and fields to Tracecat cases, rewriting functions as custom actions, and testing each workflow against live alert sources. Effort grows with the number of playbooks and custom integrations. Ask any implementation partner for a fixed-scope written plan that lists each playbook and its acceptance tests.
Staff who maintain workflows
The recurring cost that is easiest to underestimate is people. Someone must own the workflows, review AI agent tool access, keep custom actions synced from Git, and handle Tracecat upgrades. On the QRadar side, analysts and administrators also spend time on the vendor's upgrade cycle. Estimate this as a named role with a time share, and track it for the first two quarters after cutover.
What a move from QRadar SOAR to Tracecat involves
The sequence below takes a QRadar SOAR estate from inventory to a Tracecat deployment that handles live cases, with closed records kept for audits. Each step ends with an output you can check before the next one starts.
Inventory playbooks, functions and integrations
Export a complete list of the playbooks, scripts (Python functions), custom fields, incident types, and integrations in use, and note which ones fire automatically and which analysts run by hand. Your SOAR administrator and the integration owners do this, since they know which playbooks are still in use. The step is done when every automation has an owner and a disposition: rebuild, retire, or keep in QRadar SOAR until cutover.
Map incident types and fields to cases
Translate each QRadar SOAR incident type, its fields, and its task structure into Tracecat case fields, case statuses, and task patterns. Decide which fields need to be structured data for filtering and reporting. The output is a written mapping that a SOC lead signs off, with any gaps (fields with no equivalent, or custom types that need redesign) listed explicitly.
Rewrite Python functions as custom actions
QRadar SOAR functions written in Python need to be reworked as Tracecat custom actions, with their inputs and outputs defined and their dependencies checked against Tracecat's sandboxed execution model. Engineers do this work, and a Git repository is the natural place to hold the actions if your team uses version control. The step is complete when each action runs in a test workspace and returns the same result as its QRadar SOAR counterpart on sample data.
Rebuild playbooks as Tracecat workflows
Recreate each playbook as a Tracecat workflow with webhook or scheduled triggers, and point it at the actions and tables defined earlier. Where a playbook relied on a QRadar SOAR-specific behavior, record the change in the design rather than assume the behavior carries over. The output is a set of workflows that have passed review by the analysts who use them today.
Decide where closed cases are retained
Settle with your compliance or audit owner how closed QRadar SOAR incidents will remain available after cutover, for example by keeping the existing platform read-only for a defined period or by exporting records to an archive your organization controls. Confirm the retention requirement with your auditor or policy owner, since it depends on your regulatory obligations. The step is done when the retention decision is documented and a test retrieval of an archived case succeeds.
Test workflows in parallel
Run the Tracecat workflows alongside QRadar SOAR on the same or copied alert data, comparing the cases, tasks, and enrichment results each platform produces. Treat differences as defects to be resolved or accepted in writing. The step is complete when the analysts who own each playbook sign off on the results and the known differences are recorded.
Cut over alert sources
Move each alert source, such as a SIEM or other detection tool, to send new alerts to Tracecat one at a time, starting with the lowest-impact source. Keep QRadar SOAR available for in-flight cases until they close. The output is a dated cutover record per source and a confirmed list of cases still open in the old platform.
Questions buyers ask before switching from QRadar SOAR
What does a move from QRadar SOAR to Tracecat cost in effort, and what drives it?
The largest cost is internal and partner effort, not software. Tracecat's core is AGPL-3.0 licensed, so there is no per-user license fee to replace, but you still pay for the platform it runs on, the people who rebuild automation, and the time to validate it. Effort rises with the number of playbooks, custom Python functions, incident field mappings and alert sources you must reconnect. Ask for a written inventory of those items before any quote, because the inventory determines the scope. Quoted fixed scopes from DeployOpen follow from that written scope.
Can a SOC team do the migration itself without outside help?
A capable SOC team with automation experience can rebuild simple playbooks in-house, especially if it has someone comfortable with Python, webhooks and container platforms. Custom QRadar functions, multi-stage approvals and integrations with many internal tools usually need more time and a second pair of eyes. Be honest about who will maintain the workflows after cutover, since that work recurs. A split approach, where the team owns case design and an implementation partner handles deployment, hardening and custom actions, is a common option to evaluate.
How long does a move from QRadar SOAR take?
No timeline is given here because it depends on the number of playbooks, the complexity of custom code, how many alert sources must be cut over and how much parallel running you want. Ask any vendor or partner for a duration tied to a written scope, with milestones for inventory, build, test and cutover. Plan for keeping QRadar SOAR available in read-only form for closed cases until your retention requirements are confirmed.
What do internal staff need to provide during the migration?
Internal staff must supply knowledge that is not stored in the platform: why each playbook exists, which approvals are required, which incident types matter for reporting, and who owns each integration credential. Engineers need access to the existing QRadar SOAR environment, export of custom content and test systems where automation can run safely. Assign a named owner for case taxonomy and one for the target environment so decisions are not delayed.
Do single-team SOCs need Tracecat's paid Enterprise Edition features?
Probably not for core case management and automation. Tracecat documents workflow automation, webhook triggers, case management, structured tables, custom AI agents and custom actions synced from Git as part of the open-source platform. The repository names multi-tenant workspace management, Git version control integration, and authentication and single sign-on as Enterprise features. A single team may still want single sign-on or Git-based change control, so confirm which of these your identity and change policies require before choosing an edition.
How does the AGPL-3.0 license affect internal use of Tracecat?
Running Tracecat inside your own organization for internal security operations does not require you to publish your internal workflows. AGPL-3.0 has network-use obligations that matter if you modify Tracecat and offer the modified version to users over a network, including external parties. Code in the enterprise directories and enterprise feature gates is under a separate paid license. Have your legal team review the license text and your planned modifications, and confirm how any custom actions you write are classified.
What should we confirm with IBM and Tracecat before deciding?
With IBM, confirm your contract end date, notice period, data export options for cases, tasks and attachments, and what support remains available during a read-only period. With Tracecat, confirm the edition you need, the supported deployment model (Docker Compose, Kubernetes via Helm, AWS ECS Fargate or air-gapped Kubernetes), and the release you will pin to, since Tracecat 1.2.0 was released on October 16, 2026. Also confirm which connectors your tools need, because the repository lists more than 100 prebuilt connectors but yours may not be among them.
How DeployOpen helps evaluate and implement Tracecat
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure, including cloud accounts, data centers and air-gapped networks. For Tracecat, that means starting from your current QRadar SOAR case types, playbooks and integrations, then deciding which deployment path and edition fit your environment.
How we scope
- Inventory current QRadar SOAR case types, tasks, playbooks and integrations before any build starts
- Confirm target hosting: Docker Compose on one host, Kubernetes with Helm, or air-gapped Kubernetes
- Identify which needed features fall under Tracecat's Enterprise Edition, such as SSO or multi-tenant workspaces
- Agree deliverables and timelines in writing; engagements are fixed-scope and quoted from that written scope
How we build
- Deploy Tracecat in your environment with PostgreSQL, Temporal and object storage configured for your standards
- Map incident fields and cases, then rebuild playbooks as workflows with webhook triggers
- Turn Python functions into custom actions and sync them from Git under version control
- Test workflows against representative alerts and document results before cutover
How we hand over
- Deliver architecture, runbooks and configuration documentation for your operations team
- Document how closed QRadar SOAR cases are archived so audit evidence remains available
- Provide a handover session covering workflow ownership, change control and access roles
- Prepare control evidence for your compliance assessment; auditors and certification bodies issue the actual conclusions
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover
- Retainers can cover Tracecat version upgrades, backup checks and workflow changes as your SOC evolves
- Security testing of integrations and AI agents can be scoped separately under a written agreement
- Ask us to confirm current Tracecat release notes and edition features before planning an upgrade
