Migrate from IBM QRadar SOAR to Tracecat

Migrate from IBM QRadar SOAR to Tracecat: what the move involves

Most SOC and platform teams start this move at a renewal, a per-user licensing review or a residency requirement that makes hosted tooling hard to justify. The honest answer is that the move is three migrations running together: incident records and tasks into Tracecat cases, QRadar SOAR playbooks rebuilt as Tracecat workflows, and Python functions and app integrations rewritten as custom actions. Plan for a parallel run in which both platforms receive the same alerts until analysts trust the new workflows. The work is usually shared between the security engineers who own the playbooks and a platform or integration engineer who owns the Python code, with the SOC lead signing off on case types and closure rules. Effort depends mainly on how many playbooks exist, how many custom functions they call, and how many of those functions reach internal systems. Inventory every playbook from the QRadar SOAR customization settings before estimating anything, and ask any implementation partner for a quote built from that inventory, not from a platform-wide figure.

Tracecat covers the core of a SOAR-as-case-system deployment: case management, structured tables, webhook-triggered workflows and custom actions synced from Git. Confirm early which features your playbooks depend on, because 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 as well. If your analysts rely on single sign-on, workspace separation or Git-based change control, price the Enterprise Edition into the plan from the start rather than discovering the gap after cutover. Tracecat's self-hosted options include Docker Compose on a single host, AWS ECS Fargate through Terraform, Kubernetes through a Helm chart, and an air-gapped Kubernetes deployment, so the target platform can match where your QRadar SOAR runs today. Keep closed QRadar SOAR cases readable for audit by exporting them to a retention store before decommissioning, and confirm with your auditors which record formats they accept.

Which QRadar SOAR capabilities map to Tracecat and which need rework

This table maps the main QRadar SOAR objects to their Tracecat counterparts and marks each as clean, needs rework or gap. Clean means the object carries over with little change, rework means it must be reshaped or rebuilt, and gap means you should confirm the capability before planning. Authentication and SSO and multi-tenant workspaces are Enterprise features, so settle edition scope early.

Capability	Tracecat equivalent	Status	What to check
Incident cases and fields	Case management with case fields	Clean	Map incident identifiers, status, severity and custom fields, and list any fields without a match.
Tasks	Case records and workflow steps	Needs rework	Confirm how task owners and due dates will be tracked, or rebuild tasks as workflow steps.
Playbooks	Workflows with webhook triggers	Needs rework	Document each playbook's triggers, branches and actions, then rebuild it in the workflow editor.
Python custom functions	Custom actions synced from Git	Needs rework	Rewrite each function as a custom action and keep the code under Git version control.
Integrations and connectors	Prebuilt connectors and custom actions	Gap	Confirm each QRadar integration has a matching connector, otherwise plan a custom action.
Roles and analyst groups	Workspace roles and permissions	Gap	Confirm the role model in Tracecat documentation before mapping analyst groups and access.
Authentication and SSO	Enterprise feature	Gap	SSO is an Enterprise capability, so confirm licensing before the identity design is final.
Multi-tenant workspaces	Enterprise feature	Gap	Needed only when separating customers or business units, and it requires the Enterprise edition.
Closed cases for audits	Case records stored in your PostgreSQL database	Needs rework	Export closed cases to retained storage and confirm retention requirements with your auditor.

How Tracecat's case, workflow and action model replaces QRadar SOAR's

In Tracecat, a case is the unit that holds what QRadar SOAR calls an incident, and the fields you rely on today need a deliberate mapping rather than a direct copy. Tracecat's case management pairs with structured tables, so the data your SOC tracks in custom incident fields, such as severity, asset owner, regulatory flags and linked indicators, can live in a table your workflows read and write. Export your QRadar SOAR field definitions and decide, field by field, whether each becomes a case field, a table column or a value written into the case description. Confirm in a test workspace how structured tables are queried from workflows and how they appear to analysts, since that determines how much of your reporting survives the move.

