The first mistake in a security tooling decision is treating “cybersecurity” as one market. It is seven: endpoint and XDR, SIEM, SOAR, MDR and managed services, network detection, vulnerability management, and threat intel. Each is billed on a different meter, each has a different failure mode at renewal, and the criterion that decides one is irrelevant to the others. A feature matrix spanning all of them is worse than useless, because it flattens the distinctions that matter.
So the framework here is deliberately staged. Work out which segment you are replacing, apply that segment’s decisive question, and only then look at products.
Step one: name the segment, and check the overlap
Write down what you are actually replacing. Then check whether the contract you are unhappy with spans more than one segment, because bundled platforms routinely do. An XDR licence that also provides log retention, a SIEM that includes a SOAR module, an MDR contract that bundles the endpoint agent underneath it: in each case, leaving one part means solving for the others.
Enumerate the modules and confirm, per module, who consumes its output and what process depends on it. Modules with no named consumer are the cheapest saving available and often need no migration at all.
The decisive question, per segment
Endpoint and XDR: do you need autonomous prevention? Not a preference, a design constraint. Most open destinations detect and respond by script rather than blocking at execution, which means the working architecture is layered: OS-native prevention underneath, open detection platform above. If your requirement is genuinely autonomous prevention with no human in the loop and no separate prevention layer, most of the open shortlist does not meet it. The notable exception is Elastic Security, whose endpoint integration includes blocking behaviour in the free tier. Decide this before you shortlist anything.
SIEM: what is each log source worth per gigabyte? Build a table of monthly ingested volume against detections contributed, per source. The answer usually reveals that a handful of sources carry the detections and a different handful carry the cost, which points at a partial migration rather than a platform replacement. This is also the segment where the incumbent’s own cheaper tiers may solve your problem with far less work, and taking that answer is a success rather than a failure of nerve.
SOAR: how many playbooks genuinely run? Pull execution counts. If the answer is a handful, a rewrite onto an open engine is a matter of weeks. If your analysts also work incidents inside the SOAR interface, you are replacing two products, orchestration and an incident workspace, and the workspace is the harder half.
MDR and managed services: what does the rota actually cost? Roughly five to six full-time people to cover one seat continuously across a year, plus a detection engineer, a platform engineer, and a lead. Model that first. If it exceeds the contract, the correct outcome is a renegotiation with a costed alternative in hand, or a hybrid where you build the platform and daytime team and contract only out-of-hours.
NDR: how much do you rely on unsupervised anomaly detection? Open network monitoring detects what someone wrote down: Suricata signatures, Zeek scripts, explicit rules. You gain inspectability and auditability, and you lose findings that come from a model noticing something nobody anticipated. If nobody will own detection engineering as a named, funded responsibility, do not go open in this segment.
Vulnerability management: who owns prioritisation and remediation workflow? Scanning is solved and largely open. The commercial value is in prioritisation, ownership, SLA tracking, and exception management. Replace the scanner without replacing that layer and remediation stalls. Also check what proportion of your estate is roaming or ephemeral, because network scanning does not cover what agents were covering.
Threat intel: are you buying a corpus or a platform? If the value is the vendor’s research, nothing is portable and open tooling does not replace it. If the value is managing indicators and relationships you gather yourself, STIX 2.1 makes this the most portable segment in security.
The cross-segment criteria
Once the segment question is settled, these apply everywhere:
- Detection-engineering capacity. Every open destination in every segment converts vendor-supplied content into your team’s ongoing responsibility. Score this honestly, by name, with a person attached.
- Operating burden and storage. Self-hosted security is a cluster with disks, capacity planning, and an on-call rota. The licence saving is real; the running cost is not zero.
- Compliance controls. If you are audited for file-integrity monitoring, configuration assessment, retention duration, or specific benchmark coverage, confirm the candidate satisfies the control directly rather than approximately, and confirm the report renders.
- Air-gap and data-residency requirements. These rule candidates in and out rather than scoring them. Several strong SaaS-only options are simply unavailable to some estates.
- What happens to history. Retention obligations, exception registers, and investigation records rarely travel. Decide per source and per record type what you export, what you archive, and what you accept losing, before notice is served.
The traps
Retiring a prevention capability with nothing filling the role. Assuming one open tool replaces a bundled platform’s several modules. Migrating detection content nobody has examined and inheriting its noise. Treating the workflow layer, cases, prioritisation, ownership, as a later phase when it is frequently what the commercial product was really selling. Underestimating storage for self-hosted detection. And comparing an alternative against a guess rather than against the incumbent’s actual renewal quote, which leaves the savings case ungrounded.
Pressure-test before you retire anything
Whatever the segment, the acceptance pattern is the same: run both, on identical input, for long enough to see a month-end and a peak. Write the acceptance criteria before the pilot rather than after. Compare in both directions, since findings the new platform raises and the incumbent did not are as informative as the reverse. And retire the incumbent incrementally, per ring, per log source, per scan group, never estate-wide on a date.
Get the incumbent’s renewal number in parallel, and model the per-endpoint comparison at /calculator/, remembering that it normalizes every segment onto one unit so they can be compared at all. Choose the option that clears your acceptance criteria and closes the specific gap your segment’s decisive question exposed, not the one with the lowest line item.