Open-source alternative to Cortex XSOAR case management

Which open-source option replaces XSOAR case management?

A SOC that runs XSOAR incidents, layouts and the war room as its case system needs a replacement that tracks analyst work, not only automated actions. Tracecat has built-in case management, while Shuffle does not, so Shuffle needs a separate case system paired with it. The core decision is whether cases stay inside the automation tool or move to a dedicated system. This page covers Tracecat, Shuffle and the coexistence options, so you can match each one to how your analysts work today.

Start by inventorying what XSOAR actually does for analysts. Map each incident type to its fields, its layout, the SLA clock if one exists, and the notes that analysts write in the war room. Then check whether the target platform can hold each of those elements. Tracecat's case management documentation describes what its cases cover, which you should compare field by field against your layouts. For Shuffle, confirm in the Shuffle configuration docs and with the vendor how it stores analyst context, since its incident handling does not replace a case workflow. Any SLA tracking, approval steps or audit trail you depend on must be confirmed on the target, not assumed.

The second decision is operational. Running Tracecat keeps workflows and cases in one tool with one database and one set of roles. Pairing Shuffle with a separate case system adds an integration to build, test and maintain, along with a second place where access and retention rules must match. Ask any implementation partner for a written scope that names the case fields, the sync direction, who owns each data store and how historical XSOAR incidents are archived. A short pilot on one incident type, run alongside XSOAR until response times and note quality match, reduces the risk that analyst knowledge is lost during the change.

How XSOAR case features map to Tracecat and Shuffle

This table maps each XSOAR case feature to its nearest equivalent in Tracecat cases and Shuffle workflow executions, plus an external case system where neither covers it. Read the coverage notes as a checklist of what you must build, configure or confirm in vendor documentation before cutover. The main takeaway is that Tracecat ships case management in the same tool as its workflows, while Shuffle handles execution history and needs a case system paired with it for analyst work.

Capability	Tracecat	Shuffle	External case system
Incident types and custom fields	Case management is built in, so you define case fields in the platform. Confirm how field schemas map from your XSOAR incident types before migrating.	No built-in incident types. Workflow variables and execution data hold the context, so typed incident records need a separate home.	Typed records with required fields and validation. Best fit if your analysts rely on strict incident type schemas.
Layouts and analyst views	Confirm whether case views can be tailored by role or incident type. Do not assume XSOAR layout parity.	No layout engine. Analysts work from workflow execution views, so plan for a separate interface for case work.	Customizable forms and views per record type, depending on the product chosen. Confirm rendering and permissions.
SLA timers and escalation	Confirm in the Tracecat documentation whether SLA timers exist natively. If not, build timers with scheduled workflows and notify through its actions.	No SLA timer feature identified in the supplied documentation. Scheduled workflows can approximate timers, but confirm with Shuffle.	Often includes SLA tracking and breach alerts. Verify the SLA model against your existing XSOAR timers.
War room and real-time collaboration	Cases provide a single record for notes and actions. Confirm whether live multi-analyst chat or command execution in the case is offered, as XSOAR's war room has no direct equivalent in the supplied facts.	No war room. Analysts see execution results and can re-run workflows, but there is no shared incident channel.	Some products offer comment threads and chat integration. Confirm real-time features and their logging.
Analyst notes and audit trail	Confirm how notes are versioned and whether edits are logged with user identity. Required for evidence review.	Execution history is recorded per run in OpenSearch. Analyst free-text notes are not a native case artifact, so store them in a linked record.	Immutable comment history with author and timestamp is common. Confirm the audit log meets your assessor's expectations.
Evidence attachments	Object storage supports file handling, but confirm attachment size limits, retention and whether attachments are linked to cases in the UI.	Files can pass through workflows, but there is no case-level evidence repository. Plan a secure store with access controls.	Attachments are typically stored per record with access controls. Confirm chain-of-custody needs with your legal or forensic team.
Incident-to-playbook linkage	Workflows can be triggered from case events and write results back to the case. Test the round trip for each playbook you migrate.	Workflows run per execution with a trigger. Linking an execution back to a case requires an explicit identifier passed through the workflow.	Usually links to external automation via API or webhooks. Confirm bidirectional sync.
Reporting and metrics	Confirm which reports exist for case volume, handling time and ownership. Export raw data if built-in reporting is limited.	Execution data is queryable in OpenSearch, which supports custom dashboards. Metrics need to be defined by your team.	Often includes prebuilt reports. Ask for the list of metrics and export options in the quote.

When Tracecat, Shuffle or a separate case system fits