Playbooks become workflows, and the main change is the trigger. Tracecat workflows start from webhook triggers, so each QRadar SOAR automatic rule or manual playbook launch needs an explicit inbound call from the SIEM, the ticketing system or an analyst action. Inventory which playbooks run automatically, because those need a webhook source and an owner for the sending side, and which are run by hand. Python functions that QRadar SOAR scripts call become custom actions, which Tracecat syncs from a Git repository. This gives you code review and version history for every action, and it also means the repository, its branch rules and its access controls become part of your change process. Verify how Enterprise features, including multi-tenant workspace management and Git version control integration, fit your governance model before you commit to a layout. Tracecat's backend is built on Temporal for durable workflow execution and PostgreSQL for data. Those components are what should keep long-running playbook steps, such as waits on a third-party approval or a retried API call, from being lost on a restart. Do not assume that behavior. Before cutover, run your longest playbooks in a test environment and force failures at each external call: confirm retry counts, timeout handling, what the analyst sees when a step fails, and whether a restarted run resumes or repeats side effects. Record the results as evidence for your change record.

What data to export and which integrations to rebuild

A QRadar SOAR move succeeds or fails on the inventory taken before cutover. Incident records, playbooks, custom functions and integrations each need a named owner, a target in Tracecat and a decision on whether history is migrated or archived. The cards below cover the items to list first.

Incident records and tasks

Export incident records with their incident types, custom fields, severity, status, owners and task assignments. Tracecat models work as cases with structured fields, so each QRadar SOAR incident type needs a mapping to a Tracecat case shape before data moves. Ask IBM which export formats and API endpoints your QRadar SOAR version exposes for incidents and tasks, and test a sample of closed incidents end to end before committing to a bulk load.

Notes, attachments and artifacts

Notes, attachments and artifacts carry the evidence an auditor will ask about, including who added what and when. Inventory where each file is stored, its size, and whether artifacts link to observables that Tracecat should keep as structured fields. Confirm with IBM how attachments and note authorship are exported, since timestamps and user identities often need a separate mapping to the new platform.

Playbook definitions

Start with the documented export path for custom content, then download each individual playbook from the content item menu. Record the trigger, conditions, branches, and every external call in each playbook, because those steps become Tracecat workflows with webhook or case triggers. Playbooks that are never run should be marked for retirement rather than rebuilt by default.

Custom functions and scripts

Python functions embedded in QRadar SOAR playbooks run inside the platform's runtime, so each one needs review for dependencies, credentials and hard-coded endpoints. Tracecat runs custom actions synced from Git, so each function becomes a versioned action with its own tests and secrets handling. Plan a code review step for every function, since the export shows the code but not the runtime environment it depended on.

Third-party integrations and credentials

List every outbound integration, such as SIEM, ticketing, identity and threat intelligence connectors, along with the account and API key each one uses. Tracecat provides more than 100 prebuilt connectors and supports custom actions, so each QRadar SOAR integration is either matched to a prebuilt connector or rebuilt as a custom action. Credentials should move into a secrets store rather than being copied into workflow definitions, and each service account should be re-issued under a named owner.

Users, roles and audit history

Export user accounts, roles, and the audit trail the SOC relies on for reviews. Single sign-on and authentication controls are described as Tracecat enterprise features, so confirm the licensing needed for your identity model before planning cutover. Decide how closed cases and their audit history stay retrievable after the QRadar SOAR license ends, and document the retention rule that applies to each class of record.

Migration sequence from inventory to decommission

This sequence moves IBM QRadar SOAR incident handling and automation to Tracecat in controlled stages, so each stage produces evidence the team can check before the next one starts. It ends with QRadar SOAR retired and its closed cases kept in a readable archive for audit.

