Cortex XSOAR 6 end of life: move to XSOAR 8 or replace

What the Cortex XSOAR 6 end of life deadline changes for your SOC

If your SOC runs Cortex XSOAR 6.12 or 6.13 on premises or in an air-gapped site, the June 30, 2026 end of life date forces a decision. You can upgrade within the 6.x line, move to Cortex XSOAR 8, or replace the automation layer with an open-source platform. Each path changes your change window, your integration rework and your audit evidence, so the choice should be made before the date, not after it.

Version 6.14 remains active, and Palo Alto Networks recommends it for on-premises and air-gapped sites. That makes an in-place move to 6.14 the shortest path if you need to stay on premises without rebuilding content. Confirm 6.14 support dates directly with Palo Alto Networks and ask for the end of life schedule in writing, because a later end of life date would change how long you can defer a larger migration. Also check whether your current integrations and content packs are supported on 6.14 before you schedule the upgrade.

In short, upgrading to 6.14 buys time with the least disruption, Cortex XSOAR 8 is available as SaaS or on premises if you want to stay on the vendor platform, and open-source options such as Shuffle or Tracecat suit teams that want to move playbooks out of a commercial product. This page compares those paths, covers what the deadline means for air-gapped sites and explains how to export your content before you decide.

What the end of life constraint requires from the platform

XSOAR 6.12 and 6.13 stop receiving support on June 30, 2026, so any destination has to be a release that stays supported, can run where your network requires, and keeps playbooks and credentials under your control. The cards below turn those needs into checks you can apply to XSOAR 8, XSOAR 6.14 and self-hosted alternatives.

A release that stays supported

Start by confirming which release line your vendor will support after your current version expires. Cortex XSOAR 6.14 remains active and is the version Palo Alto Networks recommends for on-premises and air-gapped sites, while XSOAR 8 is available as SaaS or on premises. Ask in writing for the support end date of each option, the upgrade path from 6.13 and whether custom content needs conversion before the move. Your own risk register should record the date the chosen platform stops receiving fixes.

Running disconnected

If the SOAR platform sits in an air-gapped network, the replacement must install and update without internet access. Tracecat documents an air-gapped Kubernetes deployment with no runtime internet access, and Shuffle supports Docker and Kubernetes installs, but apps and images must be loaded offline. Test the full install, a workflow run and an app update inside an isolated lab before you commit, and confirm which vendor components phone home for licensing or telemetry.

Playbooks and credentials inside your boundary

Confirm that workflow definitions, execution logs, case data and stored credentials all stay in infrastructure you operate. Shuffle keeps its OpenSearch document database and workers in your environment when self-hosted, and its hybrid mode lets a local Orborus run without inbound firewall ports. Document where each data class lives, who can read execution history and whether any cloud component receives incident data.

Exporting custom content

Before you sign anything, confirm you can take every playbook, script and integration out of XSOAR in a reusable form. In XSOAR 8, custom content can be exported from Server Settings and individual playbooks downloaded from the content item menu. Build an inventory that marks which items use XSOAR-specific runtime logic, since those will need rewriting rather than copying. Keep a dated export set as your rollback copy.

Single sign-on for analysts

Analysts should sign in with the same identity provider used across the SOC, not with local accounts that outlive their roles. Shuffle supports SAML single sign-on from version 0.9.16 and OpenID Connect from 1.0.0, with per-tenant enforcement, and is moving Shuffle Cloud toward OpenID Connect. Tracecat documents single sign-on as an Enterprise Edition feature, so confirm the edition and license cost before assuming it is available. Test group mapping and deprovisioning during the pilot.

A documented encryption secret

Stored app credentials and API keys need an encryption secret that is backed up and never rotated casually. Shuffle encrypts saved app authentications in OpenSearch with AES-256 using the SHUFFLE_ENCRYPTION_MODIFIER value, and the docs warn that losing or changing it breaks every saved authentication. Record where the secret is kept, who can read it, how it is restored into a rebuilt cluster, and how it is tested during disaster recovery drills.

How each option meets the deadline and what it costs you

