How the portability matrix is built

Reads in the matrix were made on 2026-11-03 and 2026-11-04; each cell carries its own date.

What the matrix is

For nine source platforms (Cortex XSOAR, Splunk SOAR, Swimlane, Torq, Tines, D3 Security, Google SecOps SOAR, Microsoft Sentinel automation, ServiceNow Security Operations) and eleven targets (the same platforms except ServiceNow, plus Blink Ops, Mate Security, and agentic platforms in general), it records for seven playbook types whether the work can move and what documentation says so. 693 cells, of which 56 are same-platform pairs marked not applicable.

The four verdicts

• moves with tooling: a vendor states an importer or converter for this source into this target, and that statement names the source.
• moves with rework: a vendor page that names the source documents a path but the page says, or the gap implies, that people must redo part of it (custom code, schedules not mentioned, case data but not logic).
• rebuild from scratch: no documented path on the read date. The reason says "no documented path on 2026-11-03" and names the source format and what the target does not document.
• not applicable: source and target are the same platform.

What counts as a documented path

In rank order: a documented importer in the target's technical docs; a documented export format in the source's docs that the target documents importing; a vendor migration guide read in full; a partner migration service page; a vendor statement on a marketing page that names the source. A source's export format alone does not make a path, because the target must also read it. The absence of all of these is recorded as rebuild, and that is a finding, not a gap in the research, except where the notes below say a search was not run.

The rule, applied to every target alike: a cell is moves with rework only when a vendor page that names the source platform documents the path and the cell cites that page with the date read, so Mate's unnamed-source claim is rebuild while Microsoft's dated Splunk SOAR guide is rework.

Result in this refresh: no cell rests on a technical importer document. Of 637 applicable cells, 64 have a path and 573 are rebuild. The 64 are 56 cells from vendor marketing pages that name the source (D3 28, Swimlane 21, Blink 7), 7 cells from Microsoft's Splunk SOAR to Sentinel guide (updated 2026-08-12, read 2026-11-04), and 1 cell from a Tines library story. Mate's claim that it translates SOAR playbooks names no source or format, so its 63 cells are rebuild with the claim recorded as a vendor claim. Treat all of them as claims to test in a proof of concept.

The seven playbook types and why

1. Enrichment lookups: the commonest first automation, mostly read-only calls.
2. Phishing triage: the standard multi-step case with parsing, detonation and user comms.
3. Endpoint containment: write actions with approvals, tied to one EDR API.
4. Identity actions: disable, reset and revoke against directory services.
5. Ticketing and case sync: two-way state with an ITSM tool, where schemas differ.
6. Custom scripted logic: code written in the platform's scripting language.
7. Scheduled or batch jobs: non-alert-driven runs such as hunts, reports and clean-ups.

They span read, write, state and code, and are the types migration pages most often mention or omit.

Cell rules

• Where a vendor page names a source, enrichment, phishing, containment, identity and ticketing take the stated verdict; custom logic and scheduled jobs are set to rework because those pages say custom code is flagged for people and do not mention schedules.
• Mate's pages name no source or format, so every source gets rebuild for every type, with the unnamed translation claim recorded in the reason.
• Agentic platforms in general: rebuild for every source, because no other agentic platform with a documented import was found in the searches run.
• Splunk SOAR to Tines ticketing is rework because a Tines library story moves case records, not logic.
• Splunk SOAR to Microsoft Sentinel is rework for all seven types because Microsoft's guide maps Splunk components to Sentinel and Logic Apps; it names no converter, and it does not mention schedules or case record transfer.

What the matrix does not measure

Effort or hours, licence or services cost, data fidelity after conversion, integration parity (whether a connector exists in the target), the quality of any vendor tool, or runtime behaviour. A moves-with-tooling cell does not mean it works. A rebuild cell does not mean it is hard.

How to read a row

Read the source's row left to right. A column with all rebuild cells means no documented path. Count cells with a path per row in the dataset, then check the evidence field: vendor_claim_importer is a vendor boast, vendor_claim_unnamed_source means the vendor claims an importer but names no source, none means absence. Open the source URL in each cell for the page behind it.

Limits of this edition

• The research pass ended before targeted searches for migrations into Google SecOps SOAR, Sentinel, XSOAR and Splunk SOAR, and for partner migration pages. Those columns are rebuild with "no documented path on 2026-11-03", which means not found, and should be re-searched; the one exception is Microsoft's Splunk SOAR to Sentinel guide, read in full on 2026-11-04.
• Several pages were read only as search-result summaries (marked as a search summary in the source notes): docs.splunk.com returned 403, docs.d3security.com and the Swimlane Turbine page returned 404, Cyware's page returned an empty shell.
• Torq's guide is behind a form and was not read. Tines' original blog was read through a third-party summary.
• Mate has no public technical docs; its facts are marketing, blog and trade press.
• Community converters on GitHub: repository search returned none relevant.