What you can export from Cortex XSOAR, and what you cannot
If your team faces a renewal, a licensing change or a data residency requirement, the first question is what can leave Cortex XSOAR through a documented path. The answer is that custom content can be exported, while runtime logic, incident history and some script types need separate work. Playbooks, scripts, integrations and the related configuration are the parts you can take with you. The logic that depends on XSOAR's own runtime, the war room state and the analyst records tied to past incidents do not move as files, so plan for them separately. This page covers only the paths Palo Alto Networks documents, and it does not assume undocumented exports.
There are two routes. The first is the Cortex XSOAR 8 documentation's export of all custom content, reached from Settings, Server Settings and Custom content, where you choose Export all custom content. Individual playbooks can also be downloaded from the content item menu. The second is the demisto-sdk download command, which pulls integrations, scripts, playbooks, layouts, field definitions, classifiers and lists from a tenant into a local repository. The SDK route needs DEMISTO_BASE_URL and DEMISTO_API_KEY, and for XSOAR 8 tenants also XSIAM_AUTH_ID. Confirm the exact flags and version of the SDK against your tenant before you rely on a script in production.
The main gap is JavaScript-based integrations and scripts, which the SDK download cannot retrieve, so you must locate their source and rebuild them. Before any migration, ask your administrator to inventory every JavaScript item and every dependency on XSOAR-only features, and keep a dated export as evidence of the content you held. Confirm with Palo Alto Networks how your contract treats exported content, and with your compliance team whether incident records need to be retained in their own archive.
Which data types can be exported and how
This table lists each custom content type, the route that exports it and what to confirm about the output. Use the demisto-sdk download command for repeatable exports into a local repository, and the UI for a quick snapshot or a single playbook. JavaScript integrations and scripts are the main gap, so plan their rewrite before you start.
| Content type | Export route | Format and what to confirm |
|---|---|---|
| Integrations (Python) | demisto-sdk download, including --all-custom-content; UI export of all custom content | Downloaded into the local repository. Confirm the file layout the SDK writes for your tenant version. |
| JavaScript integrations | Not downloadable with demisto-sdk | Confirm whether the UI export includes them. Plan a manual rewrite as Shuffle apps or Python code. |
| Scripts (Python) | demisto-sdk download; UI export of all custom content | Confirm how each script is written to disk and whether dependencies are bundled. |
| JavaScript scripts | Not downloadable with demisto-sdk | Source must be recovered from the UI or your records. Confirm before decommissioning the tenant. |
| Playbooks | demisto-sdk download; per-playbook download from the content item menu; UI export | Confirm the file format of each download and whether sub-playbooks export with their parent. |
| Reports, dashboards and widgets | demisto-sdk download; UI export of all custom content | Confirm the output format and whether saved filters and data sources are included. |
| Incident fields, indicator fields, incident types and layouts | demisto-sdk download; UI export of all custom content | Confirm that layout mappings and field references are preserved in the exported files. |
| Classifiers and lists | demisto-sdk download; UI export of all custom content | Confirm list contents are complete, since lists often hold environment-specific values. |
| XSOAR 8 tenant requirements | demisto-sdk needs DEMISTO_BASE_URL, DEMISTO_API_KEY and XSIAM_AUTH_ID | Create the API key with the minimum role your export needs. Confirm the XSIAM_AUTH_ID value with your administrator. |
What does not transfer and how to handle each gap
The demisto-sdk and the UI export cover most declarative content, but some custom logic stays behind. Each gap below needs a decision about rewriting, documenting or recovering the original source before you start a migration.
JavaScript integrations and scripts
The demisto-sdk download command cannot retrieve JavaScript-based integrations or scripts, so these never reach your local repository through that path. Inventory every integration and script by language before you export, and mark the JavaScript ones as a separate work item. Plan to rewrite each one as a Python integration or as a Shuffle app. Confirm with Palo Alto Networks whether any other export route returns the original JavaScript source for your tenant version.
Rewriting scripts in Python
Once a JavaScript script is identified, the workable path is a Python rewrite that keeps the same inputs, outputs and error handling. Test each rewrite against recorded incidents so analysts see the same results. Budget review time from the people who own the logic, because the code is often the only written record of a decision. Ask Palo Alto Networks which XSOAR 8 runtime functions the original script relied on, since those calls have no direct equivalent in a Python rewrite.
War room and analyst conversation history
War room entries, analyst commands and the timeline of an incident live in XSOAR's case data, not in playbook files. Exporting playbooks does not carry this history into another platform. Decide which closed cases must remain searchable, then export them to a records system or archive them as documents. Confirm with Palo Alto Networks how long case data remains accessible on your tenant and how it can be exported in bulk.
Incident data and field dependencies
Playbooks often read incident fields, indicator fields, incident types and layouts that exist only in the XSOAR tenant. When you export these, the playbook still references field names that the target platform does not define. Map each referenced field to a Shuffle workflow variable or a case schema, and record the mapping in a table. Check that the export includes incident types and layouts, which the demisto-sdk lists among downloadable items, before you retire the source tenant.
Hosted content and runtime-bound logic
Some playbooks call hosted content packs, marketplace integrations or Palo Alto Networks threat intelligence feeds that run only inside the XSOAR service. These calls do not transfer, and the exported playbook may show them as opaque steps. Replace each hosted dependency with a self-hosted connector, a direct API call or a documented manual step. Ask Palo Alto Networks which content items are licensed content and which ones you may export for use elsewhere.
Credentials and integration configuration
Exported integration files describe how an integration works but do not carry the stored credentials, instance settings or secrets that run it in production. Each integration needs new credentials on the target platform, and the old values should be rotated rather than copied. Build a list of every configured instance from the XSOAR tenant, note its owner and purpose, and confirm with your own secrets records that no secret is still needed by a system you have not inventoried.
The export sequence and how to verify each step
This sequence takes custom content out of Cortex XSOAR twice, once through the UI and once through the demisto-sdk, then checks the two results against each other and against a working copy of the playbooks. It ends with a versioned, checksummed archive that the team can restore and audit later.
Inventory custom content before exporting anything
The XSOAR administrator lists every custom playbook, script, integration, layout, classifier, mapper and list still in use, and marks each item as active, dormant or retired. Record the owner, the incident types and the integrations each playbook calls, because these are the dependencies that will matter when rebuilding in Shuffle. The step is done when the inventory has one row per item and the count is agreed with the team that owns the automation. Confirm the list against the tenant itself, not against memory or old documentation.
Export all custom content from the UI
In the XSOAR 8 interface, go to Settings, then Server Settings, then Custom content, and select Export all custom content. Individual playbooks can also be downloaded from the content item menu, which is useful for a small set of items you need to inspect first. Save the archive in a restricted location and keep the download log. The step is done when the file is saved and you have a record of its name, its size and the time it was created. Confirm the export format and contents with the version of XSOAR you run, because the menu labels can differ between releases.
Run the demisto-sdk download command
Using the demisto-sdk download command with the --all-custom-content option, pull the same content into a local repository. The command needs DEMISTO_BASE_URL and DEMISTO_API_KEY set in the environment, and XSIAM_AUTH_ID as well when the tenant is XSOAR 8. Run it from a machine with access only to the tenant and store the repository in a clean working directory so the output is easy to compare. The step is done when the command completes without errors and the local folders hold the expected integrations, scripts, playbooks and field definitions.
Record JavaScript integrations and scripts by hand
The SDK cannot download JavaScript-based integrations and scripts, so open each one in the XSOAR interface and record its name, version, purpose and the playbooks that call it. Copy the source code into a separate folder with a note on where it came from, and mark whether it has been rebuilt as a Python integration. The step is done when every JavaScript item in the inventory has a recorded source copy and a documented dependency list. Items that depend on runtime behavior, such as a playbook step that relies on a specific server feature, should be flagged here for rebuilding rather than assumed to transfer.
Compare item counts across both exports
Count the items in the UI archive and in the SDK repository by type, then reconcile them against the inventory from the first step. Any difference should be explained, for example by an item that is marked as a JavaScript script, a built-in item that was not customized, or an item created after the first export. The step is done when every type matches or each mismatch has a written reason and an owner. This is a basic check, but it catches the most common losses before anyone relies on the export.
Open exported playbooks in a test environment
Import the exported playbooks into a non-production XSOAR or a test workspace, and open each one in the editor. Check that tasks, conditions, sub-playbooks and input arguments load without errors and that the referenced integrations and scripts are present. Where a playbook calls a JavaScript script or an integration that is not installed in the test environment, record that as a gap. The step is done when each playbook has a pass or fail result and each failure is linked to a cause. Confirm the test environment matches the production version closely enough for the results to mean something.
Store the export in version control with a checksum
Commit the SDK repository, the JavaScript source copies, the inventory and the UI archive to a private Git repository on infrastructure you control. Generate a SHA-256 checksum for the UI archive and record it in the repository alongside the commit that contains the SDK output. Store a note of the XSOAR version and the date of the export. The step is done when the repository holds the full set, the checksum can be recomputed from the stored file, and a second person has confirmed the commit. This record lets you prove later what the export contained and detect any change to the archive.
How to read the exported files before you rely on them
A successful export proves only that XSOAR returned files, not that the content will run anywhere else. The output of demisto-sdk download is a local repository of files that still reflect XSOAR's content model: integrations, scripts, playbooks, classifiers, layouts, incident fields and incident types. Each of these refers to other objects in the same tenant. Before you rely on a file, open it and check what it depends on. Look for references to other integrations, to shared scripts, to incident fields by name and to layouts or classifiers that exist only in the source tenant. A playbook that calls a script which was not exported, or a task that expects an incident field your target does not define, is a finding to log, not a detail to fix later.
Credentials need separate attention. Exported integration configurations point to credential instances rather than holding usable secrets, so the reader must confirm how each reference resolves on the target system and who will create the replacement credentials. Map every credential reference to the owner, the account it authenticates as and the scope it needs. Incident field mappings deserve the same review, because a field name that matches in both systems can still carry different types, values or required settings. Keep an inventory that links each exported file to the production item it came from, including the item name, its tenant identifier, the export date and the version of the file. That inventory is what lets a reviewer confirm later that nothing was lost, and it gives you a list to test against when the content runs elsewhere.
Questions teams ask before they export Cortex XSOAR content
How much effort does a full Cortex XSOAR content export take?
The effort depends mostly on how much custom content the tenant holds, how much of it is JavaScript, and how quickly your team can get tenant access and an API key. The export itself is a command run against the tenant, so the time goes into inventory, checking what downloaded, and deciding what gets rebuilt. Before you commit to a timeline, count your playbooks, scripts and integrations by type and list which ones are JavaScript, since those need separate work. Ask any partner for a quote that breaks the effort into inventory, export, review, rebuild and testing, with each line tied to those counts.
Can our team export Cortex XSOAR content without outside help?
Yes, a team with tenant access can run the documented export steps itself. The UI route covers all custom content through Settings, Server Settings, Custom content, and individual playbooks can be downloaded from the content item menu. For a repository-level export, the demisto-sdk download command with --all-custom-content pulls integrations, scripts, playbooks, layouts, classifiers and lists into a local repository. The harder part is the review: deciding which downloaded items still work outside XSOAR, which depend on its runtime, and which must be rewritten. That review is where most teams ask for help.
What do we need to provide before an export starts?
You need an admin account on the tenant, an API key with rights to read custom content, and the variables the demisto-sdk expects. For XSOAR 8 tenants, the command also requires the authentication ID, supplied as XSIAM_AUTH_ID, alongside DEMISTO_BASE_URL and DEMISTO_API_KEY. A test tenant or a copy of production is useful so you can export without touching live response logic. You also need a named owner for each playbook or integration, because someone has to confirm what each item does before it is moved. Confirm the exact key permissions and API settings with Palo Alto Networks for your tenant version.
Is exporting Cortex XSOAR content enough to move to Shuffle?
No, an export gives you the source material, not a working system. Exported playbooks describe logic, but the integrations behind them must be rebuilt as Shuffle apps, either from OpenAPI specifications in the App Creator or in Python with the Shuffle app SDK. JavaScript integrations and scripts cannot be downloaded through the documented command, so they must be recreated from their logic. You also need to rebuild triggers, credentials and the incident layouts that analysts used, since Shuffle does not supply those. Plan the migration as export, rebuild, test and run in parallel, and confirm the scope of each step in writing.
What happens to incident history and case data during the export?
The content export covers custom content such as playbooks, scripts, integrations, layouts and fields. It is not a method for moving incident records, war room notes or case history, so confirm separately whether your tenant's export or reporting tools cover that data. Keep the XSOAR tenant available in read-only form for the retention period your compliance obligations require, and check that the records you keep can still be read after the tenant is retired. Shuffle's incident handling does not replace XSOAR's layouts or war room, so decide early whether cases stay in the automation tool or move to another system.
Which parts of the export will not work outside Cortex XSOAR?
The main gaps are JavaScript-based integrations and scripts, which the demisto-sdk download command cannot fetch, and any logic tied to XSOAR's runtime. Examples of runtime dependence include built-in war room commands, incident context structures and automations that rely on XSOAR's internal objects rather than external APIs. Downloaded Python content still needs review, because its calls may assume the XSOAR execution environment. Build a list of these items during inventory and assign each one a rebuild or retirement decision before the export starts.
When should we bring in outside help for an export?
Bring in outside help when the inventory shows many JavaScript items, playbooks tied to XSOAR's runtime, or integrations that must be rebuilt as Shuffle apps, or when no one on your team has time to review the output. DeployOpen plans, implements, customizes and integrates self-hosted open-source platforms in your own infrastructure, and most engagements are fixed-scope with deliverables and timelines agreed in writing before work starts. Ask for a quote built from your written scope, and ask how the work will be tested against your current playbooks before anything goes live.
What to plan before the Cortex XSOAR contract ends
Start from the exit date, not from the export. Before you run any export, confirm in writing with Palo Alto Networks which rights you hold under your agreement to export custom content, and how long you keep access to the tenant or server after the subscription or support term ends. Ask whether read access survives termination, whether the vendor can provide a copy of your data if the export tooling fails, and what happens to incident records, which the playbook export does not cover. Work backward from the last date you can still log in and call the APIs, then set internal milestones for inventory, export, and a verified copy stored somewhere you control.
Check the version you will be running during the transition. Palo Alto Networks has announced that Cortex XSOAR 6.12 and 6.13 reach end of life on June 30, 2026, and that 6.14 remains active and is the version it recommends for on-premises and air-gapped sites. If your servers are on 6.12 or 6.13, plan the export against a supported version or confirm with Palo Alto Networks what support you have until your exit date. Also confirm which deployment you are on, because on-premises XSOAR 8 and SaaS XSOAR 8 expose content differently, and the demisto-sdk download command needs the correct base URL and authentication for your tenant type.
Keep a running copy during the transition, not a single export on the last day. Export on a schedule, commit the output to a version-controlled repository you own, and record which export produced which copy. Test each copy by reading it back before you rely on it. Use the window in which both systems are live to rebuild the highest-value playbooks, because a rebuild cannot be finished in the final week. Confirm all dates, support windows and export rights with Palo Alto Networks directly, since contract terms and vendor schedules may differ from the general information on this page.
What to plan before renewal or termination
Exporting content is only one step in leaving Cortex XSOAR. The cards below cover the contract, access, content freeze, storage, runtime dependencies and sign-off that decide whether the export is usable once the subscription lapses. Work through them in roughly this order, because some of them stop being possible the day access is removed.
Confirm contractual data return rights
Read your agreement for what the vendor must return or let you retrieve at end of term, in what format and within what window. Ask Palo Alto Networks or your reseller whether custom content, incident records and logs are included, and whether any export is chargeable. Get the answer in writing before you rely on it, since the export tools described on this page only cover what your tenant can reach.
Secure admin and API access early
The demisto-sdk download command needs a working DEMISTO_BASE_URL, a DEMISTO_API_KEY and, for XSOAR 8 tenants, XSIAM_AUTH_ID. Create or confirm a dedicated export account with the read permissions needed for custom content, and keep at least one administrator who can still log in. Do this before any licence reduction or user cleanup, because an expired key or deactivated account can block the export at the moment you need it.
Freeze and inventory content changes
Once you start exporting, agree a change freeze on playbooks, scripts, integrations and classifiers, or record every edit made after the export date. Build an inventory list from the tenant that matches the content types the download command covers, such as integrations, scripts, playbooks, layouts and lists. Without a snapshot, the repository you export can differ from what analysts ran in production, which makes later rebuilds harder to verify.
Decide storage and ownership of exports
Exported content contains business logic, integration endpoints and sometimes embedded configuration, so decide where the repository lives before you pull it. Choose an internal Git server or an access-controlled file store, assign a named owner, and set retention and access rules. Confirm with your security team whether any exported file can hold secrets, and strip or rotate them before the repository is shared with a new platform team.
Map runtime dependencies to rebuild
Exported playbooks often call integrations, credentials, incident types and fields that only exist inside XSOAR. List every integration instance, its credential store, the scheduled jobs and the incident triggers that feed it. JavaScript integrations and scripts cannot be pulled by the download command, and logic tied to the runtime, such as war room commands, must be redesigned. Treat each item as a rebuild task with an owner, not as something that will come across automatically.
Set a verification sign-off
Agree the acceptance test before the subscription ends: which playbooks must run end to end, which integrations must return the same results, and who signs off on each. Compare the exported file counts and content types against your inventory, then run a sample of incidents through the new platform. Keep the signed record with your renewal or termination file, since it is the evidence that the export was complete before access was removed.
Where exported content goes next
Treat what you export from Cortex XSOAR as input to a rebuild, not as a finished replacement. A playbook file or a demisto-sdk download gives you the logic and metadata in a portable form, but the target platform still has to rebuild each piece in its own model. On Shuffle, integrations are not imported as XSOAR integrations. They are recreated either as apps generated from OpenAPI specifications in the App Creator or as Python apps written with the Shuffle app SDK, and each app runs as a versioned Docker container. Plan the work by integration first, since an app is the unit you will test, version and maintain.
Credentials need their own plan. Shuffle encrypts saved app credentials and API keys in OpenSearch with AES-256, keyed to the SHUFFLE_ENCRYPTION_MODIFIER secret. Losing or changing that secret breaks every saved app authentication, so it must be generated, stored and backed up in your secrets management process before you re-enter any API key. Export files do not carry the working secrets over, so confirm with your security team who will re-issue each service account and where the new keys will live.
Exported playbooks also need rework. XSOAR playbook tasks, war room commands and incident field references do not map one to one onto Shuffle workflows, and Shuffle has no built-in incident layouts or war room to receive them. Read each exported playbook as a specification, mark the steps that depend on XSOAR-specific behavior, and decide which ones move into workflows and which stay in your case system. Our Shuffle architecture documentation is the natural next read for planning how the runtime and workers will execute the rebuilt workflows.
How DeployOpen scopes and delivers an XSOAR exit
DeployOpen plans, implements, documents and hands over self-hosted open-source platforms inside your own infrastructure, so an XSOAR export becomes a defined piece of work with written deliverables. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before any work starts.
How we scope
- Inventory every playbook, script, integration and layout in your XSOAR tenant, separating JavaScript content that cannot be downloaded from Python content that can.
- Confirm which export path applies: the UI export of custom content or the demisto-sdk download command, based on your XSOAR version and tenant type.
- Record the runtime dependencies each playbook relies on, such as war room commands, incident fields and XSOAR-only scripts, so the written scope names what must be rebuilt.
How we build
- Export content into a versioned local repository and keep a dated manifest of every item exported and any item that failed to download.
- Rebuild exported logic in the target platform, such as Shuffle workflows or OpenAPI-based apps, and test each workflow against documented sample inputs.
- Store API keys and credentials in the target platform's secret handling rather than in exported files, and check that no secrets remain in the repository.
How we hand over
- Deliver a written inventory mapping each source item to its exported file, its rebuilt equivalent and its status, so your team can audit the transfer.
- Document what did not transfer, including JavaScript integrations and runtime-bound logic, with the decision taken for each item.
- Hand over the repository, configuration notes and runbooks to your team, so they can maintain the exported content without us.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after the handover of the exported content.
- Confirm with us in the written scope whether parallel running against XSOAR is included, and for how long, before work begins.
- Ask for a quote built from the written scope, since DeployOpen does not publish a price list and each export depends on the size of your content library.