This table compares five paths for Cortex XSOAR 6 users: staying on 6.14, moving to XSOAR 8 on premises or SaaS, and replacing XSOAR with self-hosted Shuffle or Tracecat. Read each row for how the option meets the support and air-gap requirement, then for the trade-offs and cost drivers that remain. Confirm vendor support windows and offline install steps in writing before you set a migration date.

Option	Deadline and air-gap fit	Trade-offs and cost drivers
Stay on XSOAR 6.14	Remains active and is the version Palo Alto Networks recommends for on-premises and air-gapped sites.	Confirm the 6.14 support window in writing. You still need a plan for the next move.
XSOAR 8 on premises	Installed with a step-by-step terminal installer, so it can run inside your own network.	Custom content must be exported and reviewed. Confirm the offline install and update process with the vendor.
XSOAR 8 SaaS	Hosted by the vendor, so it does not fit a disconnected or air-gapped site.	Suits teams that accept vendor-hosted operations. Confirm where data is stored and how it is protected.
Self-hosted Shuffle	Installs on Docker or Kubernetes with a minimum of 4 GB RAM. Confirm how apps load offline.	No built-in incident layouts or war room. The default Docker Compose setup needs changes to scale.
Self-hosted Tracecat	Documents an air-gapped Kubernetes deployment with no runtime internet access.	Cases are built in. Multi-tenancy and SSO are Enterprise Edition features under a paid license.

Does XSOAR 8 on premises keep the deployment model you have today?

If you run Cortex XSOAR 6 on premises today, the first question is whether XSOAR 8 keeps that model. Palo Alto Networks documents Cortex XSOAR 8 as available both as SaaS and on premises, and the on-premises version is installed through a step-by-step terminal installer. That means an on-premises move is possible on paper, but you still need to confirm the installer prerequisites, host sizing, and network rules for your environment before you commit to a date, and ask Palo Alto Networks to confirm them in writing for your version and sites.

Moving to XSOAR 8 on premises still means moving your custom content. Before any installation, export everything from Settings, then Server Settings, then Custom content, and select Export all custom content. For individual playbooks, use the content item menu to download each one. Keep these exports in a controlled location with a record of what was exported, because they are the baseline you will test against and the fallback if an import fails. Confirm with Palo Alto Networks which XSOAR 8 feature changes affect your playbooks, integrations and scripts by reading the Cortex XSOAR 8 feature changes documentation, and ask them to name any content that will not behave the same way after upgrade.

Treat the on-premises move as a decision with a clear owner, not a routine upgrade. Record which playbooks depend on integrations or runtime behavior that changed, which ones you would rebuild, and which ones you would retire. If the answers show that much of your content needs rework, the same export gives you the inventory you need to compare a replacement, such as Shuffle or Tracecat, on equal terms. Ask Palo Alto Networks for the licensing terms for on-premises XSOAR 8 in writing, since the subscription, support and renewal details are the vendor's to state.

How the choice changes by environment

Connected sites have the most options. XSOAR 6.14 is still active and is the version Palo Alto recommends for on-premises deployments, so a site already on 6.14 has time to plan. Sites on 6.12 or 6.13 must act before June 30, 2026, and can choose between an upgrade to 6.14, an on-premises XSOAR 8 install or a move to self-hosted open source. Both open-source options run on your own servers without a vendor-hosted control plane.

Upgrade within 6.x: Moving from 6.12 or 6.13 to 6.14 keeps existing playbooks and integrations in place and gives you time for a later decision. Confirm the upgrade path for your build with Palo Alto.
XSOAR 8 on premises: Palo Alto documents an on-premises XSOAR 8 installation through a step-by-step terminal installer. Confirm your hardware, database and content migration steps before scheduling.
Shuffle on Docker or Kubernetes: Shuffle installs on both platforms and needs at least 4 GB of RAM. The default Docker Compose setup is not scalable without changes, so plan a distributed or Helm-based deployment for production. See the Shuffle install guide.
Tracecat on Compose or Kubernetes: Tracecat supports Docker Compose on a single host and a Kubernetes Helm chart. Its stack includes PostgreSQL, Temporal and an S3-compatible object store, so confirm that your team can operate each component.

