From IBM QRadar SIEM to Wazuh

QRadar’s licensing model is the reason most teams start looking. Paying by events and flows per second means the verbose, security-relevant sources (endpoint telemetry, authentication logs, DNS) are exactly the ones that push you into the next tier, so the licence actively discourages the logging you should be doing. Add an appliance estate on a hardware refresh cycle and a support renewal on top, and the total is rarely what anyone budgeted. Wazuh replaces the log-analytics and correlation half of QRadar for the cost of the infrastructure. It does not replace the flow-analytics half, and that asymmetry should shape the entire project.

Split the platform in two before you plan anything

QRadar is really two products sharing a console. One ingests logs through DSMs, normalizes them into a common event taxonomy, and evaluates rules written in AQL. The other ingests NetFlow, IPFIX, and QFlow, builds a picture of who talked to whom, and detects on network behaviour.

Wazuh is a complete answer to the first half and no answer at all to the second. So the first planning task is to sort every detection you care about into one bucket or the other. Log-driven detections migrate to Wazuh. Flow-driven detections need Zeek, Suricata, or an assembled distribution such as Security Onion, running alongside and shipping into the same indexer so analysts still get one place to look.

Teams that skip this split discover it halfway through, usually when someone asks why lateral-movement detections went quiet. Do it on paper in week one.

The mapping

• QRadar agents and syslog collection → Wazuh agents, syslog listener, or Filebeat.
• DSMs and custom property extractions → Wazuh decoders (parent decoder on the log prefix, child decoders for fields).
• The QRadar Identifier taxonomy → Wazuh rule groups and static field mappings, which are looser and less prescriptive.
• AQL correlation rules → Wazuh rules, with frequency, timeframe, and same_source_ip-style options for stateful logic.
• Building blocks → rule inheritance via if_sid and if_group.
• Reference sets → CDB lists.
• Offenses → alerts plus an external case platform (TheHive or equivalent); Wazuh has no offense-magnitude concept.
• QFlow / NetFlow analytics → Zeek and Suricata, as a separate deployment.
• QRadar Risk Manager and Vulnerability Manager → Greenbone or your existing scanner, feeding Wazuh’s vulnerability detector.

Offenses are the workflow you will miss

QRadar’s offense model is genuinely good and genuinely proprietary. Related events are grouped into a single offense, given a magnitude score that combines credibility, relevance, and severity, and then worked as one unit that accumulates evidence over time. Analysts triage a queue of offenses, not a firehose of alerts.

Wazuh has no equivalent. It produces alerts with severity levels. Aggregating those into something an analyst works as a case is your job, and it is the part of the migration most likely to be underestimated because it is workflow rather than technology. The standard open answer is TheHive for case management, with alerts flowing in from Wazuh and enrichment from Cortex analysers or MISP. Stand that up during the build phase, not after cutover, and get your analysts working in it while QRadar is still running so the muscle memory transfers before the safety net goes.

Also plan the magnitude question deliberately. Wazuh rule levels are a blunter instrument than QRadar’s three-factor scoring, so decide early whether you replicate prioritisation in the case platform, in rule-level discipline, or simply accept a coarser scale.

Rebuilding detection content without carrying the dead weight

Export your enabled rule list and, more importantly, your offense history. The rules that have generated offenses a human closed with a real disposition are your migration scope. Everything else is a candidate for deletion.

Then work through them in order of value. AQL rules translate to Wazuh rules conceptually rather than syntactically: the condition, the threshold, and the grouping key transfer, the language does not. Stateful rules (this event N times in M minutes from the same source) map onto Wazuh’s frequency, timeframe, and same_field options fairly directly. Rules that join across data sources at query time are harder and sometimes need restructuring into a chain of rules with an intermediate CDB list acting as state.

Test every rule against replayed production events. QRadar’s normalized taxonomy means your rules were written against clean, consistent fields; Wazuh rules fire against whatever your decoder produced, so a decoder bug and a rule bug look identical from the console. wazuh-logtest distinguishes them, and it should be the first thing every detection engineer learns.

Order of operations

1. Sort detections into log-driven and flow-driven, and scope the flow replacement separately.
2. Pull the offense history and use it to decide which rules migrate and which get retired.
3. Build the Wazuh cluster, sized on daily indexed volume and hot retention, potentially on rebuilt QRadar appliance hardware.
4. Port DSMs to decoders, one log source at a time, validating each against real production samples.
5. Reimplement rules, then reference sets as CDB lists, then wire alerts into the case platform.
6. Deploy Zeek and Suricata for the flow-driven coverage, feeding the same indexer.
7. Parallel-run with both consoles live, comparing offenses against alerts daily and closing every discrepancy.
8. Decommission event processors in waves, retiring the licence tier as EPS drops rather than all at once.

Clearing the bar before you cut over

Every migrated rule has fired correctly against replayed production data. Every decoder has been validated on live samples from that specific source. Flow-driven coverage exists in Zeek or Suricata and has been tested independently. Analysts have worked real cases in the new workflow while QRadar was still authoritative. Compliance and audit reports render with the evidence your last audit asked for. And the EPS reduction is documented, because that is the number that justified the project.

The short version

QRadar to Wazuh trades an EPS licence and an appliance refresh for a cluster you operate and a flow-analytics gap you fill separately. The log-analytics migration is well-understood work: DSMs become decoders, AQL becomes rules, reference sets become CDB lists. The two things that sink projects are assuming Wazuh covers network flows and assuming alerts are a substitute for the offense workflow. Plan both explicitly, use the calculator above for illustrative per-endpoint economics, and count the second open deployment and the case platform as part of the cost rather than extras.