When IBM QRadar or Wazuh fits your IBM QRadar renewal
If your QRadar renewal is forcing a choice, the first question is whether you are buying a packaged SIEM or a platform you will operate yourself. QRadar on premises fits best when your team already depends on its packaged content, DSM coverage for the log sources you run, and a vendor support contract that your auditors and security operations leadership expect. Its appliance or software model suits organizations that want IBM to own the detection content lifecycle and that can absorb the licensing for events per second (EPS), flows per minute, or Managed Virtual Servers (MVS). If your priority is keeping that support relationship, confirm with IBM which QRadar on premises features and support terms apply to your license tier, since IBM continues to supply them after the QRadar SaaS assets moved to Palo Alto Networks.
Wazuh fits best when the main job is endpoint visibility and you want no SIEM license fee. Its agents collect logs, file integrity data and software inventory from Linux, Windows and macOS endpoints, and its server applies decoders and rules to that data. The software is distributed under the GNU General Public License version 2, so you can run it on hardware you own or in a cloud account you control. Wazuh also covers agentless devices such as firewalls through syslog, and it provides prebuilt dashboard views for frameworks including PCI DSS, GDPR, HIPAA and NIST 800-53. The trade-off is that you own the indexer, server and tuning work, so the decision depends on whether your staff can run that stack.
The decision turns on four facts you can measure before you talk to any vendor: sustained event rate, endpoint coverage, network flow needs and in-house staffing. Pull your current EPS and flow figures from QRadar and compare them with the sizing guidance for each Wazuh component. Count the endpoints that need an agent and check whether your operating systems are on the supported list. If you depend on network flow analysis or full packet capture, Wazuh alone does not replace that, so plan a separate sensor. Finally, estimate how many engineers can write decoders, tune rules and handle upgrades. If that answer is zero, a support contract or a managed partner changes the cost picture more than the license does.
Which platform suits which scenario
This table maps common situations, such as a renewal with a fixed EPS tier or an air-gapped site, to the platform that usually fits better and the condition that drives the choice. Read each row against your own event rates, deployment constraints and in-house skills, since the answer often turns on one condition rather than general preference.
| Scenario | Better fit | Condition that drives the choice |
|---|---|---|
| Renewal with a fixed EPS tier | Wazuh | The EPS tier is priced per event rate, so a self-hosted stack removes the license line but adds sizing, storage and staff time that you must cost out. |
| Endpoint-heavy estate with many Windows, Linux and macOS hosts | Wazuh | Wazuh agents collect logs, inventory and file integrity data from endpoints and manage their configuration remotely from the server. |
| Network flow-heavy estate | QRadar, or Security Onion alongside Wazuh | QRadar licenses flows per minute and has built-in flow analysis; Wazuh is log and endpoint focused, so flow visibility needs a separate sensor layer. |
| Air-gapped sites | Wazuh | Wazuh documents an offline installation path and an offline vulnerability repository, but you must confirm which QRadar appliance and update workflows work in your isolated network. |
| Teams without dedicated SIEM engineers | QRadar, or a managed Wazuh partner | QRadar ships with prebuilt content and vendor support, while Wazuh requires your team or an outside provider to tune rules, decoders and upgrades. |
| Compliance reporting against PCI DSS, GDPR, HIPAA or NIST 800-53 | Either, after a content check | Wazuh dashboards include prebuilt compliance views; confirm that the mapping covers your specific control set before relying on it. |
| Existing QRadar content and custom rules | QRadar until migration is planned | Rebuilding offense rules and building blocks as Wazuh rules takes effort, so migrate only after you inventory the content you actually use. |
| Need for vendor-backed support contracts | QRadar | IBM QRadar on-premises customers keep receiving IBM support; Wazuh support depends on the subscription or partner you choose, so confirm terms in writing. |
How licensing and deployment differ in practice
QRadar on premises is licensed against the volume of data it handles, and the metric in your agreement determines how you size the platform. Ask IBM which model applies to each component, because the same environment can produce very different license requirements under each one.
- Events per second (EPS): Licensing counts the rate of events the system processes. Capacity planning starts from peak event rates measured at the collectors, so burst periods matter as much as the daily average.
- Flows per minute (FPM): Network flow records carry their own meter, so flow volume may need a separate sizing exercise from log volume.
- Managed Virtual Servers (MVS): Licensing is tied to the virtual machines that run QRadar components, so your cluster layout affects the license footprint.
- Appliances: Hardware appliances bring their own sizing, support terms and refresh cycle, which you should map against your budget calendar.
Confirm with IBM which metric applies to each component, how peaks are counted, whether licenses are term-based or perpetual, and which support renewal costs appear in your quote.
Wazuh is free, open-source software licensed under GPLv2, so the software carries no license fee and no event-rate meter. Costs move to infrastructure, storage, staff time and any outside support you choose to buy. Capacity planning becomes a question of how much data the indexer and server can hold and process on hardware your team controls.
- No license meter: Event volume does not trigger a license tier, so growth appears as storage and compute rather than as a new license line.
- Storage: Alerts are stored in the Wazuh indexer, so retention period and daily data volume drive disk size.
- Compute: The Wazuh server analyzes agent data with decoders and rules, and it can run as a cluster to scale horizontally.
- Outside support: Vendor support and managed options such as Wazuh Cloud are optional purchases, and each should be priced separately from the software.
Ask any support or hosting provider which services they quote separately, and confirm which parts of your estimate are one-time costs and which recur each year.
QRadar is available as hardware appliances and as software for virtual machines, and each model changes how you buy, refresh and expand the platform. Wazuh runs on servers and virtual machines you select, so the unit of growth is a host your team already manages. The difference shows up most clearly in hardware refresh and in how many nodes you add over time.
- Appliance refresh: Hardware appliances reach end of life on their own cycle, so plan replacement alongside support renewals.
- Software sizing: The Wazuh indexer, server and dashboard are separate components, so you size each tier and add nodes in steps that match growth.
- Clustered server: The Wazuh server can run as a cluster for horizontal scaling, which spreads analysis load across hosts.
- Standard images: Wazuh agents and servers can follow the same image, patching and change processes as your other infrastructure.
Confirm with IBM which QRadar components are sold as appliances, which run as software, and which hardware generations each appliance model supports before you plan a refresh.
Wazuh documents several installation targets, including a prebuilt OVA virtual machine, an Amazon Machine Image, Docker and Kubernetes. Each suits a different platform team, and the choice affects upgrade routines and capacity planning. QRadar virtual deployments depend on the licensing model in your agreement, so confirm supported platforms and sizing with IBM before you commit. The Wazuh deployment options page lists the current methods.
- OVA: A prebuilt virtual machine gives a fast single-node start for labs and small environments.
- AMI: An Amazon Machine Image suits teams that already build on AWS, where instance sizing drives capacity.
- Docker and Kubernetes: Containers fit teams that run clusters, and storage classes and node pools become part of capacity planning.
- Node counts: Plan indexer, server and dashboard capacity separately, since the server supports clustering and each component has its own sizing.
Ask IBM whether your MVS or virtual licensing covers the hypervisor or cloud platform you intend to use, and confirm the supported Wazuh install method for each environment you plan to run.
Automation and air-gapped operation shape how capacity and licensing play out in regulated networks. Wazuh supports Ansible and Puppet for repeatable builds, and it publishes an offline installation guide for systems without internet connectivity. For vulnerability detection, an offline repository can replace the Wazuh Cyber Threat Intelligence platform. Licensing for isolated QRadar deployments is a question to settle directly with IBM.
- Configuration management: Ansible and Puppet keep builds repeatable and traceable to your change records.
- Offline installation: The offline guide covers isolated systems, so plan how packages and updates cross the enclave boundary.
- Offline vulnerability data: Vulnerability detection can use an offline repository, which means someone must maintain and refresh that copy.
- Agent coverage: Agents run on Linux, Windows, macOS, Solaris, AIX and HP-UX, and firewalls and other agentless devices can send syslog, which affects rollout effort.
Ask IBM whether on-premises licenses need connectivity to validate or report usage, and confirm how license files and usage reports reach a network with no outside access.
Capabilities side by side: log analysis, flows, endpoints and compliance
This table compares how IBM QRadar on premises and self-hosted Wazuh cover log collection, correlation, file integrity, vulnerability detection, flows and compliance reporting. Read the Wazuh column for what you configure yourself, and treat cells marked as gaps or to confirm as items to test in a proof of concept before you commit.
| Capability | IBM QRadar on premises | Wazuh |
|---|---|---|
| Log collection and parsing | Log sources are parsed through Device Support Modules (DSMs) that you install and maintain for each product | Wazuh agents and agentless syslog collection feed decoders and rules; custom decoders are written for sources without a built-in one |
| Correlation rules | Offense rules and building blocks, with correlation tied to the QRadar event pipeline | Rules in the Wazuh server analyze decoded events, with alerts stored in the Wazuh indexer; rule coverage must be confirmed for your log sources |
| File integrity monitoring | Not a core QRadar feature; typically supplied by a separate host or FIM tool | Built into the Wazuh agent, with alerts on file changes on monitored Linux, Windows and macOS endpoints |
| Vulnerability detection | Vulnerability data comes from QRadar Vulnerability Manager, which is licensed separately | Correlates agent software inventory with the Wazuh Cyber Threat Intelligence platform or an offline vulnerability repository |
| Network flow analysis | Flow collection and flow-based detection are part of QRadar, and flows are licensed per minute | No native flow analysis; pair Wazuh with Security Onion (Zeek and Suricata) for network visibility |
| Agentless syslog and API collection | Collects syslog and API data from supported devices through DSMs and protocol sources | Collects syslog and performs periodic API probing from devices such as firewalls; confirm the connector for each device |
| Compliance dashboards | QRadar offers compliance reporting content that depends on the rules and reports you deploy | Prebuilt dashboards for PCI DSS, GDPR, HIPAA and NIST 800-53; GDPR and PCI DSS are the frameworks covered by the Wazuh GitHub repository |
| Endpoint agents | No QRadar endpoint agent; endpoint telemetry comes from other tools that feed QRadar | Wazuh agents on Linux, Windows, macOS, Solaris, AIX and HP-UX, with remote configuration and upgrades |
Where Wazuh agents cover endpoints and where flow analysis needs another tool
Wazuh agents cover the endpoint side of a QRadar estate well, but they do not replace network flow analysis on their own. The agents run on Linux, Windows, macOS, Solaris, AIX and HP-UX, and they collect the software inventory that Wazuh's vulnerability detection correlates with vulnerability data from the Wazuh Cyber Threat Intelligence platform or an offline repository. Before you plan a retirement, list every operating system in your QRadar log sources and confirm each one has a Wazuh agent or an agentless path (syslog or API collection) that you have tested against your own event rates. Also confirm which vulnerability data source your environment can reach, since air-gapped networks will need the offline repository.
Wazuh alone is enough when your detection requirements rest on host logs, file integrity, configuration assessment, vulnerability inventory and syslog from firewalls and other appliances, and when you do not need to answer questions about who talked to whom across the network. In that case, the QRadar flow licensing you pay for today has no direct counterpart to rebuild, and the decision reduces to log and endpoint coverage. QRadar prices network activity as flows per minute alongside events, so review your current flow entitlement and the flow sources feeding it, because that line item will not map to a Wazuh setting.
Add a flow sensor beside Wazuh when your detection cases depend on east-west traffic, lateral movement, DNS or protocol metadata, or full packet capture for investigation. Security Onion bundles Suricata, Zeek and the Elastic Stack for that purpose, and it is a separate platform with its own sensors, storage and licensing terms, so it needs its own sizing and staff time. Note that its repository is licensed under the Elastic License 2.0 rather than an OSI open-source license. Confirm which flow-based rules your current QRadar content uses, because each one needs a documented replacement or an accepted gap before the appliances are switched off.
Data location, hosting models and compliance implications
The choice between QRadar and Wazuh is partly a choice about where event data physically lives, who operates the platform and who holds the evidence when an assessor asks. Each card below covers one of those decisions and what to confirm before committing.
Event data in each option
With QRadar on premises, events, flows and offenses are stored in appliances or virtual machines that your team operates inside your own data center or cloud account. With self-managed Wazuh, alerts land in the Wazuh indexer on servers you control. Ask IBM and your integrator to confirm where QRadar's event and flow stores sit, how long they retain data, and whether any telemetry leaves your environment for licensing or support purposes.
Self-managed Wazuh hosting
Running Wazuh yourself means the indexer, server, dashboard and agents all stay in your infrastructure, whether on virtual machines, containers or Kubernetes. The deployment options include an OVA appliance, Docker, Kubernetes and Ansible or Puppet automation. Your team owns patching, backups and the agent upgrade schedule, so document who approves each of those tasks before go-live.
Wazuh Cloud as a managed option
Wazuh Cloud is a hosted service run by the Wazuh company, so the data residency question shifts to that provider. If you need a managed Wazuh, confirm in writing the hosting region, subprocessors, encryption at rest, retention and the exit terms for exporting alerts. Compare those answers with your own data classification rules before choosing it over self-management.
Air-gapped offline installation
For networks without internet access, Wazuh documents an offline installation guide. Vulnerability detection can use an offline vulnerability repository in place of the Wazuh Cyber Threat Intelligence platform, which means you must maintain that feed yourself. Confirm how updates are transferred across the boundary and how often your feed is refreshed, since stale vulnerability data weakens findings.
Identity and single sign-on
Wazuh supports single sign-on for the dashboard, so administrator access can follow your existing identity provider rather than local accounts. On QRadar, confirm how authentication, role mapping and session policies are configured on the appliances and whether they integrate with the directory you already use. Map each platform's roles to your access review process before the first audit cycle.
Compliance evidence and assessor roles
Both platforms can produce logs and reports that support controls, and Wazuh's dashboard includes prebuilt views for frameworks such as PCI DSS, GDPR, HIPAA and NIST 800-53. DeployOpen prepares configurations, controls and evidence for assessments, but auditors and certification bodies decide whether the result meets a requirement. Note that IBM continues to support on-premises QRadar, and QRadar SaaS customers were offered migration to Cortex XSIAM after Palo Alto Networks acquired those assets in 2024.
What moving from QRadar to Wazuh involves at a high level
The sequence runs from inventorying what QRadar collects to retiring appliances in stages, so each step is verified before QRadar stops being the system of record. The result is a Wazuh deployment that has proven its detections against the same sources before any appliance is switched off.
Inventory log sources, DSMs and rules
Your team lists every log source sending events to QRadar, the DSM assigned to each one, the EPS and flow volume per source, and every custom rule, building block and report in use. Ask your QRadar administrator to export these lists, and mark which rules are actually firing. The step is done when each source has an owner, a volume figure and a decision to keep, replace or retire. Effort depends on how many sources and rules you have, so measure both before estimating anything.
Run Wazuh in parallel with QRadar
Stand up a Wazuh indexer, server and dashboard in your own infrastructure while QRadar keeps receiving the same sources. Duplicate a representative set of feeds to both platforms, using syslog forwarding where the source allows it. The step is done when Wazuh shows the same events for those sources over a normal business period and the team has confirmed that ingest, storage and dashboard load behave as expected.
Deploy agents and decoders for each source
For hosts, install Wazuh agents on Linux, Windows or macOS endpoints. For network devices and other agentless sources, configure syslog collection on the Wazuh server and write decoders where the default ones do not parse the events. Replace each QRadar DSM with the matching agent configuration or decoder, and test parsing with sample events. The step is done when every source in scope produces normalized events in Wazuh that your analysts can search.
Rebuild offense rules as Wazuh rules
Translate each QRadar correlation rule and building block into Wazuh rules, using the Wazuh rule syntax and any frequency or timeframe conditions the logic needs. Some QRadar logic, such as offense aggregation, will need a different approach, and this is where the rule inventory from the first step matters. The step is done when each retained rule has a documented Wazuh equivalent, a named owner and a test event that triggers it.
Export QRadar history for retention
Decide which QRadar events, saved search results, offenses and rule definitions must be kept for investigations or retention obligations, then export them before the appliance is retired. Export paths and what each one preserves differ, so check the dedicated export guide for the method that fits your data. The step is done when exported data is stored in a location you control, is readable, and has a documented retention period set by your compliance owner.
Retire QRadar appliances in stages
Move sources to Wazuh in groups, starting with the lowest-risk ones, and switch off QRadar collection for each group only after its detections have been validated. Keep the QRadar licence or support contract active until the final group is cut over and the history export is verified. The step is done when each stage has a signed-off cutover record and the last QRadar appliance is decommissioned under a documented change.
Validate detections against known scenarios
Run test scenarios, such as simulated failed logins, file changes or policy violations, and confirm that Wazuh raises the alerts your analysts expect. Compare results with the QRadar behavior recorded during the parallel run, and document each gap with an accepted risk or a fix. The step is done when every retained detection has a passing test, the gap register is closed or formally accepted, and your SOC lead has approved the detection set for production.
Questions buyers ask before choosing Wazuh over QRadar
What drives the cost of moving from QRadar to Wazuh?
Most of the cost sits in people and infrastructure, not in a license fee, because Wazuh is free and open source under GPLv2. QRadar costs recur through EPS, FPM or Managed Virtual Server licensing and support renewals, and those figures come from your IBM contract. Wazuh costs are one-time for design, deployment and content migration, then recurring for servers, storage, staff time and any outside support you buy. Storage usually grows with retention period and event volume, so ask your team to size retention before you size hardware. When you request a quote, ask for each component to be priced separately: the migration work, the hosting, the support tier and the retention approach.
How long does a QRadar to Wazuh migration take?
The timeline depends on how many log sources, custom rules and offense workflows you have, and on how long you need to run both platforms in parallel. Each QRadar log source with a DSM has to be mapped to a Wazuh agent, agentless collection or decoder, and each offense rule has to be rebuilt as a Wazuh rule. Historical data export also takes time, since you need to decide how much history must remain searchable. Teams that retire appliances in stages usually run both platforms for a period of overlap. Confirm the duration with a written scope that lists the log sources, rules and retention periods covered, rather than relying on a generic estimate.
Can a small security team run Wazuh without outside help?
A small team can run Wazuh if it has Linux administration skills, familiarity with SIEM detection content and a clear owner for alert triage. Wazuh has four components: the indexer, the server, the dashboard and the agents on endpoints. The server can run as a cluster, and it manages agent configuration and upgrades remotely, which reduces manual work. Staffing is the real constraint, because detection tuning, rule maintenance and patching run continuously. Before deciding, count the hours your team can spare each month for those tasks and compare that with the release cadence, since Wazuh shipped 4.14 patch releases on six dates in 2026.
What support does each option offer?
QRadar on premises customers continue to receive IBM features and support, under the terms of their IBM agreement. Wazuh is free to use, so its community channels and documentation come at no license cost, while commercial support, managed services and Wazuh Cloud are separate paid arrangements. Ask each vendor for its written support scope, response targets and the contract term for your region. DeployOpen can plan, implement, harden, back up, upgrade and document a self-hosted Wazuh deployment in your own infrastructure, and offers ongoing support and upgrades as retainers. Support tiers and their service levels should be confirmed in writing before you compare them.
Does Wazuh replace QRadar network flow analysis?
No, Wazuh does not provide a direct equivalent to QRadar's flow collection and network activity analysis. Wazuh focuses on log analysis, file integrity monitoring, vulnerability detection and endpoint agents, and it supports agentless collection of devices such as firewalls through syslog. If your detections depend on flow records, plan a separate network visibility layer. Security Onion, which bundles Suricata, Zeek and full packet capture, is one option to evaluate alongside Wazuh. Confirm which QRadar flow rules and dashboards your team uses before you assume any coverage.
How does EPS-based licensing map to Wazuh sizing?
QRadar licenses by events per second, so your current EPS figure from licensing records is the starting point, but it does not translate directly into Wazuh sizing. Wazuh sizing depends on the indexer's storage and search load, the number of agents, the alert volume after decoding and rules, and your retention period. Measure your actual event rate and daily volume over a representative period, then size the indexer and storage from those numbers. Ask your team to separate high-volume, low-value sources from critical ones, because filtering noise early often reduces storage needs. Hardware and storage figures should come from a sizing exercise in your environment, not from a conversion of licensing units.
When should a team bring in outside help for Wazuh?
Bring in outside help when the migration crosses multiple log source types, when compliance reporting must be proven during the transition, or when your team lacks capacity to rebuild detection content. DeployOpen plans, implements, customizes, integrates and documents self-hosted open-source platforms in your own cloud accounts, data centers or air-gapped networks. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. DeployOpen also prepares systems and evidence for compliance assessments but does not issue audit reports or certifications, which independent auditors provide. Request a written scope that lists the deliverables, and ask for the evidence you will receive.
What to ask IBM and your own team before deciding
Start with IBM, because the answers determine whether staying on QRadar is a real option at all. Ask which QRadar on-premises release line IBM will support over the next renewal term and how long each version receives fixes. Ask whether the license metric on your contract is events per second (EPS), flows per minute (FPM) or Managed Virtual Servers (MVS), how the metric is measured and sampled, and what happens to licensed capacity when your event rate rises above it. Get the renewal terms in writing: the uplift schedule, the support end date, what the price covers for appliances and virtual appliances, and whether a term can be shortened. Confirm which support tiers IBM offers for the on-premises product and who answers when a QRadar component fails.
Then ask your own team questions that a license quote cannot answer. Who will own detection content once the platform is running: the rules, decoders, dashboards and suppression logic that currently live in QRadar offenses and building blocks? Who will review tuning changes, and how many analysts can do that work without a vendor? Estimate sizing from your own data rather than from a vendor figure: measure sustained and peak event rates, the share of events that are noise, the flow volume from your network sensors, and how many days of searchable history your investigations and regulators require. Decide who will run upgrades, backups and capacity reviews. The outcome of these questions is a named owner for each function and a written scope, which is what a fixed-scope implementation partner will need before quoting.
How DeployOpen helps evaluate, implement or migrate Wazuh
DeployOpen is a Chainscore Labs company that plans, implements, hardens, backs up and documents self-hosted open-source platforms inside your own infrastructure. For a QRadar to Wazuh decision, we work from a written scope so you can compare licensing, appliances and support against a concrete Wazuh design before any work starts.
How we scope
- We start with your current QRadar estate: deployment type, event and flow volumes, and which log sources and offense rules matter.
- The written scope names the Wazuh components, deployment method and hosting environment, including any air-gapped or offline requirements.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work begins and a quote following from that scope.
How we build
- We install the Wazuh indexer, server, dashboard and agents in your environment, using the deployment method your scope selects.
- We map log sources to agents and decoders, and rebuild priority detection rules and compliance dashboards for your frameworks.
- We test detections against representative events and document tuning decisions so your team can review each rule's behavior.
How we hand over
- You receive architecture documentation, configuration records, runbooks for agent and rule management, and the backup and upgrade procedures.
- We document the evidence and control mappings your compliance team needs, while independent auditors and certification bodies make any assessment decision.
- Knowledge transfer sessions walk your operations staff through daily triage, rule changes and the retirement plan for QRadar appliances.
How we support
- Ongoing support, upgrades and continuous security testing are available as retainers after handover.
- Retainers can cover Wazuh patch releases, upgrade testing and cluster capacity reviews, scoped in writing with your team.
- Confirm with us which QRadar support renewal dates and data export deadlines apply, so the handover timeline matches your contract.