Check which integrations have vendor support on the target version and how many analysts depend on XSOAR incidents, since that determines how much of the incident layer you must replace.

How to move playbooks off XSOAR 6 before the deadline

This sequence turns an XSOAR 6 estate into a sorted inventory, a set of exported content and a per-playbook decision on where each automation goes, then moves them one use case at a time until 6.x can be shut down.

Inventory playbooks, integrations and scripts
The SOC lead and an XSOAR administrator list every playbook, integration, script and incident type in use, and record which SIEM, ticketing and cloud sources each one calls. Mark which items run on a schedule, which are triggered by incidents and which are dead. Confirm the list with the analysts who own each use case, since unused content is often the easiest to retire. Done when every active item has an owner, a trigger and a target decision field in one tracked sheet.
Export custom content from XSOAR 6
Using the export path in the XSOAR interface, the administrator exports all custom content and keeps a copy of each playbook and script as a file under version control. Record the exact version of XSOAR 6 used for each export, because the 6.12 and 6.13 releases reach end of life on June 30, 2026 and the 6.14 release remains active. Note that JavaScript integrations and logic tied to XSOAR's runtime will not transfer as-is and need manual rebuilding. Done when the archive opens and each item in the inventory matches a file.
Decide the target for each playbook
For each inventory item, the architect and the SOC decide whether it moves to Cortex XSOAR 8, Shuffle or Tracecat. Factors include whether the playbook depends on XSOAR incident layouts or the war room, whether the team wants a self-hosted tool with cases built in, and whether the content must run without internet access. Shuffle has no built-in incident layouts, so playbooks that rely on them need a companion system. Done when each item has one named target, a reason and an owner.
Rebuild integrations and secure the target platform
Integrations are rebuilt as Shuffle apps generated from OpenAPI specifications or written with the Shuffle app SDK in Python, or as Tracecat workflows and actions. Before any playbook runs, the platform team stores app credentials through the target's secrets handling, keeps Shuffle's encryption secret in a safe location and connects the platform to the identity provider for single sign-on. Confirm current SSO options with the vendor, since Shuffle's SAML support is being deprecated on its cloud service. Done when test credentials work from the target and an administrator can log in through SSO.
Run old and new side by side per use case
The team picks one use case, such as phishing triage or endpoint containment, and sends the same alerts to both XSOAR 6 and the target platform. Analysts compare outputs, enrichment results, ticket updates and error rates for a defined period agreed in the project plan. Discrepancies are logged and fixed before the next use case starts. Done when the outputs match the agreed acceptance criteria and the team signs off the use case in writing.
Cut over and decommission XSOAR 6
Once every use case has passed side-by-side testing, the team switches the alert sources to the new platform, disables the matching XSOAR 6 playbooks and keeps the archive as a read-only record for audit and rollback. Scheduled jobs and integration accounts are removed from XSOAR 6 and revoked. The decommission is recorded in the change log. Done when no active XSOAR 6 playbook is receiving alerts and the archive and change records are stored under retention rules.
Scope the effort in writing
Total duration depends on the number of playbooks, the number of integrations that need rebuilding, the number of use cases that need parallel running and the availability of analysts for testing. Ask any implementation partner for a written scope with named deliverables, acceptance criteria and a timeline tied to the inventory, and ask for the same from internal teams. Do not accept a duration that has not been tied to the inventory counts. Done when the agreed scope lists each deliverable, its owner and its sign-off point.

Evidence to keep for the migration record

Whichever path you choose, an auditor or board reviewer will want proof of what was running, what moved, what was tested and what was switched off. The cards below list the artifacts that connect the old XSOAR 6 estate to the new platform, so each one can be traced from the decision to the decommissioning. DeployOpen can prepare this evidence, while independent auditors and certification bodies issue any audit report or attestation.

Inventory of playbooks and integrations

A dated list of every playbook, script, integration instance and incident type on the XSOAR 6 servers, with the owner, the trigger source and the last run date for each. This is the baseline for scope: any item missing from it is a control that may silently stop working at cutover. Ask whether each entry is marked as migrated, retired, or accepted as a gap, and who signed that decision. Cross-check the list against what the export actually produced, since JavaScript integrations and runtime-bound logic often need manual handling.

