Migrate from FortiSOAR to Tracecat: what the move involves
A SOC lead facing a FortiSOAR renewal, licensing tied to FortiGuard, a data residency requirement or growing lock-in should know this first: moving to Tracecat is a staged rebuild of playbooks, case records and integrations, not a file import. Each FortiSOAR playbook has to be re-expressed as a Tracecat workflow with webhook triggers, and each connector has to be replaced by a Tracecat action or a custom action synced from Git. Case history and structured records are usually moved selectively, because Tracecat's case management and tables model data differently from FortiSOAR modules. The work is typically done by internal SOC engineers who already know the playbooks, supported by a platform team that owns the Docker Compose, Kubernetes or air-gapped deployment, or by an implementation partner working to a written scope. Effort depends on how many playbooks and custom connectors you have, and the reader should confirm that inventory before estimating anything.
Tracecat is licensed under AGPL-3.0, and the code in its enterprise packages sits under a separate paid Enterprise Edition license. Single sign-on and multi-tenant workspace management are named as enterprise features, so if your current FortiSOAR setup depends on SSO or separate tenants for an MSSP model, confirm those requirements against the Enterprise Edition terms before you plan the cutover. Ask the vendor which features are in the community edition for your intended deployment, and check the current release notes in the Tracecat GitHub releases page before you pin a version. Treat the largest risks as identity integration, alert source switchover and the rewrite of expression logic, and run both platforms in parallel until each alert source is confirmed on Tracecat.
Which FortiSOAR capabilities map to Tracecat, and which need rework
This table compares FortiSOAR building blocks with their Tracecat equivalents and marks each row as clean, needs rework or gap. Use it to scope the migration before inventorying your playbooks. Rows marked needs rework or gap are where most of the effort will sit, and connector coverage should be confirmed against Tracecat's prebuilt connector list and documentation before you commit.
| Capability | FortiSOAR | Tracecat | Status |
|---|---|---|---|
| Playbooks as workflows | Playbooks built in the visual designer with steps, conditions and loops | Workflows built from webhook or schedule triggers and chained actions | Needs rework: every step is rebuilt, not imported |
| Modules and record types | Custom and built-in modules with fields, relationships and picklists | Structured tables for custom records; cases for incident records | Needs rework: map each module to a table or case field set |
| Incident and case handling | Incident records with tasks, comments and attachments | Case management with fields, status and activity history | Clean for core case workflow; confirm attachment and task handling |
| Connectors | Vendor connectors installed from the FortiSOAR catalog | More than 100 prebuilt connectors per the Tracecat repository, plus custom actions | Needs rework: confirm each connector you use appears in the prebuilt list |
| Jinja-style expressions | Template expressions inside playbook step inputs | Tracecat expression syntax in workflow actions, not a direct copy | Needs rework: translate and test each expression against sample data |
| Custom actions and code | Custom connector and script code stored in the appliance | Custom actions synced from a Git repository | Clean once code is moved into Git; review dependencies |
| Roles and access control | Role-based permissions set per module and team | Workspace roles; confirm the granularity you need in the documentation | Needs rework: rebuild roles and test each permission |
| Multi-tenancy | Tenant separation for managed service use | Multi-tenant workspace management is an Enterprise feature | Gap on the community edition: confirm the paid edition covers your model |
| Single sign-on | Built-in and external authentication options | Authentication and SSO are documented as Enterprise features | Gap on the community edition: plan access for existing identity provider |
| Audit and history of runs | Playbook execution history and record audit trail | Workflow run history and case activity; confirm retention settings | Needs rework: decide what evidence you must keep before cutover |
What data and integrations move, and what you rebuild by hand
The move from FortiSOAR to Tracecat splits into three groups: what the documented export carries, what you must map into Tracecat's data model, and what never transfers and has to be recreated. Treat each group as its own inventory item so nothing is assumed to come across automatically.
Playbooks, modules and connector settings
The FortiSOAR Configuration Export wizard is the documented export path for playbooks, modules and connector settings. Use its output as the starting inventory: list every playbook, every module that playbooks call, and every connector configuration in use. Check each exported item against the alert sources and response actions it supports today, because the export describes what FortiSOAR does, not what Tracecat will need to do. Export output is the inventory, not the finished workflow.
Incident records as structured data
Incident records do not move as FortiSOAR objects. Export them as structured data, then map fields to Tracecat cases and to structured tables for reference data such as asset lists or enrichment results. Decide early which FortiSOAR fields become case fields, which become table rows, and which are dropped. Confirm with your analysts that closed incidents need to be searchable in Tracecat before you plan the import, since the mapping determines what history looks like afterward.
Credentials and connector secrets
Credentials stored in FortiSOAR do not transfer with the configuration export. Every connector that Tracecat will call needs its secret recreated in Tracecat's secrets handling, with the least privilege scope the target system allows. Build a register of each credential, its owner, and its rotation schedule before cutover. Ask whether any credential was shared across connectors, because shared credentials are easy to miss and hard to revoke later.
FortiGuard-tied licensing
FortiSOAR licensing is tied to FortiGuard entitlements, and those entitlements do not carry into Tracecat. Your Tracecat deployment has its own license model, and the Enterprise Edition features, including single sign-on and multi-tenant workspaces, sit under a separate paid license. Confirm with the vendor which edition covers your required features, and document the FortiSOAR entitlements you are retiring so the offboarding evidence is complete.
Custom actions synced from Git
Custom actions you built for FortiSOAR must be rewritten for Tracecat, then stored in a Git repository that Tracecat syncs from. Version control gives you a reviewable history of each action and a clear rollback path. Git version control integration is listed as an Enterprise feature, so confirm whether your edition includes it before you design the repository workflow. Test each synced action against a non-production target before enabling it on live alerts.
Playbook logic and expressions
FortiSOAR playbook steps and their Jinja-style expressions must be rewritten as Tracecat workflows and actions, not copied. Expect differences in how conditions, loops and data references are written, and test every branch with representative alert data. Keep the original playbook as a reference until each rewritten workflow has produced matching outcomes in a parallel run. Log which playbooks were rebuilt, which were retired, and which need owner sign-off.
How the migration differs by SOC size and starting point
A small SOC with a short list of playbooks usually has a migration that is mostly a rebuild. The inventory is short enough to review by hand, and most playbooks map to a handful of Tracecat workflows triggered by webhooks, with alerts and investigations recorded as Tracecat cases. Because the record volume is modest, the main question is whether the team wants to rewrite each playbook or simplify it during the move. Ownership is often one or two people, so documentation and handover matter more than tooling.
- Scope: Limited to a few workflows, one set of alert sources and one workspace.
- Mapping effort: Low, but each playbook still needs its steps re-expressed as Tracecat actions.
- Enterprise features: Single sign-on and multi-tenant workspace management are usually not needed unless identity policy requires SSO.
- Deployment: A single-host Docker Compose setup is often enough for a small team, subject to your own availability requirements.
- Risk: Key-person dependency, so write down how each workflow is triggered and who receives its output.
Confirm with Tracecat whether the features your team relies on are in the community edition or the Enterprise license before you commit to a deployment model.
An MSSP migrates for many customers at once, so the scope multiplies. Each client's playbooks, alert sources, case history and access rules must be separated, and the migration plan must decide whether clients share one Tracecat deployment or receive their own. Mapping effort goes up because the same logical playbook often exists in slightly different forms for each client, and those variants need to be reconciled before they become shared templates. Tenant isolation is the area where the Enterprise features matter most.
- Scope: Per-client inventories, separate alert routing and reporting for each tenant.
- Mapping effort: Higher, driven by client-specific variants of the same playbook.
- Enterprise features: Multi-tenant workspace management and Git version control integration are named as Enterprise features in the Tracecat repository, so confirm their availability and terms before design.
- Access control: Single sign-on is described as an enterprise capability in the Tracecat documentation, which matters for analyst access across tenants.
- Operations: Upgrades, backups and tenant onboarding become recurring operational tasks.
Ask Tracecat which tenancy model and license tier fit your client contracts, and document how client data is separated before any playbook is moved.
A team with many custom FortiSOAR modules and heavily templated Jinja logic faces the largest rewrite. Custom modules must be turned into Tracecat actions or workflow logic, and Jinja expressions must be re-expressed in Tracecat's syntax and tested against sample alerts. The FortiSOAR export is the starting inventory, but it does not replace reading each expression to understand what it does. This group benefits most from pulling custom actions into Git early so that changes are reviewed and tested rather than edited in a UI.
- Scope: Driven by the number of custom modules and the complexity of their Jinja logic.
- Mapping effort: Highest, because each expression needs a behavioral test, not only a syntax check.
- Git sync: Custom actions can be synced from Git, which supports review and rollback; Git version control integration is listed as an Enterprise feature.
- Testing: Build a set of sample alerts and expected outcomes for each rewritten workflow.
- Knowledge transfer: Logic often lives in people's heads, so pair each module owner with the engineer doing the rewrite.
Before scoping, ask Tracecat and your implementation partner which custom modules have direct Tracecat equivalents and which need new actions written from scratch.
Migration sequence: inventory, pilot, parallel run and cutover
The sequence moves FortiSOAR automation into Tracecat in controlled stages, so each playbook and alert source is proven before FortiSOAR is retired. Each phase ends with a written artifact that the security and operations owners can review.
Inventory playbooks, modules and connectors
Run the FortiSOAR Configuration Export and list every playbook, module, connector setting and scheduled task it contains. Your SOC lead and a FortiSOAR administrator should tag each item by owner, alert source, trigger type and business criticality. The output is a playbook inventory that flags which items are active, which are dead code, and which depend on FortiGuard-tied features. The step is done when every active playbook has an owner and a target disposition: rebuild, retire or replace with a Tracecat action.
Build a mapping sheet for Tracecat
For each inventory item, record how the FortiSOAR concept maps to Tracecat: incident records to cases, reference data to structured tables, triggers to webhooks, and connector calls to prebuilt connectors or custom actions. Note every Jinja expression that must be rewritten as a Tracecat workflow expression, and flag any logic that needs a custom action synced from Git. Confirm current connector coverage in the Tracecat documentation rather than assuming a match. The output is a mapping sheet that a reviewer can sign off before any workflow is built.
Pilot a few low-risk playbooks
Choose a small set of low-risk playbooks, such as enrichment-only or notification flows that do not block containment, and rebuild them as Tracecat workflows. Deploy Tracecat in a test environment using the method your platform team has chosen, whether Docker Compose, Kubernetes or an air-gapped cluster. Run each workflow against replayed or sample alerts and compare outputs with the FortiSOAR results. The pilot is complete when the outputs match the agreed acceptance criteria and the analysts who use the workflows have signed off on the case layout.
Run both platforms in parallel
Send selected alert sources to FortiSOAR and Tracecat at the same time, with FortiSOAR still performing the live response actions. Log each alert, the actions each platform took, and any mismatch in enrichment, severity or case creation. Review the discrepancies daily with the SOC and fix the Tracecat workflows or the mapping sheet before the next change. Keep webhook and credential handling reviewed so that no action runs twice against production systems. The output is a parallel-run log that records agreement rates and open defects for each source.
Cut over each alert source
Move one alert source at a time from FortiSOAR to Tracecat, starting with the source whose parallel-run log shows the fewest open defects. Repoint the webhook or feed, confirm that the first live cases appear in Tracecat, and keep a documented rollback path to the FortiSOAR playbook for that source. Update the runbook, on-call contacts and escalation paths before the switch. The step is complete when every source in scope has been moved, the rollback path has been tested, and the change record names the approver.
Archive records and decommission FortiSOAR
Once no active source sends alerts to FortiSOAR and the retention period for its records has been confirmed with your compliance team, export the remaining incident records and the final configuration. Store the archive in a location that meets your retention and access rules, and verify that it can be read by someone who does not have FortiSOAR access. Then shut down FortiSOAR and remove its licenses, following your license terms with Fortinet. The output is an archived export, a retention record and a signed decommission report.
Mapping playbook steps and Jinja expressions to Tracecat workflows
Treat every FortiSOAR playbook as a specification to rebuild, not a file to import. Walk each playbook step by step and record what it does: which connector or module it calls, what inputs it passes, what it writes back to the record, and which branch it takes next. Then create the equivalent action and workflow in Tracecat, and map each branch explicitly. FortiSOAR's playbook logic and Tracecat's workflow model are organized differently, so the goal is to preserve the decision outcomes (enrich, escalate, close, notify), not the visual layout. Keep a mapping sheet with one row per FortiSOAR step, the Tracecat action that replaces it, and the owner who signed off the change. Where a step has no clean equivalent, such as a manual approval or a vendor-specific lookup, record that gap and decide whether to rebuild it with a custom action, a webhook, or a human task before you move on.
FortiSOAR playbooks rely on Jinja-style expressions to reference step outputs, record fields and conditions. Those expressions do not carry over unchanged. Each reference to a prior step result, each filter, each string transformation and each conditional must be rewritten against the data shape Tracecat actually produces at runtime, and the field names in your alert and case records will often differ from the ones FortiSOAR used. Do not copy expressions across and assume they evaluate the same way. Confirm the expression syntax and available filters in the Tracecat documentation for the version you deploy, and test edge cases such as empty lists, missing fields and null values, which are the most common source of silent failures in migrated logic.
Every rewritten workflow needs test cases built from recorded alerts before it touches live sources. Export representative alerts from FortiSOAR or your alert sources, including benign, malicious, incomplete and duplicate examples, and replay them through the Tracecat workflow in a non-production workspace. Compare the outcome of each branch with what the original playbook produced, and record every difference as either an intended improvement or a defect. Keep the recordings and expected results under version control so the same tests run again after each change. Plan for the risk that an incorrect condition will close or suppress real incidents, and make the sign-off decision explicit: a named analyst or engineer approves each workflow only after its recorded alerts pass.
What drives migration cost and duration
This table lists the factors that raise or lower the effort of moving FortiSOAR playbooks and records to Tracecat, and how each one changes the work. Read it as a checklist to scope with your implementation partner before a quote is written, since most of the effort sits in the playbook inventory and the testing that follows.
| Driver | Why it moves cost or effort | How to keep it down |
|---|---|---|
| Number and complexity of playbooks | Each FortiSOAR playbook must be rebuilt as a Tracecat workflow, and branching, loops, sub-playbooks and Jinja-based expressions each need manual translation and checking. | Inventory every playbook from the Configuration Export first, retire unused ones, and group similar playbooks so shared logic is rebuilt once. |
| Custom modules and connectors | Custom connectors have no direct import path, so each one needs a Tracecat custom action, and any vendor API quirks must be reproduced and tested. | Count custom modules early, prioritize those used by active playbooks, and keep actions in Git so they are versioned and reviewed once. |
| Historical records to keep | Moving closed incidents into Tracecat cases and structured tables requires field mapping, and large volumes add data transformation and validation work. | Decide which records must move for compliance and which can remain archived in the FortiSOAR export, then migrate only the active or required set. |
| Enterprise feature needs | SSO and multi-tenant workspace management are named as Enterprise features, so their presence adds licensing and identity integration effort on top of the base platform. | Confirm with Tracecat which features your team actually needs in writing before design starts, and note which ones depend on the Enterprise license. |
| Hosting model | Docker Compose on one host is the simplest path, while Kubernetes via Helm and the air-gapped Kubernetes option add cluster, image mirroring and operations work. | Match the deployment to your real requirements, and confirm the supported options and prerequisites in the Tracecat documentation for your environment. |
| Alert source changes | Each SIEM, EDR or ticketing feed that sends alerts to FortiSOAR must be repointed to Tracecat webhook triggers, which often needs changes on the source side and coordination with other teams. | List every alert source and its owner, and schedule changes in batches so each source can be verified before the next one moves. |
| Testing and parallel running | Each rebuilt workflow needs test cases against known alerts, and running FortiSOAR and Tracecat side by side increases the effort of comparing outcomes. | Build a shared set of sample alerts with expected results, and set clear exit criteria so parallel running ends on a known date. |
What usually goes wrong and how to prevent it
Most failed FortiSOAR to Tracecat migrations break in the same few places: untested workflows, lost connector behavior, orphaned records, wrong assumptions about edition features, unversioned custom code, and premature alert cutovers. Each card below names one of these risks and the check that prevents it, so the project can be run in stages with evidence at each step.
Playbooks rebuilt without tests
A FortiSOAR playbook often looks finished once every step is drawn in Tracecat, yet the logic still fails on real alerts with empty fields, duplicate events or unexpected severity values. Before cutover, replay a set of historical alerts through each rebuilt workflow and compare the resulting cases, enrichments and tickets with what FortiSOAR produced. Keep the replay inputs in version control so they can be rerun after every change.
Lost connector behavior
FortiSOAR connectors carry configuration such as retry rules, field mappings, timeouts and credential handling that do not appear as obvious steps in a playbook. When a connector is replaced by a Tracecat action, these defaults can silently disappear, so a lookup that used to retry may now fail once and stop. Inventory each connector's settings from the export, then document which behaviors the new action reproduces and which you add explicitly.
Records left behind without an archive plan
Cases, incident notes, attachments and audit history in FortiSOAR do not move automatically just because playbooks do. Teams that switch off the old platform without an archive lose the ability to answer questions about past incidents, and retention obligations may still apply. Decide which records are migrated into Tracecat cases and tables, which are exported to read-only storage, and who approves deletion, with retention periods confirmed against your own policy.
Enterprise-only features assumed in the open-source edition
Tracecat's Git version control integration, multi-tenant workspace management and single sign-on are named as Enterprise features, and the Enterprise code sits under a separate paid license. A design that depends on SSO or Git-synced custom actions without budgeting for that edition will stall at the access or deployment stage. Confirm the license terms and feature gates for each requirement with Tracecat before the architecture is approved.
Custom actions not under version control
Custom actions written for FortiSOAR often exist only as edits made in the admin interface, with no history or review. Moving them into Tracecat without a Git repository repeats that problem, and a later change can break several workflows at once. Store every custom action in Git from day one, require review for changes, and tag the commit that each production workflow depends on so rollbacks are possible.
Alert sources cut over before validation
Redirecting SIEM, EDR or email feeds to Tracecat webhooks before the new workflows pass replay tests means analysts receive untested output during live incidents. Run both platforms in parallel for a fixed observation window, compare outcomes source by source, and switch one alert source at a time. Keep the FortiSOAR triggers ready to re-enable until each source has a documented sign-off from the SOC lead.
Questions buyers ask before moving from FortiSOAR to Tracecat
What does the effort and cost of a FortiSOAR to Tracecat move depend on?
The effort depends mostly on how many playbooks, custom connectors and record types you run, how much of your FortiSOAR logic depends on FortiSOAR-specific modules and Jinja expressions, and how many alert sources you need to re-point. Cost has two parts: your own infrastructure and staff time, which recur or are one-time as noted below, and any external implementation work, which is one-time and scoped in writing. Tracecat's core is licensed under AGPL-3.0, so the software itself carries no license fee, but its Enterprise Edition features are under a separate paid license. Ask Tracecat for its current edition terms and ask any implementation partner for a written scope before you compare numbers.
How long does a FortiSOAR to Tracecat migration take?
No timeline is fixed in advance, and the duration is set by inventory size and complexity rather than by the platform alone. The main drivers are the number of playbooks to rewrite as Tracecat workflows, how many custom actions need to be ported and synced from Git, how much case history you need to carry over, and how much testing your SOC requires before switching alert sources. Use your FortiSOAR export to count playbooks and modules, then ask for a phased plan with a written schedule. Confirm current deployment and migration steps against Tracecat's documentation at docs.tracecat.com.
What does our team need to provide during the migration?
Plan for named owners from the SOC, the platform team and whoever holds the FortiSOAR integrations. The SOC must supply playbook logic and approval rules, the platform team must provide hosting, networking, secrets handling and backup, and someone must own the Git repository that holds custom actions. You will also need access to the FortiSOAR configuration export and to the alert sources and downstream systems that each playbook calls. Confirm with Tracecat which Tracecat roles, licenses and access controls your team needs before the project starts.
Can our own team do the migration without an implementation partner?
Yes, a capable internal team can run the migration, provided it has people who know FortiSOAR playbooks, Python for custom actions, container platforms and the SOC's workflows. The harder parts are usually re-creating FortiSOAR module logic as Tracecat cases and tables, rewriting Jinja expressions, and proving that detections and response steps behave the same before cutover. If your staff lack that time or depth, you can ask DeployOpen for a fixed-scope engagement covering planning, implementation, hardening, backup and documentation, agreed in writing before work starts.
Are SSO and multi-tenant workspaces included in the open-source edition of Tracecat?
No, according to the supplied repository information, multi-tenant workspace management and Git version control integration are named as Enterprise features, and the Tracecat documentation describes authentication and single sign-on as enterprise features. The core AGPL-3.0 code is open source, but code under the Enterprise Edition license is separate and paid. If you rely on SSO for SOC access or on multiple tenants for an MSSP model, get the exact feature list and license terms from Tracecat in writing before you plan the architecture. Also note that Git-synced custom actions are listed as an Enterprise feature, so confirm whether your plan depends on it.
Can historical FortiSOAR incidents move to Tracecat?
Historical records can often be moved, but usually through a deliberate export and import rather than a direct transfer, so plan for a mapping exercise. FortiSOAR record types need to be mapped to Tracecat cases and structured tables, and attachments, comments and status history may need separate handling. Decide which records must be migrated, which can be archived read-only in FortiSOAR or in your own storage, and how long you must retain them for audit. Confirm with Tracecat what import paths it supports for case data and how it stores attachments in its object store.
How do we keep FortiSOAR running during the parallel run?
Keep FortiSOAR as the system of record for alert handling until Tracecat has passed agreed tests, then switch alert sources one at a time. Run the same test alerts through both platforms, compare the actions and case outputs, and record every difference in a shared log. Keep FortiSOAR connectors and credentials active, back up its configuration on a schedule, and define a rollback path for each source. Set exit criteria in writing, including who signs off the cutover and when FortiSOAR is placed in read-only mode for retention.
Where to confirm Tracecat capabilities before you plan
Before you finalize the mapping from FortiSOAR modules and playbooks to Tracecat, confirm the capabilities your plan depends on against Tracecat's own sources. The first stop is the TracecatHQ repository, which states the project's license, lists the prebuilt connector count and names the features that sit in the Enterprise Edition. Treat the Enterprise feature list as a decision input: multi-tenant workspace management, Git version control integration and authentication with single sign-on are described there as enterprise features, so any FortiSOAR function that depends on them needs a paid license in your cost model, not a free-tier assumption.
Next, check the Tracecat GitHub releases page for the version you intend to deploy. The most recent release in the supplied facts is 1.2.0, dated October 16, 2026, but your team should confirm the current release on the day you pin a version, read its changelog for breaking changes to workflows or custom actions, and record the exact tag in your migration runbook. Then use the Tracecat documentation to verify the pieces that drive your architecture: the deployment target (Docker Compose on a single host, AWS ECS Fargate through Terraform, Kubernetes through Helm, or air-gapped Kubernetes), the webhook trigger and structured table behavior that replace FortiSOAR record handling, and how custom actions are synced from Git. Ask your Tracecat contact or the community channel to confirm any connector your FortiSOAR inventory needs but the prebuilt catalog does not list, because a missing connector means a custom action to build and maintain.
How DeployOpen scopes, runs and supports the migration
DeployOpen is a Chainscore Labs company that plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure. For a FortiSOAR to Tracecat migration, we work from a written scope that covers playbooks, records, custom actions and the Tracecat deployment you choose.
How we scope
- We inventory FortiSOAR playbooks, modules, connector settings and custom content from your configuration export before any build starts.
- The written scope lists which playbooks move, which are retired, and which record types map to Tracecat cases and tables.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work begins, and a quote follows from that scope.
How we build
- We rebuild selected playbook steps as Tracecat workflows and actions, and rewrite FortiSOAR Jinja expressions into the Tracecat equivalents.
- Custom actions are synced from a Git repository so changes are versioned, reviewed and traceable across environments.
- Each workflow is tested against sample alerts and records in a non-production Tracecat instance before any alert source is switched over.
How we hand over
- We document the deployment, workflow inventory, mapping decisions and the rules for moving records, so your team can audit the migration later.
- Handover covers the Tracecat deployment on the target you select, whether Docker Compose, Kubernetes or an air-gapped cluster, with backup procedures and access settings recorded.
- Your staff are walked through the workflows and custom action repository, with open questions about edition features such as SSO confirmed in writing.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after the migration closes.
- Support can cover Tracecat version upgrades, which we test in staging before they reach production workflows.
- Where a feature you rely on sits in Tracecat's Enterprise Edition, we help you confirm licensing with Tracecat before the scope is final.