XSOAR combines incidents, layouts, the war room and playbooks in one product, so replacing it means deciding where each of those lives. The three options below differ mainly in whether cases stay inside the automation tool, sit beside it, or move to a system your organization already governs.

Tracecat for workflows and cases together

Tracecat ships workflow automation, webhook triggers and case management in one self-hosted tool under AGPL-3.0, so incident records and the playbooks that act on them share one data store. Check the single-host Docker Compose, Kubernetes Helm and air-gapped Kubernetes options against your hosting rules. Confirm which features you need sit in the open-source edition, because SSO and multi-tenant workspace management are Enterprise Edition items under a separate paid license.

Shuffle with a separate case system

Shuffle runs the automation and has no built-in incident layouts or war room, so case records, SLAs and analyst notes need a home elsewhere. Its architecture is a frontend, a Go backend, an OpenSearch document database and Orborus runtime nodes, which means OpenSearch sizing, Orborus redundancy and backups are your operating work. Shuffle's app-run licensing and open-source edition are a good fit when that case system is already in place.

External ticketing or case platform

Where SOC cases must follow a retention schedule, legal hold process or an existing ITSM queue, a separate case platform can hold the system of record while automation runs elsewhere. Map each XSOAR incident type and field to that platform's record model before you choose, and confirm retention and audit log export with its vendor. Expect an integration to maintain on both sides, with two places to review when an alert changes state.

Shuffle SSO on OpenID Connect

Shuffle added SAML in version 0.9.16 and OpenID Connect in 1.0.0, both available on-premises, with per-tenant SSO enforcement. Shuffle is moving Cloud users from SAML to OpenID Connect, so a new deployment should start on OpenID Connect. Check that your identity provider meets your analyst access and logging needs before you rely on it for case access control.

Protecting the Shuffle encryption key

Shuffle encrypts saved app credentials and API keys in OpenSearch with AES-256 using the SHUFFLE_ENCRYPTION_MODIFIER secret. Losing or changing that value breaks every saved app authentication, so it must be backed up with the same care as the database. Include it in your migration runbook and in your key custody process before you connect any case or ticketing app.

How deployment environment changes the case decision

A single host running Docker Compose suits a small team evaluating both options or running a limited pilot. Shuffle's install guide lists Docker and Kubernetes as installation paths, notes that the default Docker Compose setup is not scalable without changes, and states a minimum of 4 GB of RAM. Tracecat also documents Docker Compose on a single host. On this layout, workflow data, analyst notes and case records share one machine, so the case decision mostly depends on whether that host can hold the data you intend to keep.

Case store placement: Shuffle keeps its data in OpenSearch on the same host, while Tracecat uses PostgreSQL and an S3-compatible object store, so both need backup planning from the first day.
Single point of failure: One host means an outage stops automation and case work together. Confirm with each vendor whether any high-availability pattern is supported for this layout.
Shuffle case handling: Shuffle has no built-in incident layouts or war room, so analyst cases would sit in a separate ticketing system on the same network.
Tracecat case handling: Tracecat includes case management with its workflow engine, which keeps the number of moving parts lower on one host.
Sizing: Treat 4 GB as a minimum and size RAM, disk and snapshot capacity against your expected case volume.

Confirm that backup and restore for the host have been tested before any case data moves in.

Mapping incident types, fields and SLAs without losing analyst context

Start with an inventory, not a build. Export the XSOAR incident types, custom incident fields, layouts and the SLA definitions attached to them, then group them by what an analyst actually does with each one. Incident types that share the same fields and the same response steps are candidates for one case template. Types that need different required fields or different approval paths need their own template. Fields that feed reporting or correlation, such as severity, data classification or affected business unit, should become typed fields in the case template or columns in a structured table, so they can be filtered and counted later. Fields that only ever held free text can usually stay as notes. Tracecat's case management documentation describes how cases and their fields are modeled, and that is the reference to check against your inventory before you map anything.

Treat SLAs and layouts as things to rebuild and verify, never as things that carry over automatically. XSOAR SLA timers are tied to its incident model, so the timer logic, start events, pause conditions and breach actions must be redefined in the new system and tested against real past incidents. Confirm in the target product whether it offers native SLA timers or whether you need a scheduled workflow that checks elapsed time and raises escalations. Layouts are presentation: the sections, tabs and field visibility that analysts see must be reproduced and reviewed by the analysts who use them, because a missing field on a tab is easy to overlook in testing. Analyst notes need a rule too. Decide which notes are case comments, which are evidence, and which are scratch work, and migrate them with timestamps and author identities intact.