Export archives and their checksums

The exported custom content and individual playbook files, stored with a checksum recorded at the time of export. In XSOAR 8, the export of all custom content and the per-playbook download are the documented routes, so record which route produced each archive. Store the archives in write-once or access-logged storage and keep a note of who handled them. Without matching hashes, you cannot later show that the file imported into the new platform is the one that was reviewed.

Deployment configuration and version pins

The compose files, Helm values, container image tags and host operating system versions for every new platform component, stored in version control. Pin versions explicitly and avoid floating tags such as nightly for production. Record the release used for the new platform and the date it was deployed, so the state can be rebuilt if an assessor asks how the environment was configured on a given day. Confirm the current stable tag with the vendor before you pin it.

Custody record for the encryption secret

Where the encryption secret that protects saved integration credentials is stored, who can read it, and the rotation history. In Shuffle, losing or changing the SHUFFLE_ENCRYPTION_MODIFIER secret breaks every saved app authentication, so the custody record is also a recovery record. Document the backup location, the break-glass procedure and the approval for any change. Test restoration in a non-production environment and keep the result with the record.

Side-by-side test results per use case

For each use case moved off XSOAR 6, the test plan, the test data used, the outcome from the old and new platforms, and the sign-off by the analyst or SOC lead who owns it. Results should cover triggers, enrichment calls, containment actions and failure handling, not only a successful run. Keep the test evidence tied to the inventory entry it proves, so a reviewer can follow a control from requirement to result.

Decommissioning record for 6.x servers

A record that each XSOAR 6.x server was stopped, its data backed up or retained under the approved schedule, its credentials revoked and its network access removed. Include the date, the person who performed each step and the verification that no triggers still point at the old server. Retained backups need a stated retention period and an owner. Ask your compliance lead which retention rule applies before the servers are switched off.

Questions buyers ask before moving off Cortex XSOAR 6

What drives the cost and effort of moving off Cortex XSOAR 6?

The main drivers are playbook count, the number of custom integrations, and the design of the target platform. Each playbook you rebuild takes analyst and engineering time. Each custom integration may need to become a Shuffle app, built from an OpenAPI specification or written with the Python app SDK. The second group is design: whether you need single sign-on, a highly available layout, an OpenSearch cluster, and shared file storage for several backends. The hosting choice also matters, because XSOAR 8 as SaaS, XSOAR 8 on premises, and self-hosted Shuffle or Tracecat each bring different cost lines. Ask every bidder to price these items separately, using your playbook and integration counts as the basis.

Which migration costs are one-time and which ones recur every year?

Migration work is one-time: inventory, rebuilding playbooks and apps, testing, SSO setup, backup design, runbooks and handover documentation. Recurring costs depend on the path you choose. The Shuffle open-source edition includes all features, but its paid tiers differ in limits, scaling and support, and since v2.1.1 those limits are enforced. Paid Shuffle licensing uses app runs as its metric. Recurring lines usually include servers or Kubernetes capacity, OpenSearch storage, backups, patching, upgrades and any support retainer. A commercial XSOAR 8 subscription renews on its own schedule. Ask each vendor or partner to state every recurring line with its unit and its driver.

Can our own team migrate Cortex XSOAR content without outside help?

Some teams can do parts of the work themselves, and the answer depends on your engineering skills and spare capacity. Exporting is straightforward: the XSOAR 8 documentation describes exporting all custom content from the server settings and downloading individual playbooks. Shuffle's App Creator can build integrations from OpenAPI specifications, and it ships premade apps for many security tools. The harder work is rewriting logic tied to XSOAR's runtime, rebuilding incident layouts and the war room (Shuffle has no built-in equivalent), and designing a highly available deployment. DeployOpen plans, implements, integrates, hardens, backs up, upgrades, documents and supports self-hosted platforms in your own infrastructure. Work is usually fixed-scope, so you can split tasks between your team and a partner.

How long does an XSOAR migration take and what does it depend on?

