What you can export from FortiSOAR and what you must rebuild
If a FortiSOAR renewal, licensing change or exit plan is forcing you to get configuration out of the platform, start by treating the Configuration Export wizard as an inventory of configuration content, not as a migration. It covers configuration content such as playbooks, modules and connector settings. Incident records, licensing entitlements and some credentials need a separate plan, because they do not travel with a configuration file in the same way. The export is useful in two ways. It gives you a written list of what you built, which is the starting point for estimating how much rework a move to another platform will need. It also gives you a backup point you can restore from if an exit stalls. Neither use turns the export into a working copy of the environment. A playbook that calls a connector still needs that connector rebuilt on the target platform, and a module's logic still has to be re-tested against the new engine.
Before you rely on any output, confirm the exact scope with Fortinet's documentation for your FortiSOAR version. Ask which objects the wizard includes, which it omits, what format it writes, and whether it captures secrets or only references to them. Run a test export in a non-production instance and compare the result with your own list of playbooks, modules and connectors. Record every gap in a migration inventory that names an owner for each item. That inventory, not the export file itself, is what your procurement, security and engineering teams should review together.
Which FortiSOAR configuration items the export covers
This table lists the configuration items the Configuration Export wizard is documented to capture, with the export method and the checks you must complete before relying on it. Read the format and limits column as a list of things to verify in your FortiSOAR version and a test export, since no figures are stated here. The main takeaway is that the export is an inventory starting point, not a complete record of your environment.
| Data type | Export method | Format and limits |
|---|---|---|
| Playbooks | Configuration Export wizard | Confirm in your version's documentation and a test export which playbook elements are included |
| Modules and custom module definitions | Configuration Export wizard | To be verified: whether custom module schemas and their fields are fully captured |
| Connector settings and configurations | Configuration Export wizard | To be verified: whether connector configurations are exported with credentials or require re-entry |
| Other configuration items named in the export options | Configuration Export wizard | Check each selectable item in the wizard against the documented list for your version |
| Incident and alert records | Not covered by the wizard | Records are a separate data set; plan a separate extract and confirm its method with FortiSOAR documentation |
| FortiGuard-tied licensing and entitlements | Not covered by the wizard | Licensing stays with the FortiSOAR deployment; confirm with Fortinet what transfers |
| Export file size and format | Configuration Export wizard | To be verified in the FortiSOAR documentation for your version and in a test export |
What stays behind: records, licensing and credentials
A configuration export captures the automation logic you build, but the operational state around it often sits elsewhere. The four cards below cover the items most likely to be missed during inventory, and each one ends with a check to run against FortiSOAR's current documentation before you plan cutover.
Incident and case records
Incidents, alerts and case history are operational data, not configuration, so they may not be part of the Configuration Export wizard. Analysts rely on this history for open investigations and for reporting. Confirm with Fortinet whether FortiSOAR provides a documented records export or API extract and, if it does, test that extract against a sample of closed and open cases before you commit to a retention plan.
Attachments and audit history
Evidence files attached to cases and the audit trail of who changed what are easy to overlook because they live beside the records rather than inside the playbooks. Auditors and incident reviewers often ask for both. Ask Fortinet which of these the export covers, and plan a separate extract for the rest. Store extracted evidence in your own object store with hashes recorded, so the chain of custody survives the move.
FortiGuard-tied license entitlements
Your FortiSOAR licensing depends on entitlements fetched from FortiGuard, so a configuration file alone does not carry your right to run the product. Keep the subscription active until the migrated workflows are proven and the alert sources have switched over. Do not let the renewal date decide cutover. Record the license terms, renewal dates and any FortiManager or entitlement-file dependency in the migration inventory so procurement can see the exit date.
Stored connector credentials and secrets
Connector passwords, API keys and certificates are usually held in FortiSOAR's own store and are generally not portable as plain values. Expect to re-enter them. Build a credential register that lists each connector, its owner, the account it uses and its rotation status, then create the credentials in your target platform's secret handling. For Shuffle, saved app credentials are encrypted with a secret you control, so plan where that secret is stored before any credential is entered.
Scheduled jobs and integration endpoints
Schedules, inbound webhook URLs and alert-source subscriptions often exist outside the playbook definitions. If they are not in the export, alerts can stop arriving or start arriving twice when you switch sources. List every trigger, its source system and its schedule, then confirm with Fortinet how each is represented in the export. Run both platforms side by side and switch one source at a time, so each trigger has a single owner at any moment.
How to run a complete FortiSOAR export in order
This sequence produces a configuration export you can trust as a migration baseline and backup, plus a separate copy of records and attachments. Each step ends with a check, so gaps are found before the production system changes.
Confirm the FortiSOAR version and admin access
The administrator who owns the export confirms the exact FortiSOAR version and build running in production, and that the account has the administrative rights needed to open the Configuration Export wizard. Record the version in the migration file, because export options and included items can differ between releases. Confirm the export route in the documentation for that version, not from memory or an older guide. Done means the version, the account, and the documented steps are written down and agreed by the people who will run the migration.
Run a test export on a non-production instance
Run the Configuration Export wizard on a non-production FortiSOAR instance that matches production as closely as possible, including the same modules, playbooks and connector configurations. Review what the file contains and what the wizard reports as skipped or excluded. Note any surprises, such as items that did not export or settings that need manual reentry. Done means you have a list of known gaps and a clear understanding of what the production export will and will not capture.
Run the production Configuration Export
Run the Configuration Export wizard on production using the options validated during the test run. Plan the export for a window when no playbooks are actively changing, and ask the team to pause manual edits until the export completes. Save the output and the wizard's log or summary, if one is produced. Done means you have a complete export file, a matching record of the options used, and a timestamp showing when the configuration was captured.
Store the export file in a controlled location
Move the export file to a storage location that your organization controls, such as an approved file share, encrypted object storage in your own environment, or a backup repository with access logging. Set access so only named administrators can read or restore it, because connector settings can include credentials or references to them. Record the file name, checksum, location and owner in your migration log. Done means the file can be retrieved by an authorized person and the storage meets your data handling policy.
Capture records and attachments through the documented route
Configuration Export does not cover incident records or their attachments, so export those through the route FortiSOAR documents for your version, such as a data export or an API-based extract. Run it on the same day as the configuration export where possible, so both snapshots describe the same period. Store records and attachments in the same controlled location, keeping them separate from the configuration file. Done means you have a record export and an attachment set, each with its own inventory of counts, dates and checksums.
Build a manual inventory from the live system
Before opening the export file, have an administrator list the playbooks, modules and connectors visible in the live FortiSOAR interface, along with each connector's configured instance and whether it is active. Include custom modules and any playbooks that are disabled, scheduled or triggered by other sources. Keep this list independent of the export so it can serve as a check. Done means you have a signed-off list that represents what the business believes is running in production.
Verify the export against the live inventory
Compare the export file's contents with the manual inventory, item by item: playbooks, modules and connectors, plus any custom content the wizard reports. Investigate every mismatch, including items present in the export but missing from the live list, because those may be stale. Record each finding and its resolution, then confirm the outcome with the platform owner. Done means every playbook, module and connector is either matched, explained, or logged as a gap that the migration plan must address, and the signed-off comparison is filed with the export.
How to turn the export into a migration inventory
Turn the raw export into a spreadsheet or table with one row per playbook, module and connector, and treat that table as the migration contract. Each row should carry an owner, the alert sources or record types that trigger it, its dependencies on other playbooks, modules or connector configurations, and a target column that names the construct that will replace it. For playbooks, the target is a Shuffle workflow or a Tracecat workflow. For connectors, the target is a Shuffle app or a Tracecat action. For modules and record types, the target is a case, table or field in the new platform. Record the target before you start rebuilding, because it forces a decision on each row: whether an existing integration is replaced by a Shuffle app built from an OpenAPI specification with the App Creator, a Python app written with the Shuffle app SDK, or a Tracecat custom action synced from Git. Mark rows that need a new webhook trigger in Tracecat, since alert sources must be repointed at a new endpoint during cutover.
Ownership and dependencies usually cause the most rework, so fill those columns from people, not from the export. Ask the analyst or engineer who maintains each playbook to confirm its purpose and any manual approvals it contains. Note which playbooks call other playbooks, which depend on a specific connector configuration or secret, and which write to an external ticketing or identity system. Credentials do not move with the export, so every connector row needs a note on where its secret is held and who can re-create it in Shuffle or Tracecat. Shuffle encrypts saved app credentials with a secret of its own, so plan that value as a new item in your secrets process, not a copy of anything from FortiSOAR.
Before you freeze the inventory, confirm the connector list against live usage. An export shows what is configured, not what runs. Pull execution history or job logs from FortiSOAR for the period you choose, and mark any playbook that has not executed recently as a candidate for retirement, subject to owner sign-off. Compare the alert sources and connectors that actually fired against the inventory, and add rows for anything that is used but missing from the export. Ask your FortiSOAR administrator or vendor which logs and reports your deployment retains, because retention limits will shape the window you can verify. Review the finished inventory with the SOC lead and the platform owner, and sign it off as the scope for the migration.
How to schedule FortiSOAR exports as backups
Use this approach when you plan to leave FortiSOAR. Take one complete export as a frozen reference point, then keep that file with your migration inventory. Before you run the Configuration Export wizard, confirm in FortiSOAR's documentation for your release which items it includes and which it leaves out. Incident records and FortiGuard-tied licensing are the items most often assumed to be included and usually are not.
- Version the file: record the FortiSOAR version, the export date and the administrator who ran the export in the migration folder.
- Confirm the scope: check whether playbooks, modules and connector settings are included, and whether stored credentials are exported or must be re-entered.
- Store it off the platform: keep a copy in storage that your migration team controls and that FortiSOAR administrators cannot overwrite.
- Plan a separate record extraction: the configuration file does not carry incident and case data, so schedule a second extraction for those records.
- Log the checksum: calculate and store a hash of each exported file so you can show later that the copy was not altered.
Before you decommission the platform, ask FortiSOAR support to confirm in writing what the exported file contains for your release.
Use a recurring schedule when FortiSOAR stays in service during a migration, or when you need a fallback copy while running both platforms side by side. Confirm in the documentation whether the product has a built-in scheduler, which options it exposes, where scheduled files are written and how long they are kept. If there is no scheduler, confirm which external job runner or manual procedure the vendor supports, so the process you document matches what the product actually does.
- Separate jobs: configure one job for configuration exports and another for incident records, because one job cannot capture both.
- Retention: confirm whether the platform prunes old exports automatically and whether you can set the period, then align it with your records policy.
- Storage location: confirm the target path or external store, whether files are encrypted at rest and who can read or delete them.
- Event-based exports: add an export after significant playbook or connector changes, so the backup reflects the latest approved state.
- Failure alerts: confirm that a failed scheduled run raises an alert to a named person who will act on it.
Ask FortiSOAR for the documented scheduling options in your release and the service account permissions the job requires.
A backup has value only if you can restore it. Build a non-production instance of the target platform, or a separate FortiSOAR instance if you need to test the exported file itself. Run the import or rebuild steps in a controlled window, then record what restored cleanly, what failed and what had to be recreated by hand. The test result is the evidence that your backup process works, so treat it as a deliverable rather than a one-off check.
- Isolated environment: place the test instance on a network segment with no live alert sources or outbound connector access, so test runs cannot act on production systems.
- Inventory comparison: match the counts of playbooks, modules and connectors on the restored instance against the export inventory.
- Credential check: verify which connector credentials restored, which need re-entry and which depend on keys held in your secret store.
- Record sample: restore a sample of incident records separately and confirm that attachments, links and timestamps are intact.
- Repeat after changes: rerun the test after major upgrades or significant configuration changes, so the restore path stays proven.
Document each test with the date, the file tested and the sign-off person, because auditors and migration leads will ask for that record.
What to plan before the FortiSOAR contract renews or ends
These six decisions shape the export work in this guide. Several depend on what Fortinet confirms in writing, so gather those end-of-term steps first. Use the cards to sequence the export, the records plan and the cutover against your last day of access.
Confirm entitlement and expiry access
Ask Fortinet to confirm in writing how your FortiSOAR license entitlement ends and what happens to console access, API calls and stored data on the last day of the term. FortiSOAR licensing is tied to FortiGuard, so a lapsed entitlement can affect more than the login page. Check whether a grace period exists, who can extend access for an export, and whether the end-of-term steps differ between your deployment types. Record the answers before you set a migration date.
Export before the last day
Run the Configuration Export wizard early, and schedule repeated exports so a recent copy exists if the term ends sooner than planned. Store each export outside the FortiSOAR host, record its date and version, and test that someone on your team can open the files. Keep a second copy in a location you control. Confirm that the export holds playbooks, modules and connector settings, and note which items it leaves behind for separate handling.
Plan for records outside the export
A configuration export does not carry incident history. Cases, alerts, attachments and audit entries that live in FortiSOAR records need their own extraction plan, with formats and fields agreed before access ends. Decide which closed incidents must stay searchable for investigations or regulators, and who owns retention once the contract finishes. Map each record type to its target, such as a Shuffle OpenSearch index or a Tracecat case, and confirm your team can reach the archive after the license lapses.
Run both platforms side by side
Keep FortiSOAR active until every alert source and playbook trigger points to the new platform. Running both in parallel shows whether the replacement receives the same events, which is the only dependable proof of parity. Avoid duplicate actions by disabling each automation in one system as you enable it in the other, such as ticket updates or containment steps. Write the cutover into a runbook with a rollback path, and do not start decommissioning until the parallel period has produced consistent results against your agreed checks.
Check Shuffle edition and app runs
Shuffle's open-source edition includes all features, but its paid tiers differ in feature limits, scaling and support, and since v2.1.1 those limits are actively enforced. Its licensing uses one metric, app runs, which counts actions that actually execute in a workflow. Triggers and skipped actions are not counted, and users, apps and workflows are unlimited. Estimate run volume from your current playbook activity, then confirm with Shuffle which tier covers your scale, support and features before you commit.
Check Tracecat Enterprise features
Tracecat's core is licensed under AGPL-3.0, but code in packages/tracecat-ee and its enterprise feature gates falls under a separate paid Enterprise Edition license. Multi-tenant workspace management and Git version control integration are listed as enterprise features, and the documentation places authentication and single sign-on in the same group. If your FortiSOAR setup depends on tenants, Git-based change control or SSO, confirm those needs against the enterprise scope in writing before you rebuild the workflows that rely on them.
Questions buyers ask about exporting FortiSOAR data
What drives the effort of a FortiSOAR export and migration inventory?
The effort scales with how much your FortiSOAR environment has been customized. The main drivers are the number of playbooks, the number of custom modules and record types, the number of connectors and their configurations, and the number of alert sources that feed the platform and must be switched over. Each playbook needs to be read, understood and mapped, and each connector needs its credentials and endpoints accounted for. A small environment with a few standard playbooks is a very different inventory from a multi-tenant deployment with years of custom content. Ask for a scope that counts these items before agreeing on any work.
Can our own team run the FortiSOAR export and inventory without outside help?
Yes, many teams can run the Configuration Export wizard and build an inventory themselves, provided they have administrator access and enough time from people who understand the automation. The export is the mechanical part. The harder part is deciding what each playbook actually does, which alert sources depend on it, and which steps are obsolete. Internal teams often underestimate how many playbooks are no longer used or how many connectors have credentials nobody remembers. An outside partner is most useful for the analysis, rebuilding and parallel running, and for producing a written inventory your auditors and stakeholders can review.
What does the export need from our team?
You need three groups of people. A platform administrator must provide access to the Configuration Export wizard and the scheduled backup settings. Playbook owners must confirm what each workflow is for, whether it is still in use, and what business outcome it protects. Alert source owners must identify which SIEMs, mailboxes, ticketing systems and other feeds send events into FortiSOAR, and must agree on when those feeds can be redirected. Without the second and third groups, the export contains files but not the decisions a migration depends on.
How long does an export and inventory take, and when do we need outside help?
Duration depends on scope, not on the export itself, which is usually quick once access is in place. The time goes into reviewing playbooks, mapping modules and connectors, and getting owners to sign off. Outside help is worth considering when the environment has many custom modules, when playbooks are poorly documented, when several business units share the platform, or when a regulated process depends on specific automations. Ask for a timeline in the written scope that names the artifacts, reviews and sign-offs included, rather than accepting an open-ended estimate.
Does the export move our FortiSOAR licenses or stored credentials to a new platform?
No. A configuration export captures playbooks, modules and connector settings, but FortiSOAR licensing is tied to FortiGuard entitlements, and it does not transfer to Shuffle or Tracecat. Stored credentials and secrets also need to be re-entered or re-issued in the target platform through its own secure mechanism, so the inventory should list every connector that needs new credentials. Records such as cases and incidents are a separate data stream and need their own export and mapping. Confirm with Fortinet how your specific license and records are handled before you plan the cutover.
How do we get a quote for exporting and inventorying our FortiSOAR environment?
DeployOpen does not publish a price list. A quote follows from a written scope. To get one, provide a count of playbooks, custom modules, connectors and alert sources, a description of any multi-tenant or regulated workflows, and the team members who will take part as administrators, playbook owners and alert source owners. Most engagements are fixed-scope, so the scope, deliverables and timelines are agreed in writing before work starts. Ask for the inventory format, the review steps and what is excluded, so you can compare quotes on the same basis.
What should we check in the export before relying on it as a backup?
Check that the export file opens and that its contents match the playbooks, modules and connectors you expect. Confirm which items are not captured, such as records, attachments and any settings the wizard does not cover, and store those separately. Restore a copy into a test environment where possible, because a backup that has never been tested is only an assumption. Schedule exports at a frequency that matches how often your playbooks change, and keep old versions so you can compare changes over time. Document who can access the export, since it describes how your security automation works.
How DeployOpen works on this
DeployOpen plans and implements self-hosted open-source platforms inside your own infrastructure, so a FortiSOAR export and exit is handled as a fixed-scope engagement with agreed deliverables. The work starts with an inventory of what your FortiSOAR export actually contains and ends with documented, tested artifacts you keep.
How we scope
- Agree in writing which FortiSOAR playbooks, modules, connectors and settings the export must cover.
- Confirm which records, attachments and FortiGuard-tied licensing items stay behind and need separate handling.
- Define the target platform, Shuffle or Tracecat, and the deployment model inside your own cloud, data center or air-gapped network.
How we build
- Set up scheduled exports and store them in your backup location, with restore tests confirmed before cutover.
- Turn the export into a migration inventory that maps each playbook and connector to a target workflow or app.
- Rebuild priority playbooks in the target platform and test them against sample alerts in a non-production environment.
How we hand over
- Deliver the migration inventory, gap list and runbook covering exports, credentials and parallel running.
- Document secrets handling, including how saved app credentials are protected and recovered in the new platform.
- Walk your security and operations teams through the cutover plan and the decommissioning steps for FortiSOAR.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Retainers can cover the target platform's version upgrades and periodic restore tests of exported configuration.
- Ask for the support scope, response expectations and retainer terms in your written quote before work begins.