War room transcripts are the decision most teams postpone and then regret. The war room holds command output, analyst chat and automation results in one timeline, and a regulator or outside counsel may later ask for exactly that record. Decide, with your legal, compliance and incident response leads, whether transcripts are archived as evidence in read-only form, exported into the case as attachments, or retained only in the original XSOAR system for a defined period. Write that decision down with the retention period your policy requires, and confirm that the archive is complete and tamper-evident before the XSOAR tenant is switched off. Ask the implementation partner to show, on a sample incident, that the case timeline, SLA history and archived transcript all reconcile.

Moving open cases and closed history out of XSOAR

This sequence moves open incidents into a new case system first, archives closed history for lookup, and ends with intake switched over once analysts handle work the same way in both tools. It is written for SOCs that use XSOAR incidents, layouts and the war room as their case record.

Export custom content from XSOAR
The SOC engineering lead exports the custom content that defines how incidents are shaped and handled, including layouts, field definitions and playbooks, using the XSOAR export path in Settings, Server Settings, Custom content. The sibling page on exporting XSOAR data covers the UI export, the demisto-sdk download command and the formats each item comes in. This step is done when every custom item is saved in a versioned repository and someone other than the exporter can list what is in it.
Inventory incident types and fields
Working with analysts, list every incident type in use, the fields each type carries, which fields are mandatory at each stage, and which ones feed SLA timers or dashboards. Record where each field is populated: by an integration, a playbook, or an analyst typing into the layout. Note the war room content that holds real decisions, since that is analyst history rather than structured data. This step is done when the inventory is signed off by the SOC lead and every field has an owner and a source.
Build the target case schema
Map each XSOAR incident type and field to a case template in the target system. In Tracecat, this means its case management and structured tables. In Shuffle, Shuffle has no built-in incident layouts or war room, so the team must decide what stores incident records and analyst notes, such as a ticketing or case tool paired with Shuffle. Decide how SLA clocks, severity and closure reasons are represented. This step is done when a test case created from a sample XSOAR incident holds every mapped field and the SOC lead accepts the mapping.
Migrate open incidents first
Copy open incidents into the new case system with their status, owner, timestamps and analyst notes, while keeping the XSOAR incident ID as a cross-reference. Migrate in a small batch first and have analysts confirm that each case shows the same state as it did in XSOAR. Open cases are migrated before history because they are the ones analysts must act on during cutover. This step is done when a reconciliation report shows matching counts and fields for the open batch and analysts sign off on a sample of cases.
Archive closed history
Export closed incidents with their notes, attachments references and closure data into a read-only archive that analysts and auditors can search. Decide whether the archive lives in the new case system, in a separate store, or in the XSOAR server kept under a retention plan. Confirm retention requirements with your compliance team before deleting anything from XSOAR. This step is done when a sampled set of closed incidents can be found and read from the archive and the retention decision is recorded in writing.
Switch intake to the new case system
Repoint the alert and SIEM triggers that create incidents so that new alerts open cases in the target system instead of XSOAR. Confirm which integrations, webhooks or scheduled jobs create records and update each one. Keep XSOAR able to receive alerts for a short overlap only if your playbooks still depend on it. This step is done when a test alert from each source creates a case in the new system and no new incidents appear in XSOAR.
Run both until analyst handling matches
Run XSOAR and the new system side by side for a defined overlap that the SOC lead agrees in writing, comparing time to acknowledge, time to close and the rate of missing fields for each incident type. Fix mapping gaps as analysts find them and update the schema. Retire XSOAR incident handling only when the comparison shows the new process meets the agreed targets. This step is done when the SOC lead signs off on the comparison and XSOAR is set to read-only for case work.

Running cases alongside the rest of the XSOAR estate

Few SOCs can switch case handling in one cutover, so the open-source case system usually runs next to XSOAR for a period. The cards below cover which system owns in-flight incidents, how case status reaches the SIEM and ticketing tools, and where threat intelligence lives, with the integration risk each one carries.

Keep XSOAR as record for open incidents

Leave incidents that already exist in XSOAR in XSOAR until they close, and route only new alerts to the open-source case system. The main risk is a split record, where an analyst updates a case in one tool while the audit trail sits in the other. Confirm how your routing rule marks an alert as claimed by one system, and whether a closed XSOAR incident can be reopened by a webhook from the other side.

Map incident fields to case fields

XSOAR incident types, custom fields and layouts do not carry over as-is, so each field needs a named target in the new case model. Severity, owner, SLA timers and analyst notes are the usual sources of mismatch, because XSOAR stores some of them as incident fields and others in the war room. Confirm which fields your reporting and SLA dashboards read, and test that they still populate after the mapping.