Inventory incident types, playbooks and integrations
Export the QRadar SOAR configuration, including incident types, field definitions, playbook content and custom functions, and list every app integration and the systems each one calls. Assign an owner to each playbook and record how often it runs and which alert sources trigger it. The output is a mapping sheet that lists each playbook, its trigger, its functions and the Tracecat equivalent or gap. The step is done when every active playbook has an owner and a documented target, and the team has confirmed the list with the SOC leads.
Map incident fields to Tracecat cases
Translate each incident type into a Tracecat case structure, deciding which fields become case fields, which become structured table records and which are dropped. Record where tasks, notes and attachments will live, and where regulated data such as personal information will be stored and who can read it. The output is a field mapping document approved by the incident response and compliance owners. Confirm in the Tracecat documentation how case fields and tables are modeled before you commit to a structure.
Rewrite functions as custom actions and rebuild playbooks
Port each Python function from QRadar SOAR into a Tracecat custom action, keeping the inputs, outputs and error handling that the playbooks depend on. Rebuild each playbook as a Tracecat workflow with webhook or alert triggers, and store the action code in Git so changes are reviewed. The output is a tested workflow set and a list of functions that could not be ported, each with a decision. Run every workflow against sample alerts in a non-production workspace and keep the test results with the mapping sheet.
Pilot one incident type
Select one low-risk incident type with a known volume and a clear owner, and run it end to end in Tracecat with analysts working the cases. Compare the outcomes with QRadar SOAR for the same alerts, including timestamps, task completion and escalation paths. The output is a pilot report listing defects, missing integrations and analyst feedback, with a go or no-go decision recorded by the SOC manager. Do not expand to other incident types until the pilot defects are fixed or accepted in writing.
Run both platforms in parallel
Send the same alert sources to QRadar SOAR and Tracecat for an agreed period, with analysts working the production cases in QRadar SOAR while Tracecat workflows run in shadow mode or on a separate queue. Reconcile case counts, enrichment results and actions taken each day. The output is a reconciliation log that shows where the two platforms differ and why. Exit the parallel run only when the differences are explained and accepted by the incident response owner.
Cut over alert sources and playbook triggers
Switch each alert source and playbook trigger to Tracecat in the order set in the mapping sheet, updating the SIEM or ticketing connections and disabling the matching QRadar SOAR triggers. Keep a rollback path for each source until its first full working cycle has passed. The output is a cutover runbook with change records, named approvers, rollback steps and the verification performed at each switch. Confirm the new triggers with the owners of the upstream tools before disabling the old ones.
Decommission and archive closed cases
Once no open cases remain in QRadar SOAR and all triggers point to Tracecat, export closed incidents, tasks, notes, attachments and audit logs into an archive that auditors and legal teams can read without the original platform. Confirm with compliance and legal how long the archive must be kept, then shut down the QRadar SOAR instance or VM according to the retention plan. The output is an audit archive with an index, a verification report of record counts, and a signed decommission record. Ask your auditor which evidence formats they accept before you export.

Keeping closed QRadar SOAR cases available for audits

Closed QRadar SOAR incidents, their tasks, notes, attachments and activity history must stay retrievable after cutover, because an auditor or incident reviewer may ask for them long after the playbooks that handled them are gone. Before any cutover date is set, confirm with your auditors which evidence you must retain, in what form, and for how long. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports or attestations, so the retention requirements must come from your auditors and your own policies.

There are two practical options. The first keeps the QRadar SOAR instance running in read-only mode for a defined retention window, with no new incidents, no playbook runs and restricted administrative access. This preserves the original records and audit trail as they were, but it keeps the license, the virtual machine or OpenShift platform and its upgrade cycle alive for as long as the window lasts. The second exports closed records into Tracecat cases or into a separate archive store. Export is cheaper to run over time and fits the new platform, but the export must carry every field, task, note and timestamp that auditors will test, and you must verify it against samples from the source system.

Whichever option you choose, run a test before cutover: pick a set of closed incidents across each incident type, reproduce them from the retained or exported source, and confirm that status changes, owners, timestamps and attachments match. Record who approved the export mapping and keep the export logs. Check that Tracecat's self-hosted deployment, your backup scope and your access controls cover the archive, and confirm which Tracecat features you need for case access and role separation under the paid Enterprise Edition terms described in the Tracecat repository. Ask your auditors to review the test output before you decommission the QRadar SOAR instance.

How the migration changes by playbook count and starting point

