Most category pages on this site cover one product class. This one covers seven, because “cybersecurity spend” is an accounting convenience rather than a market. An endpoint agent billed per device, a SIEM billed per gigabyte ingested, a SOAR billed per playbook run, a managed SOC billed per endpoint or, for the co-managed-SIEM kind, per gigabyte ingested, and a network sensor billed per Gbps inspected have almost nothing in common except the budget line they land on. They also fail at renewal in completely different ways, which is why the exit plan for each looks different.
What follows is what changes per segment, and the four things that hold true across all of them.
What is constant across every security migration
Coverage cannot drop. Every other category on this site tolerates a maintenance window. Security does not, which is why these migrations run as a ringed rollout with an extended dual-run rather than a cutover. You run both systems, you compare what each detects, and you retire the incumbent only from the rings, segments, or log sources where the replacement has been proven.
Detection content is the real asset, and it does not export. Whatever the segment, the thing that makes a security platform work is the accumulated rules, signatures, queries, tuning, and exclusions written for your specific environment. Almost none of it transfers between products. Budget the migration as a content-rebuilding exercise, not a deployment.
Audit what actually fires before you cost anything. In every segment, the gap between what a platform contains and what it does is enormous. Rank rules, playbooks, and log sources by how often a human acted on their output in the last year. The head of that distribution is your migration scope. The tail is a retirement decision you should record with an owner and a date, because deleting unexamined content is an improvement rather than a compromise.
The saving is smaller than the licence, and the operating cost is real. Self-hosted security platforms trade a licence line for storage, compute, and people. That trade is often strongly favourable, but any business case built on “the software is free” has already gone wrong.
Endpoint protection and XDR
The agent on the device. Billed per endpoint with per-module SKUs on top, so the bill grows on two axes.
The defining constraint is that most open destinations detect but do not autonomously prevent. Wazuh gives you rule-driven detection, file-integrity monitoring, configuration assessment, and scripted active response, and it is excellent at all of that, but it will not block a threat at the moment of execution the way a commercial next-gen EDR does. The working architecture is layered: OS-native prevention on the endpoint, with the open platform as the detection and response brain above it. Decide that split before deploying anything, and confirm the prevention layer is live on a host before removing the incumbent agent from it.
The exception worth knowing is Elastic Security, whose Elastic Defend integration does include blocking behaviour in the free tier, which makes it one of the few open destinations that does not force the layered compromise.
SIEM and log analytics
Billed on how much you send it, which puts the security team’s instinct in permanent conflict with the budget.
Two things make SIEM migrations distinctive. First, the migration is never the log data, which exports fine, it is years of accumulated correlation content written in a query language nothing else speaks. There is no SPL-to-anything converter, no AQL converter, no KQL converter, and there will not be one.
Second, partial migration is often the right answer and it is rarely considered. Log sources vary wildly in alerts-per-gigabyte: a handful of sources produce almost all detections and very little volume, while firewall, proxy, and DNS logs produce most of the volume and almost no detections. Moving only the high-volume, low-signal sources to a self-hosted platform cuts the bill substantially without touching the part of the platform that works. Build that value-per-gigabyte table before deciding anything.
SOAR and security automation
Billed per seat or per execution, which means the better your automation works, the more it costs.
Playbooks are the least portable content in security. They reference integration commands, incident fields, and automation scripts that exist only inside one platform, so migration is a rewrite. The scope is set by how many playbooks genuinely run, which is usually a handful: phishing triage, enrichment, containment, and ticketing.
The specific discipline this segment demands is shadow mode. A SOAR is the most dangerous system in a security stack because it acts. Every rebuilt workflow should run read-only first, logging the action it would have taken, compared against the incumbent, before it is granted permission to isolate a host or disable an account. Then write access one action at a time, each with its own narrowly scoped credential.
MDR, MSSP, and SOC-as-a-Service
The one segment where you are not buying software at all.
Watch which meter runs, because the segment splits in two. Endpoint-centric MDR (Falcon Complete, Huntress, Sophos MDR) is billed per endpoint or per asset. Co-managed SIEM and SOC-as-a-Service, where the provider runs a SIEM on your behalf (Securonix, Exabeam, LevelBlue, ReliaQuest, and the Splunk- or Sentinel-based MSSPs), are usually billed by data ingestion, per gigabyte per day, the same meter that makes standalone SIEM renewals sting. If your provider is charging by ingest, the cost-control levers are the SIEM ones (audit which log sources actually earn their keep) as much as the staffing ones.
Leaving is an insourcing decision, and the arithmetic is unforgiving: covering a single seat continuously across a year takes roughly five to six full-time people once leave, sickness, training, and turnover are accounted for. That is one analyst on shift at any moment, with no depth. Add a detection engineer, a platform engineer, and a lead.
Run that calculation before anything else, because for many organisations the honest conclusion is that insourcing costs more than the contract, and the correct output of the exercise is a renegotiation backed by a credible plan. Where a full exit does not pay, the hybrid usually does: build the platform and a daytime team in-house, and contract only nights and weekends, since out-of-hours coverage is what multiplies the headcount.
Whichever way you go, extract the provider’s accumulated tuning and investigation history while the relationship is good. Detection exclusions, asset inventory, and closed-investigation records represent months of work about your specific environment, and a request made after notice is served rarely gets an enthusiastic response.
Network detection and response
Detection from traffic rather than agents, which is how you cover appliances, OT, and anything that will never run an endpoint agent.
This segment is unusual because the open engines are the incumbents: Zeek and Suricata sit inside a large share of commercial NDR products, which makes some exits remarkably short. The genuine capability gap is unsupervised anomaly detection, the self-learning model that flags something nobody wrote a rule for. Open stacks detect through explicit, inspectable logic instead. You gain auditability and lose a class of finding, and that trade should be stated plainly rather than glossed over.
The practical advantage is that tapping infrastructure is vendor-neutral. A packet broker can feed the incumbent and the replacement byte-identical traffic, which makes a long, rigorous side-by-side comparison both possible and mandatory.
Vulnerability management
Billed per scanned asset, including short-lived cloud instances that existed for an afternoon.
Scanning is a largely solved and largely open problem. What commercial platforms actually sell is the layer above it: prioritisation, ownership, SLA tracking, exception management, and the reports an auditor recognises. Replace the scanner and forget that layer, and you hand the infrastructure team a flat list of several thousand CVSS-scored findings, which is how a remediation programme stalls within two quarters.
Plan the prioritisation replacement explicitly, whether that is asset criticality plus CVSS, enrichment against public exploited-vulnerability catalogues, or an open workflow platform such as DefectDojo. Also check your ephemeral and roaming estate, because network scanning does not cover what agents were covering.
Threat intel and case management
The one genuinely portable segment, because STIX 2.1 and TAXII are real standards that commercial and open platforms both implement.
Indicators, actors, campaigns, and the relationships between them export and import faithfully. What does not travel is platform-computed confidence scoring, analyst annotations in proprietary fields, and the change audit trail. And most of what a threat-intel platform holds came from feeds it subscribed to on your behalf, so the right move is re-subscribing those feeds at source rather than importing a snapshot that starts decaying immediately.
Where these projects usually go wrong
Agent conflicts, when two security agents with kernel-level components share a host, which is why the pilot ring has to cover every OS build rather than a convenient sample. Underestimating storage, because self-hosted detection converts a licence into disks and someone to look after them. Migrating unexamined content and inheriting its noise. And treating the workflow layer, cases, prioritisation, ownership, as optional, when it is frequently the thing the commercial product was really selling.
Use the TCO calculator to model a per-endpoint comparison, remembering that it normalizes every segment onto one unit so they can be compared at all. Then subtract the infrastructure, the detection-engineering time, and where relevant the analyst rota that the incumbent was quietly covering.