Send case status to the SIEM

Detection rules and dashboards in your SIEM often read incident status to suppress duplicates or close alerts. When the case moves, that status has to be written back by a connector or API call, or the SIEM keeps showing open work that analysts already closed. Confirm whether the SIEM accepts status updates through its API, and how it handles a case identifier that changes after migration.

Sync case state with ticketing

Where a ticketing or ITSM tool records change approvals or customer-facing incidents, a second status flow runs in parallel. Two-way sync is where duplicate tickets and stale states usually appear. Decide which system is authoritative for each state, and confirm the ticketing API supports the webhooks or polling interval your handoff needs.

Keep threat intelligence in its own platform

Indicator scoring and feed ingestion belong in a threat intelligence platform, not in the case tool. Cases should reference indicators by identifier and pull their scores when needed. Confirm how the case system stores that reference, and whether indicator changes in the threat platform can update an open case without overwriting analyst edits. See the separate threat intelligence page for the platform options.

Protect credentials used for the bridge

Every integration between XSOAR, the case system, the SIEM and ticketing needs API credentials with scoped permissions. Shuffle stores saved app credentials encrypted in OpenSearch under a single secret, and losing that secret breaks every saved authentication. Confirm where each bridge credential lives, who rotates it, and how you restore it if the encryption secret is lost.

What does moving XSOAR case management cost and require?

What drives the effort of moving XSOAR case management to another system?

The effort follows the size and shape of your case model. The main drivers are the number of incident types, the number of custom fields on each layout, how many SLA rules and escalation paths you run, how many integrations feed or act on incidents, and how long you must keep closed cases. Each incident type with its own layout, field set and playbook is a separate piece of design and testing. Shuffle has no built-in incident layouts or war room, so a team moving to it must also choose and build a case store. Tracecat ships case management, so the work shifts toward mapping fields and rules into cases rather than building the store itself. Inventory these counts before asking for a scope.

Can our SOC move XSOAR cases without outside help?

A team with strong automation skills and time for a parallel run can do much of this internally, especially if the case volume is modest and the incident types are few. Work that usually benefits from outside help includes designing the case data model, rebuilding integrations as OpenAPI-based Shuffle apps or Python apps, hardening the deployment, setting up SSO and secrets handling, and producing evidence for an assessment. Shuffle documents its own deployment and high availability options, and Tracecat documents Docker Compose, Kubernetes and an air-gapped Kubernetes path, so the platform work is well documented. The question is whether your staff have the hours to carry it alongside live operations.

How long does a case management migration take?

Duration depends on scope, and no fixed figure applies to every SOC. A small set of incident types with few integrations can move far faster than a multi-region SOC with many custom layouts, SLA rules and retention commitments. Plan in phases: inventory and mapping, building the case model in the new system, running both platforms side by side for each use case, then cutting over and retiring XSOAR incident handling. Ask any provider to break the timeline into these phases with written milestones and an agreed end point for the parallel run. DeployOpen agrees scope, deliverables and timelines in writing before work starts.

What must our team provide before a migration starts?

The team must supply analyst time, a current export of incident types, layouts, fields, SLA definitions and playbooks, and realistic test alerts that reflect real incident shapes. Analysts need to review mapped fields and confirm that notes, owners and timestamps carry over correctly. Someone with authority must approve data retention rules, because closed cases and analyst notes often contain personal or regulated data that must be kept, minimized or deleted on a defined schedule. Export of custom content from XSOAR is documented in Cortex XSOAR 8, so start there. Also name an owner for access control, since the new case system will need its own roles.

What does a self-hosted case system cost after launch?

The recurring costs are the parts you run yourself: compute and storage for the platform, database and object store backups, OpenSearch storage for Shuffle or PostgreSQL and object storage for Tracecat, certificate and secrets management, monitoring, and upgrades. Shuffle's configuration docs recommend an OpenSearch cluster, shared cache and multiple Orborus nodes for high availability, so those recur as infrastructure cost. Upgrades and security patches need scheduled test windows. Support is either an internal rota or a retainer, and the choice drives how quickly a failure is fixed. Shuffle's licensing is based on app runs for its paid tiers, and Tracecat's SSO and multi-tenancy sit in its Enterprise Edition, so check whether those features are in your plan.

What should we ask for in a written quote for this work?