A small team with a handful of playbooks and no custom Python functions has the shortest path. Most of the work is re-creating incident types, fields and tasks as Tracecat cases and rebuilding each playbook as a workflow with webhook triggers and prebuilt connectors. The first decision is whether the team will carry over open incidents or only use Tracecat for new cases, because that choice sets how much history must be exported and mapped.

Inventory the playbooks: List each playbook, its trigger, the incident types it runs on and the actions it calls. Retire any that nobody uses.
Check connector coverage: Confirm that each external system your playbooks call has a prebuilt connector or can be reached through a custom action.
Decide on open incidents: Choose between closing them in QRadar SOAR before cutover or migrating them as Tracecat cases with their tasks and notes.
Test with one alert source: Rebuild one high-volume playbook first and run it against a single source before moving the rest.

Before you start, confirm the deployment model you need. Tracecat documents single-host Docker Compose for smaller installs, which should be checked against your own availability needs.

What usually goes wrong in a QRadar SOAR to Tracecat move

Most failed SOAR migrations break at the seams: field mappings, code that quietly relied on the old runtime, and edge cases nobody tested. The cards below cover the risks we see most often when moving QRadar SOAR incidents, tasks and playbooks to Tracecat, and the prevention step for each.

Untested playbook edge cases

QRadar SOAR playbooks often handle rare branches, such as a failed enrichment, a task reassigned mid-run or an incident closed while an action is pending. These paths rarely run in daily use, so they are easy to miss when rebuilding. Build a test matrix from the last year of closed incidents and replay representative cases against each Tracecat workflow before cutover. Confirm how Tracecat handles retries and failed actions in the workflow documentation.

Lost field mappings

Custom incident fields, data tables and task types in QRadar SOAR often carry business meaning that no one has written down. When they are mapped to Tracecat case fields by hand, values can be truncated, typed differently or dropped. Export the field definitions and sample records first, then sign off each mapping with the analysts who use it. Keep a mapping table in version control so changes are reviewed.

Python functions tied to QRadar runtime

Custom QRadar functions may call SOAR-specific objects, rely on its incident context or assume a particular Python environment. These calls do not exist in Tracecat, so the code fails or behaves differently after a straight port. Inventory every function, list the runtime objects it touches, and rewrite each as a Tracecat custom action with its own tests. Treat any function you cannot explain as a blocker until an engineer has reviewed it.

Alert duplication during parallel run

Running QRadar SOAR and Tracecat side by side means the same alert can open a case in both systems. Analysts then work duplicates, and metrics such as mean time to respond become unreliable. Decide which system owns each alert source for each phase, and add a shared identifier to every case so duplicates can be found. Retire each source from the old system only after the new workflow has handled it correctly for a set review period agreed by the SOC.

Missing audit history

Closed QRadar SOAR incidents are part of your evidence trail, and a migration that imports only open cases can break audit questions about past decisions. Export closed incidents, notes, tasks and timestamps in a readable format and store them in an archive your auditors can access. Decide with compliance owners how long the archive must be kept, and test a sample retrieval before the old system is decommissioned.

Enterprise-only features assumed included

Some capabilities teams expect, such as single sign-on, multi-tenant workspace management and Git version control integration, are listed as Enterprise features in Tracecat's repository and documentation. If your QRadar SOAR setup depends on them, the open-source edition may not cover your needs. Compare your current access and change-control requirements with the Tracecat feature documentation, confirm licensing with Tracecat in writing, and include any paid features in the cost comparison before you commit.

What drives migration cost and duration

This table lists the main factors that change the effort of moving QRadar SOAR content to Tracecat, with why each matters and how to keep it under control. Use it to scope a written quote, since the same driver can add work in one column and remove it in another.

