Leaving Wazuh is an operations decision, not a feature comparison. The licence is free and the detection content is yours to edit, so what you are weighing is server capacity plus engineering hours against a subscription. Answer a few questions first — who owns the deployment today, how many of your custom rules actually fire, what retention you are obliged to keep — and the decision usually makes itself.
What does running Wazuh actually cost you?
A deployment has four parts, per the components documentation: the agent on each endpoint, the Wazuh server, the Wazuh indexer and the Wazuh dashboard. Three of them run on infrastructure you size, patch, back up and upgrade.
The published figures give you a floor. Wazuh recommends 16 GB of RAM and 8 CPU cores for the indexer (minimum 4 GB and 2 cores) and 4 GB with 8 cores for the server (minimum 2 GB and 2 cores). Storage scales with retention, not endpoint count alone: the install guide's own example puts 80 workstations, 10 servers and 10 network devices at roughly 231 GB for 90 days of alerts (1.5 GB per workstation, 3.7 GB per server, 7.4 GB per network device). Keep a year and the same estate needs about four times the disk.
Capacity is not a one-off check. The server exposes two state files — /var/ossec/var/run/wazuh-analysisd.state for dropped events and wazuh-remoted.state for discarded agent messages — and the documented response when either rises above zero is to add cluster nodes. Someone must watch them.
Upgrades are the cost most often underestimated. The upgrade guide requires all central components to run identical version numbers including the patch level, with the manager the same version as the agents or newer. That is a planned window across three services. The indexer also tracks OpenSearch rather than Elasticsearch: release 4.12.0 upgraded it to OpenSearch 2.19.1, and those notes state the indexer cannot be downgraded afterwards. The current branch is 4.14.x, with 4.14.8 released on 23 September 2026.
Tuning never finishes either. Your own detections live in local_decoder.xml and local_rules.xml, with IDs reserved in the 100000 to 120000 range, and that knowledge tends to live in one person's head.
What do you lose if you leave?
Five things go with the migration, and all of them are real. The free licence: Wazuh describes itself as a free and open source security platform that unifies XDR and SIEM capabilities, so a commercial product replaces a zero licence cost with a per-endpoint or per-environment one. Direct access to the data store: with your own indexer you query the indices yourself, without filing a request. Your decoders: XML decoders you wrote for a firewall, a point-of-sale system or an industrial appliance do not transfer, so confirm the replacement parses those exact sources before cut-over. Configuration as files: ossec.conf, rule files and agent groups sit in version control and review like code, where most managed products give you a console. Reading every rule that fires: with a maintained catalogue you rely on someone else's content, which is what you are paying for and still a trade.
What do you operate yourself, and what does a managed product operate?
Wazuh publishes the split for its own hosted service, a fair template for managed SIEM generally. The Wazuh Cloud documentation says Wazuh handles hosting, maintenance, infrastructure monitoring, scaling, high availability, platform security and version upgrades, while you keep agents, custom rules, integrations, user access and incident response.
| Task | Self-hosted Wazuh | Managed product (including Wazuh Cloud) |
|---|---|---|
| Hosting the central components | You size, install and maintain them. | The vendor hosts, deploys and maintains them. |
| Scaling and high availability | You add nodes when the state files show drops. | The vendor monitors, scales and provides HA. |
| Version upgrades | You, in lockstep, in a maintenance window. | The vendor ships updates and upgrades. |
| OS and platform patching | Yours, including the indexer hosts. | The vendor secures the underlying platform. |
| Retention and disk | Your storage bill, sized from alerts per second. | In the subscription; check the ceiling and the overage. |
| Agent deployment and configuration | Yours. | Still yours. |
| Custom detections and integrations | Yours, in XML. | Still yours, in the product's own format. |
| Access control for your users | Yours. | Still yours. |
| Triage and incident response | Yours. | Still yours, unless you buy a monitored service. |
Read the right-hand column twice. A managed product changes who runs the plumbing, not who makes the detections match your environment. Our Wazuh alternative page draws the same line row by row.
Which questions should you answer before deciding?
- Who owns the deployment, by name? If the answer is "whoever has time", the problem is ownership rather than tooling, and a managed product treats the symptom.
- How many of your custom rules actually fire? Count distinct rule IDs in the alert index over 90 days, separating your 100000-range rules from the bundled set. Usually far smaller than the rule count in the files.
- Which log sources do you depend on? List every source with no alerts and no searches in 90 days. Removing those changes your storage maths either way.
- What retention do you really need, and for what? Audit evidence can sit in cold storage; only the investigation window has to be searchable, and that window drives indexer cost and what a SIEM and search subscription is priced on.
- Do you need endpoint response, or only detection? Wazuh active response runs scripts on the host, triggered by rules. Isolate, kill process and quarantine from a console with approval is a different requirement — see what an EDR module covers.
- Where do your incidents actually start? If most of them begin in Microsoft 365 or Google Workspace, a host-agent SIEM is the wrong centre of gravity and no amount of rule tuning fixes that.
- What breaks if the SIEM is unavailable for a day? If nothing urgent does, you do not need a multi-node indexer on either side of the comparison.
- What does today's setup cost per month in hours? Upgrades, tuning, disk growth and agent troubleshooting at a loaded rate, plus the server bill. Until you have that number you cannot tell whether a per-endpoint price is cheap. Ask the new vendor the exit question too: can you export detections and raw events, in what format, and for how long after the contract ends.
How does a parallel run work, week by week?
Running both side by side is the only way to answer the parity question with evidence. Six weeks is a realistic shape for a few hundred endpoints:
Week 0 — baseline. Record alerts per day per rule ID, the active log sources, the agents disconnected for over a week, and your current false-positive rate. Without it you cannot tell whether the replacement is better or merely different.
Week 1 — dual ingest on a pilot group. Twenty to forty endpoints covering each operating system and role, including one noisy server. New agent beside the Wazuh agent, the same syslog sources at both collectors, nothing switched off.
Week 2 — detection parity. For every rule that fired in the baseline, mark the new product covered, covered differently, or not covered. The not-covered list is the real decision input, and a better thing to put to a vendor than a feature matrix.
Week 3 — noise. Tune false positives on the pilot group, comparing against your tuned Wazuh rather than a fresh install.
Week 4 — response and permissions. Take one incident end to end as a tabletop or a safe simulation: alert, triage, containment, closure. Check who may isolate a host and whether approval is required.
Week 5 — routing cut-over. Paging and ticket creation move to the new product while Wazuh keeps ingesting silently. Set the rollback trigger before you start: a missed detection class, an ingestion gap beyond an agreed number of minutes, or a false-positive rate over threshold.
Week 6 onward — wind-down. Keep Wazuh read-only until your retention obligation expires, and restore one indexer snapshot and search it before deleting anything. Do not stretch the parallel run: two agents on one endpoint means two sets of exclusions and double the CPU. Historical alerts are rarely worth importing — keep the old data queryable where it is.
When should you stay on Wazuh?
Staying is the right call more often than a comparison page admits. Stay if an engineer owns the deployment by name, with hours actually allocated, and someone else can take over. Stay if your use cases are log collection, file integrity monitoring, configuration assessment and compliance reporting, which is the ground Wazuh was built for. Stay if you have decoders for sources no commercial parser handles. Stay if your alert volume fits on a single indexer node, because that is where self-hosting is genuinely cheap.
Move if nobody owns it and upgrades keep slipping, if the alerting has never been tuned and nobody has time, or if you need endpoint containment, email protection and identity signals in one place — the gap a small-team SIEM has to close when there is no dedicated analyst.
There is also a middle option that gets skipped. Wazuh Cloud keeps your ruleset, your agent and your skills, and moves only the infrastructure. If the problem is the indexer cluster rather than the product, that is a much smaller change than a migration.
Do the counting first. The teams who regret this decision compared a licence price with a subscription price and left the hours out of both columns.