Ask for a scope that names each incident type, integration, field mapping, SLA rule and playbook in scope, and states what is excluded. Request the deliverables in writing, including the case data model, mapping document, test evidence, runbooks and handover material. Require the parallel-run period, the cutover criteria and the rollback plan. Ask who owns backups, upgrades and monitoring after go-live, and whether that is a separate retainer. Confirm which licence tier of Shuffle or Tracecat is assumed, and which features depend on the Enterprise Edition. Ask how retention and deletion of case data will be configured and who signs off. Finally, confirm which compliance outputs are prepared and that independent auditors, not the implementer, issue any reports.

Do we still need XSOAR-style case management if we keep the automation in Shuffle?

Yes, if analysts need one place to track ownership, status, notes and SLA clocks. Shuffle provides workflow execution and an OpenSearch-backed document store, but it does not provide the incident layouts or war room you use in XSOAR, so the case record must live somewhere. Some teams keep cases in a separate ticketing or case system and let Shuffle write updates to it. Others choose Tracecat, which includes case management alongside workflows. Decide this first, because it sets the data model, the integration design and the retention rules. A short illustrative example: a team that keeps cases in an existing ticketing tool would map XSOAR fields to that tool's fields and have Shuffle post status changes through its API.

What risks should a security lead review before committing to this move?

The main risks are losing analyst notes or audit trails during export, breaking SLA timers, mis-mapping incident fields so that severity or ownership shows the wrong value, and losing saved integration credentials. Shuffle encrypts saved app credentials with a secret named SHUFFLE_ENCRYPTION_MODIFIER and warns that losing or changing it breaks all saved app authentications, so back it up securely from day one. Also check that JavaScript integrations and logic tied to XSOAR's runtime are rebuilt rather than assumed to transfer. Run both systems side by side for each use case until response times and case completeness match what you had before cutover.

What to confirm before choosing a case system

Before you pick a case system, confirm that Tracecat's case management covers the fields your analysts and auditors actually use. Pull a sample of XSOAR incident types and map each custom field, severity scale, SLA timer, owner assignment and closure reason to a Tracecat case field or a structured table. Then build one representative case end to end and export it to check that reporting can answer your questions, such as mean time to acknowledge by incident type. Tracecat's documentation describes case management as a core feature, but the field model, the reporting outputs and any gaps are for your team to verify against your own incident catalog, not for a vendor summary to settle.

Next, decide how Shuffle will talk to the case system you keep. Shuffle has no built-in incident layouts or war room, so an integration has to create, update and close cases through an API call. Confirm which case system exposes the endpoints you need, then check whether an app for it already exists or must be built from an OpenAPI specification in the App Creator or in Python with the app SDK. Test the write path with a non-production case, including attachments and analyst notes, because a failed update in the middle of a playbook is harder to trace than a failed HTTP call.

Identity and retention decide the edition and the evidence model. Tracecat documents single sign-on and multi-tenant workspace management as Enterprise features, so if your analysts must sign in through your identity provider or you separate client or business-unit workspaces, price the Enterprise Edition before you design around the open-source build. Shuffle's SAML and OpenID Connect support is available on premises, so confirm the protocol your identity provider uses. Finally, write down retention periods, legal hold rules and who may delete or edit closed cases, and confirm with your compliance lead and your vendor that deleted or purged records and their audit trail meet those rules. Losing SHUFFLE_ENCRYPTION_MODIFIER or storing case data outside your backup scope creates the same kind of evidence gap, so keep both in your review.

How DeployOpen scopes and delivers a case management move

DeployOpen plans, implements, integrates, documents and supports self-hosted open-source platforms inside your own infrastructure. For case management, that means agreeing in writing which XSOAR incident types, fields, SLAs and analyst notes move, which system holds them, and how the SOC runs while both sides operate.

How we scope

Inventory XSOAR incident types, layouts, fields and the war room usage analysts rely on today.
Decide in writing whether cases stay in Shuffle or move to Tracecat case management, or to a separate system.
Agree which SLAs, analyst notes and attachments must carry over, and which can be retired with the old tool.

How we build

Map each incident type to a case template, with fields, statuses and ownership rules defined before any build starts.
Rebuild the playbook steps that open, update and close cases, and test them against sample incidents from your own environment.
Deploy the chosen platform on your Docker, Kubernetes or air-gapped setup, and configure SSO and secrets handling as agreed.

How we hand over

Deliver the field mapping, runbooks, configuration records and test results as documentation your team can maintain.
Walk analysts through the case queue, notes and escalation paths, using your own incident examples.
Record the parallel-run period and the cutover criteria agreed with your SOC lead before XSOAR is switched off.

How we support

Engagements are fixed-scope, so scope, deliverables and timelines are agreed in writing before work starts.
Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Ask any provider, including us, to confirm how case history and audit trails are exported if you later change tools.