Driver	Why it changes effort	How to keep it down	What to ask for in a quote
Number of playbooks	Each QRadar SOAR playbook is rebuilt as a Tracecat workflow, so the count sets the bulk of the rebuild and test work.	Retire unused or duplicate playbooks before migration and group similar ones into shared sub-workflows.	Itemized list of playbooks in scope, with a retire or rebuild decision for each.
Custom Python functions	Functions run inside QRadar SOAR's runtime and must be rewritten as Tracecat custom actions, with their dependencies and secrets reviewed.	Inventory every function, remove dead code, and prioritize functions that call external systems.	Per-function estimate covering rewrite, dependency review and testing in a Tracecat sandbox.
Third-party integrations	Each integration needs a connector, a custom action or an API call, and each one needs credentials and error handling checked.	Reuse the prebuilt connectors where they match, and standardize on a small set of API patterns.	Named list of integrations, the Tracecat route for each, and who owns the test accounts.
Incident type and field complexity	Mapping QRadar SOAR incident types, custom fields and tasks to Tracecat cases and structured tables requires decisions about each field's meaning.	Simplify field sets, agree a field dictionary with the SOC, and drop fields nobody queries.	Field mapping workbook and the number of case templates included in scope.
Historical data to retain	Closed incidents, attachments and notes must stay retrievable for audits, which affects export tooling, storage and verification work.	Set a retention rule per incident class and archive older cases in a read-only export before cutover.	Record counts, attachment volume, export format and the verification method used to prove completeness.
SSO and access control requirements	Single sign-on and multi-tenant workspace management are listed as Enterprise Edition features, so SSO needs a paid license and extra configuration.	Decide early whether SSO is mandatory, and separate workspace roles from identity provider groups.	Confirm the Enterprise Edition scope in writing with the Tracecat vendor and the identity provider integration work.
Deployment target	Docker Compose on a single host is simpler than Kubernetes with Helm, and an air-gapped Kubernetes install adds image mirroring and offline update steps.	Match the target to the SOC's availability and change-control needs, and document the upgrade path for the chosen method.	Target architecture, environments (test, production), and who operates Temporal, PostgreSQL and object storage.
Testing and cutover	Each rebuilt workflow needs tests against realistic alert payloads, and parallel running adds time before the old platform is switched off.	Replay recent alerts through both platforms and sign off workflows one by one.	Test plan, acceptance criteria per workflow, and the parallel-run period agreed in advance.

Questions teams ask before moving from QRadar SOAR to Tracecat

How much effort does a migration from QRadar SOAR to Tracecat take?

The effort depends mostly on how much automation you have built in QRadar SOAR, not on how many incidents you hold. Playbooks, custom Python functions, incident type and field customizations, and integrations with external tools each take separate work. A team with a short list of playbooks and a few functions has a much smaller job than a team with years of custom scripts tied to several ticketing and threat intelligence systems. The main cost components are the engineering time to inventory and rebuild automation, the platform work to deploy and harden Tracecat in your environment, and the testing needed before cutover. Ask any provider to break the estimate into those components and to state which items assume your existing exports are complete.

How long does a QRadar SOAR to Tracecat migration run?

The schedule is set by the written scope, and the most useful timeline is one tied to named deliverables. Duration depends on the volume of playbooks and functions to rebuild, the number of integrations that need custom actions, how many environments you run, and whether a parallel period is required while SOC analysts validate results. Change approval cycles and access requests in your own organization often take longer than the technical work. Ask for milestones that cover inventory, a pilot playbook, a parallel run, cutover and a post-cutover review, and confirm who signs off each one. DeployOpen plans and delivers most engagements as fixed-scope work, with scope, deliverables and timelines agreed in writing before work starts.

What must our team provide for the migration?

Your team supplies the knowledge and access that no migration plan can replace. Expect to provide:

An export or list of QRadar SOAR playbooks, custom functions, incident types, fields, roles and integration configurations, along with the owners who understand each one.
Access to the QRadar SOAR instance, the target infrastructure and the external tools that playbooks call, such as ticketing, identity and endpoint platforms.
Named SOC and IR decision-makers who can approve how cases, tasks and severity levels will map to Tracecat cases.
Sign-off on test cases, because only your analysts know which outcomes are correct for real incident types.

If these inputs arrive late, schedule and cost both move. Confirm the exact list in your written scope before work begins.

Can our own team migrate QRadar SOAR playbooks to Tracecat without a partner?