No duration applies to every estate, so treat any single figure with caution. Duration depends on playbook and integration counts, how many use cases must run side by side with XSOAR during cutover, and how quickly infrastructure, network access to target systems and SSO approvals become available. The end-of-life date of June 30, 2026 for XSOAR 6.12 and 6.13 sets an outer deadline for those versions. Ask for a timeline in the written scope with named milestones: inventory, a pilot use case, a parallel run, cutover and decommissioning. Also ask each bidder to list its assumptions, because most schedule slips come from those assumptions rather than from the coding work itself.

Is Cortex XSOAR 6.14 a safe bridge while we choose a platform?

XSOAR 6.14 stays active, and it is the version Palo Alto Networks recommends for on-premises and air-gapped sites, so it can work as a bridge if your support terms cover the period you need. Treat it as a bridge with a clear end date rather than as a long-term home. Confirm the support end date for 6.14 with Palo Alto Networks in writing, because this page does not state one. Upgrading within 6.x keeps your existing playbooks running, but it does not remove the need to choose a platform for the next several years. Set a decision date early, so the move does not coincide with the 6.12 and 6.13 end-of-life deadline.

What servers, memory and storage does a self-hosted Shuffle deployment need?

Shuffle's install guide sets a minimum of 4 GB of RAM and supports Docker and Kubernetes. The default Docker Compose setup is not scalable without changes, so production estates usually need a different layout. Shuffle documents four architectures: a single server with Docker Compose, distributed Docker Swarm, a hybrid with Shuffle Cloud and a local Orborus that needs no inbound firewall ports, and Kubernetes with Helm charts. For high availability, the docs recommend an OpenSearch cluster, optional Memcached, NFS for shared files when running several backends, and more than one Orborus node. OpenSearch holds the workflow and execution data, so storage needs depend on execution volume and retention. Confirm these figures during sizing in your own environment.

How do we protect saved credentials and single sign-on during the move?

Shuffle encrypts saved app credentials and API keys in OpenSearch with AES-256, using the SHUFFLE_ENCRYPTION_MODIFIER secret. The configuration docs warn that losing or changing this value breaks every saved app authentication, so store it in your secrets manager and include it in your backup and recovery plan. Shuffle supports SAML single sign-on from version 0.9.16 and OpenID Connect from 1.0.0, both on premises and in the cloud, with per-tenant enforcement. SAML is being deprecated on Shuffle Cloud in favor of OpenID Connect, so new designs should start there. Test credential migration in a non-production environment before you move any production integration.

What should a written scope include before we ask for a quote?

A quote is only comparable when every bidder works from the same written scope. Include a full inventory of playbooks, integrations, triggers and custom scripts, with the target platform and hosting model. State your high availability, SSO and backup requirements, and the method for migrating credentials, including key handling. Define the pilot use case, the parallel-run criteria, the acceptance tests and the cutover and rollback steps. Add the deliverables: runbooks, documentation and handover. Also cover support after handover, change control, and exclusions and assumptions. DeployOpen works from fixed-scope agreements, with scope, deliverables and timelines agreed in writing before work starts, and it does not publish a price list.

How DeployOpen plans a self-hosted SOAR move under a deadline

DeployOpen plans and implements self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For Cortex XSOAR 6 end of life, we start from your playbook inventory and the deadline, then agree in writing which path fits your environment before any build work begins.

How we scope

We inventory playbooks, integrations, scripts, incident types and the SIEM triggers that call XSOAR today.
We record which versions run in production and which sites are on premises, air-gapped or connected.
Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.

How we build

We rebuild priority playbooks in the target platform, such as Shuffle or Tracecat, or prepare an XSOAR 8 upgrade path.
We configure secrets handling, such as the Shuffle encryption modifier, and document where each credential is stored.
We test each workflow against sample alerts in a non-production environment before any cutover decision is made.

How we hand over

We deliver architecture notes, runbooks, a playbook mapping register and backup and restore procedures for the new platform.
We run parallel operation for agreed use cases and record where response results differ from XSOAR.
We document the decommissioning steps for XSOAR, including what content was exported and where it is kept.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
We can help you prepare control and evidence material for compliance assessments; independent auditors issue any audit reports or certifications.
Ask any provider, including us, to confirm the platform's current release, licensing terms and support window in writing before you commit.