After SOAR

What actually moves when you leave Cortex XSOAR

Published 4 November 2026. About 5 minutes.

Most of an XSOAR estate does not travel. Playbook logic, Python scripts and content packs are built for XSOAR and XSIAM, and no vendor documents a converter in the pages we read. This guide sorts what moves, what you rewrite and which end-of-life dates set your deadline.

The lifecycle dates set your deadline, not the sales calendar

Start with the dates, because they decide how much time you have. Palo Alto's lifecycle pages show that XSOAR 6.12 and 6.13 reached end-of-life on 2026-06-30, and that XSOAR 8 on-prem versions retire on a three-month cycle. Version 8.10 reached end-of-life on 2026-07-30, and 8.11 follows on 2026-11-13 (Palo Alto product support lifecycle, XSOAR 8 on-prem) (read 2026-11-03). If you run on-prem, you are on a treadmill whether or not you leave.

Palo Alto also recommends XSOAR 6 for on-prem and air-gapped installs, per the XSOAR 6 lifecycle page (XSOAR 6 administrator guide) (read 2026-11-03). That is the version with the dated end-of-life. Check which patch you run before you plan anything.

On the product future, the vendor's own words are narrow. The 2025-10-28 press release describes Cortex AgentiX as the successor to XSOAR and gives no end-of-sale date and no migration path (Palo Alto Networks press release) (read 2026-11-03, vendor claim). A competitor, D3, says XSOAR professional services SKUs entered end-of-sale in October 2025. We found no Palo Alto source for that, so treat it as a rival's claim (D3 migration guide) (read 2026-11-03).

Content packs are built for Palo Alto's marketplaces

A pack is the unit XSOAR ships. It bundles integrations, scripts, playbooks, layouts, classifiers and incident and indicator types, and it carries a pack_metadata.json with a version number. The marketplaces field accepts xsoar, xsoar_on_prem, xsoar_saas, marketplacev2 (XSIAM) and xpanse (XSOAR pack format) (read 2026-11-03). So one pack can target both XSOAR and XSIAM.

That is good news if your destination is XSIAM and bad news for every other destination. Nothing in the pack format maps to a Tines story, a Torq workflow or a Sentinel Logic App. The layouts, classifiers and incident types have no equivalent object elsewhere. You carry the intent, not the file.

Integrations are a YAML metadata file plus Python or JavaScript code. Python is preferred, new content should be Python 3, and Python 2 support for existing content ended 2025-10-01 (XSOAR code conventions) (read 2026-11-03). If your estate still has Python 2 scripts, they are already unsupported. Fix that before any migration, not during it.

The export path is thinner than you expect

We could not confirm a single-playbook export format for XSOAR 8 from official documentation read on 2026-11-03. What we found is narrower:

  • A pan.dev utility playbook, XSOAR - Export Selected Custom Content, builds a zip of chosen custom items for import on another XSOAR server. We saw it in a search summary, not on the opened page (pan.dev job reference) (read 2026-11-03).
  • A 2023 community post on version 6.12 says the docs describe a YAML import API for playbooks and no matching export API. That is a forum statement about one version, not documentation (Palo Alto community thread) (read 2026-11-03).

Plan on a rebuild, not an export. If your target vendor tells you it imports XSOAR files, ask for the file extension, the version it accepts and the list of what fails.

Vendor migration offers are claims until you see a parity report

Three sellers name XSOAR as a source. Read each as a sales position.

D3 lists XSOAR among six source platforms with published porting coverage. It says structure ports, custom code and anything without a Morpheus equivalent is flagged for human review, converted playbooks arrive in Deterministic mode, and no percentage is guaranteed (D3 playbook migration) (read 2026-11-03, vendor claim).

Swimlane says up to 90 percent of workflows migrate automatically, and a three-year agreement gives up to the first year free (Swimlane SOAR migration) (read 2026-11-03, vendor claim). The page does not describe workflow types or tooling.

Torq's own advice is redesign over lift and shift, with a proof of concept first. Its blog names no XSOAR converter (Torq blog, 2025-03-24) (read 2026-11-03, vendor claim). That is the most honest of the three, and it fits what the file formats allow.

Sort the estate into keep, translate and retire

Skip the idea of a single migration percentage. Sort every item.

  1. Retire. Playbooks that have not fired in a year, test playbooks, and duplicates built for a tool you no longer own. Measure it from run history, not from memory.
  2. Translate. Playbooks whose logic is a decision tree over tool calls. The intent moves: enrich, decide, notify, contain. Rebuild these in the target's editor and keep the XSOAR version running beside it.
  3. Keep, in place. Anything tightly bound to XSOAR objects, such as war room tasks, custom layouts and indicator types, and anything an audit needs unchanged. If the destination is XSIAM, packs may carry over. Otherwise these stay until XSOAR ends.

Then count the scripts. Python integrations move more easily than playbooks, because Tines, Torq and Splunk SOAR all run Python in some form. They still need new wrappers, new credentials handling and new tests.

Price the destination before you price the exit

None of the XSOAR pages we read publish a price. The product page offers an ROI calculator instead, and its pricing URL returned 404 on 2026-11-03 (Cortex XSOAR product page) (read 2026-11-03). Two counts also disagree. The home page states 900+ prebuilt integration and automation packs, and the Marketplace page states 850+ product integrations, both without a date (XSOAR Marketplace) (read 2026-11-03, vendor claim). When you size what you must rebuild, count your own used integrations from run history. Do not use either figure.

Our nine-criterion scoring puts Cortex XSOAR at 6.18 on pages read 2026-11-03. Approvals score 4.0 because we found nothing on them, and migration scores 6.0 because the pan.dev pages name the YAML content-pack format, though no leaving guide exists. That is a statement about the pages, not about the product.

Checklist before you sign anything

  • Record your exact XSOAR version and the end-of-life date for it.
  • Export run history and list playbooks that fired in the last 12 months.
  • Mark every playbook retire, translate or keep.
  • List scripts still on Python 2 and fix them first.
  • Inventory incident types, layouts and classifiers that have no target equivalent.
  • Ask each vendor for the source file format it accepts and the list of what does not port, in writing.
  • Ask for a parity report from replayed incidents, and a rollback path.
  • Count integrations you actually call, and check each exists in the target.
  • Set a parallel-run period that ends before your version's end-of-life date.