Yes, a capable internal team can do the work, provided it has people who can read the existing Python functions and who can operate the platform after handover. Tracecat is built on Python with FastAPI, a Next.js frontend, Temporal for durable workflow execution, PostgreSQL for data and an S3-compatible object store, so the work touches application code, workflow logic and infrastructure. Your team must also own upgrades, backups and monitoring of those components. The question to answer honestly is capacity: who will rewrite each playbook, who will test it against real alerts, and who will run the platform once the project team moves on. A partner is most useful for the parts that are hardest to staff internally, such as platform hardening, evidence preparation for compliance assessments and testing. DeployOpen does not issue audit reports or certifications, so independent auditors still judge the outcome.

What happens to closed QRadar SOAR cases after cutover?

Closed cases should remain available in a read-only form for as long as your retention policy and audit obligations require, and this should be decided before cutover, not after. Moving every historical case into Tracecat is one option, but importing closed records can be costly and may not preserve every field, note and attachment. Many teams keep QRadar SOAR available in read-only mode for a defined period, export case data in a documented format, and store attachments and audit trails in a location the auditors can reach. Ask the provider to show, in writing, how each case field, task, note and timestamp will be exported or preserved, how access will be controlled, and who approves retention periods. Confirm the export capabilities of your specific QRadar SOAR version with IBM, because those depend on your deployment.

Which Tracecat features need the Enterprise Edition?

Tracecat is licensed under AGPL-3.0, but code in its enterprise package directory and its enterprise feature gates sits under a separate paid Enterprise Edition license. According to the Tracecat repository, multi-tenant workspace management and Git version control integration are Enterprise features. The Tracecat documentation also describes authentication and single sign-on capabilities as enterprise features. Automation features such as webhook triggers, case management, structured tables, custom AI agents and custom actions are listed in the documentation without that enterprise label, so confirm the current feature matrix before you design around any of them. If your SOC needs single sign-on to meet access policy, or needs separate workspaces for business units, budget for the Enterprise Edition from the start and ask for its license terms in writing.

Can Tracecat run inside our data center or an air-gapped network?

Yes, the Tracecat documentation describes several self-hosted deployment paths. These include 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. Choose the path that matches your operations model and your data residency rules, then confirm that the components it needs, including PostgreSQL, the object store and Temporal, meet your hardening baseline. Air-gapped installs also require you to plan how connectors, updates and any external threat intelligence feeds reach the environment. Review the current deployment guide in the Tracecat documentation before the scope is written, since deployment details change between releases.

How DeployOpen scopes and runs a QRadar SOAR to Tracecat migration

DeployOpen plans, implements, customizes, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For this migration, we start from a written scope that maps your QRadar SOAR incident types, playbooks and custom functions to Tracecat cases, workflows and custom actions, then build and document the result in your environment.

How we scope

Inventory of QRadar SOAR incident types, fields, tasks, playbooks and custom Python functions agreed in writing before work starts
Decisions on which open cases move to Tracecat, which close in QRadar, and how closed records stay searchable for audits
Deployment target chosen with you: Docker Compose on a single host, Kubernetes with Helm, or air-gapped Kubernetes

How we build

Field and incident type mapping to Tracecat cases, with structured tables for any data that has no direct equivalent
Python functions rewritten as Tracecat custom actions, tested against sample incidents in a non-production workspace
Playbooks rebuilt as Tracecat workflows with webhook triggers, connected to your alert sources and tested end to end

How we hand over

Written documentation covering the mapping, workflow inventory, custom actions, deployment and backup procedures
Evidence of testing and of closed-case retention prepared for your compliance and audit reviewers
Walkthrough sessions so your analysts and platform engineers can maintain workflows after cutover

How we support

Ongoing support, upgrades and continuous testing available as a retainer after handover
Upgrade planning for each Tracecat release, including checks of enterprise features your team relies on before any change
Confirmation with your auditors or certification bodies of any assurance requirement, since DeployOpen prepares evidence but does not issue audit reports

Migrate from IBM QRadar SOAR to Tracecat