Migrate from IBM QRadar to Wazuh

Migrate from IBM QRadar to Wazuh: what the move involves

Moving from an on-premises QRadar estate to Wazuh is a rebuild of log collection, detection content and retention, not a copy of stored events. QRadar's event store, its AQL-based searches, its offense correlation and its DSM-based parsing do not transfer into Wazuh as they are, so the work is to re-collect sources through Wazuh agents or syslog, re-express detections as Wazuh decoders and rules, and decide what history must remain searchable and for how long. Most teams keep QRadar collecting and alerting while Wazuh is stood up beside it, then cut over one log source group at a time once the new detections have been compared against known QRadar results.

The work is usually shared. Security engineering owns detection content and the mapping from each QRadar DSM to a Wazuh decoder and rule set. SOC leads own the offense inventory, decide which QRadar rules and building blocks still matter, and test the replacements against recent incidents. Platform staff own the Wazuh indexer, server and dashboard, sizing, backups and upgrades, and the agent rollout through Wazuh's remote configuration. Some organizations bring in an outside implementer for the first deployment and hand over runbooks. Ask any implementer to show how they will inventory QRadar content, which sources they will re-onboard first, and how parallel running will be checked, before agreeing scope.

Effort and risk depend mostly on how much custom QRadar content exists, how many log sources are unusual or custom-parsed, and whether regulators or auditors expect continuity of detection evidence. Confirm these counts in your own environment before estimating anything. The main risks are silent gaps: a source that stops reaching Wazuh, a rule that fires less often than the QRadar offense it replaces, or history that is archived but not searchable when an investigation needs it. Plan to keep QRadar read access until retention obligations are met, and retire appliances in stages only after parallel results match. Use the Wazuh documentation to confirm component roles before sizing the new environment.

Which QRadar capabilities map to Wazuh, and which need rework

This table maps each main QRadar capability to its closest Wazuh component and marks it clean, needs rework or gap. Read the rework rows as work your team must budget for, and the gap rows as functions you must cover with another tool. Network flow analysis is not a Wazuh equivalent and must be confirmed against Security Onion or another flow tool before you retire any QRadar flow licensing.

Capability	QRadar on premises	Wazuh equivalent and status
Log source integration	DSMs parse vendor logs, with protocols such as syslog and JDBC collecting them	Agents and decoders parse logs; syslog and API probing cover agentless devices. Needs rework: each DSM must be mapped to a decoder and tested
Event collection and storage	Events are collected through appliances and stored under EPS licensing	Agents and the server collect events, and the Wazuh indexer stores alerts. Needs rework: sizing and retention must be redesigned
Offense correlation rules	Rules and building blocks chain events into offenses	Wazuh rules with correlation by frequency and timeframe. Needs rework: each offense rule must be rewritten and tested
Building blocks and reference sets	Reusable tests and lists of IPs, users or hashes used by rules	Wazuh uses CDB lists and rule groups. Needs rework: confirm list formats and migrate values by hand
Dashboards and searches	Custom dashboards and AQL searches in the QRadar console	Wazuh dashboard views and indexer queries. Needs rework: AQL searches must be rebuilt, not translated automatically
File integrity monitoring	Available through QRadar content and add-ons, depending on your setup	Built into Wazuh agents with FIM. Clean for most endpoints; confirm paths and scan frequency
Endpoint agents	QRadar relies on separate endpoint products for host telemetry	Wazuh agents run on Linux, Windows, macOS, Solaris, AIX and HP-UX. Clean for supported platforms; confirm older OS versions
Vulnerability data	Vulnerability scanner feeds are integrated through separate products	Vulnerability detection uses the agent software inventory with CTI or an offline repository. Clean if an offline feed is planned for air-gapped sites
Compliance reporting	Reports are built in QRadar from custom content	Dashboard views for PCI DSS, GDPR, HIPAA and NIST 800-53. Needs rework: confirm each report against your own control mapping
Network flow analysis	Flow licensing per minute with flow-based detection	Not a Wazuh equivalent. Gap: confirm against Security Onion or another flow tool before retiring flow licensing

What data and content can leave QRadar, and what must be rebuilt

QRadar gives you several export paths, and each one carries a different slice of your environment. Events, saved searches, rules and integrations do not move the same way, so plan them separately. The cards below cover what each path leaves behind and what your team will rebuild in Wazuh.

Log Activity exports

The Log Activity interface can export search results to XML or CSV, which is the simplest way to pull a bounded set of events for an audit or a specific investigation. The export reflects only the search you ran and the fields shown, so normalized and custom properties may be missing unless you include them. Confirm the row limits and file formats for your QRadar version before you plan bulk pulls. Use this path for evidence sets, not for full history.

Ariel API result downloads

The Ariel API lets scripts run AQL searches and download results in bulk, which suits longer time ranges than the interface handles well. Write the queries against the same field names your analysts use, and record the time window and event count for each batch so you can prove completeness. Check the API version, authentication method and any result size limits in your own deployment before you script the job. Exports still arrive as files, not as live events.

contentManagement.pl for rules and reports

The contentManagement.pl tool exports and imports QRadar content such as custom rules, building blocks, reports and saved searches. It is the only documented path that captures rule logic, so it becomes your source for the rebuild backlog. Expect the output to be QRadar-specific XML that no Wazuh tool reads directly, so each rule must be translated by hand into Wazuh decoders and rules. Confirm which content types your version exports.

History as files, not replayed events

Historical events are normally exported as files and then re-indexed into the Wazuh indexer or archived for retention, rather than replayed through the Wazuh server. Replay would generate new alerts against current rules and distort any trend you need to keep. Decide early which periods must be searchable in Wazuh and which only need to be retrievable from archive. Map each export to a retention owner.

Offenses and analyst notes

QRadar offenses, their correlation history and analyst comments are case-level records that the export paths above do not reliably carry into Wazuh. Treat them as an archive: export what your ticketing or case system can hold, and keep the QRadar appliance or an offline copy for the open cases and the legal hold period. Ask your compliance lead which offense records must be retained and in what form. Assume closed offenses will not reappear as Wazuh alerts.

Ticketing, SOAR and identity connections

Ticketing, SOAR playbooks and identity connections such as directory lookups are configured inside QRadar and do not transfer as data. Rebuild each one against Wazuh integrations, the Wazuh API and your identity provider, and test every workflow end to end. Single sign-on for the Wazuh dashboard is a separate configuration task that the Wazuh documentation describes. Inventory these connections before cutover so none are lost silently.

How Wazuh agents, decoders and rules replace QRadar DSMs and offenses

A QRadar DSM does not translate into a Wazuh object one to one. In QRadar, a Device Support Module parses events from a source, and offenses are raised by custom rules and building blocks that correlate those events. In Wazuh, the work is split across four components: the Wazuh indexer stores and searches alerts, the Wazuh server analyzes incoming data with decoders and rules, the Wazuh dashboard presents results, and Wazuh agents on endpoints collect logs, file integrity data and software inventory. Map each DSM to a decoder that extracts the fields you need, then to the rules that act on those fields. Start with the sources that feed your highest-value offenses, and list the parsing and property extraction each one depends on before writing anything.

Agentless devices such as firewalls generally do not need an agent. They send syslog to the Wazuh server, which decodes and evaluates it in the same way. Confirm with your own environment which devices can emit syslog in a format your decoders can read, which need a periodic API probe, and which depend on vendor-specific fields that a stock decoder will not extract. Also confirm the syslog listener, port and transport (UDP or TCP) you will use, and check how event volume from each source affects the server sizing you plan for. Wazuh has no equivalent to QRadar's event rate licensing, so these sizing decisions become your infrastructure and staffing questions.

Offense rules and building blocks must be rewritten as Wazuh rules and then tuned against real traffic. Building blocks are reusable test sets, and they usually encode assumptions about your network, such as which address ranges are internal or which accounts are administrative. Treat each correlation rule as a new design: define the trigger, the time window, the grouping key and the expected false positive rate, then replay historical events to validate it. Do not translate correlation logic line by line, because QRadar's test functions and Wazuh's rule chaining behave differently. Keep a register of which offenses you retired, which you rebuilt, and which you consciously dropped, and have the security team sign off on it. On licensing, Wazuh is distributed under the GNU General Public License version 2, with an exception that permits linking with the OpenSSL library. Ask your legal team to review the license terms against your internal distribution and modification plans.

The migration sequence from inventory to decommission

This sequence moves QRadar event collection, detection content and history to Wazuh one source group at a time, so each step produces evidence that the next step depends on. Appliances are retired only after both platforms have been compared and the cutover has been signed off.

Inventory log sources, EPS and retention needs
Build a source register that lists every log source sending events to QRadar, its DSM or protocol, its average and peak events per second, the offense rules and building blocks that depend on it, and the retention period your auditors and legal team require. Confirm the retention figures in writing with compliance owners, because they set how much history must be exported before the appliances are switched off. This step is done when the register is reviewed and signed by the platform owner and the security operations lead.
Map DSMs and rules to Wazuh content
For each entry in the source register, identify the Wazuh route: an installed agent for endpoints and servers, syslog collection for network devices and firewalls, or an API integration where the source offers one. Decide whether an existing Wazuh decoder and rule set covers the event type or whether a custom decoder is needed, and list each offense rule and building block with its Wazuh rule equivalent or a note that it has no direct match. The output is a rule mapping document that marks each item as covered, partially covered or needing redesign, with an owner for each open item.
Pilot on a representative source set
Deploy the Wazuh server, indexer and dashboard in your own environment, then onboard a small group of sources chosen to cover the main types in the register, such as a Windows domain, a Linux server group, a firewall and one authentication source. Replay or mirror known events, trigger the rules you rebuilt, and confirm that alerts appear in the dashboard with the fields your analysts need. The pilot is complete when a validation log records, for each test case, the input, the expected alert and the observed result, and the team accepts the gaps.
Run both platforms in parallel
Send the same events to QRadar and Wazuh for a set period agreed in advance, and compare alert volumes, false positive rates and the detections analysts act on. Track differences in a shared log and tune Wazuh rules until each difference is explained. Parallel running also tests capacity, so check indexer storage and server load against the event rate you measured in the inventory step. The output is a parity report that the security operations lead reviews against the success criteria written before the run began.
Cut over source groups with a signed plan
Move sources to Wazuh in groups, starting with those whose rules passed parity testing and ending with the most complex sources. For each group, stop forwarding to QRadar only after the rule mapping and validation log show the group is covered, and keep a documented rollback path. Record each cutover in a signed-off plan that names the group, the date, the approver and the rollback steps, so the audit trail shows when responsibility moved.
Decommission QRadar appliances in stages
Before retiring any appliance, export the history you need using the export paths documented for QRadar, then verify that exported records open and can be searched in your archive. Retire non-production and collector appliances first, and keep the console read-only for a defined review period so analysts can query older data. Remove the final appliance only after the retention checks, the export verification and the compliance owner's sign-off are complete, and file the decommission record with your audit evidence.

How the migration differs by estate size and starting point

A single-site estate with a limited number of log sources usually has the simplest path. Most of the work sits in inventory and rule translation rather than in infrastructure. A small team can often install the Wazuh server, indexer and dashboard on one stack and enroll agents in waves, starting with domain controllers, identity systems, perimeter firewalls and the hosts that generate the most offenses.

Inventory first: List every QRadar log source, its DSM and its protocol, then decide which ones get an agent and which ones use syslog.
Fewer decoders to rebuild: A short source list means fewer custom decoders and fewer offense rules to translate into Wazuh rules.
Single-node sizing: Confirm with Wazuh documentation whether an all-in-one installation or a step-by-step installation fits your event volume.
Shorter parallel run: Running QRadar and Wazuh side by side is easier to finish when only a handful of sources change.
Owner for each source: Assign one named person per source so that agent rollout and syslog changes do not stall.

Confirm the expected events per second and retention period with your own data before choosing a single-node layout.

What drives the cost and duration of a QRadar to Wazuh move

This table lists the factors that change the effort and cost of moving from QRadar to Wazuh, why each one matters, and how to reduce it. Read it as a checklist to size your own inventory before asking for a quote, since no fixed price or duration applies to every environment.

Driver	Why it changes cost or effort	How to keep it down
Log source count and DSM coverage	Each source needs an agent, syslog path or API collector, plus a decoder and tests. Sources with QRadar DSM coverage map more easily than custom or unsupported formats.	Export the log source list with event rates and owners, retire dead sources, and group similar devices so one decoder serves many.
Custom parsers and properties	Custom event properties and parsing logic written in QRadar must be re-expressed as Wazuh decoders and rules. Each custom parser is hand-work, not a configuration copy.	Inventory custom properties first, drop unused ones, and consolidate overlapping parsers before rebuilding.
Offense rule count and complexity	Correlation rules, building blocks and reference data sets are rebuilt as Wazuh rules and lists. Multi-condition rules with cross-source logic take longer to validate than simple thresholds.	Export rules with usage data, retire rules that never fired, and prioritize the detections your audit and incident process depend on.
History volume and export method	Long retention means large archives to export through the Ariel API or saved search results. Export speed, storage for the archive and the decision on what must be queryable all add work.	Set a retention need per data class, export only what regulators or investigations require, and keep older data in read-only archives.
Integration count	Ticketing, identity, threat intelligence, vulnerability and SOAR connections each need reconfiguration or replacement, and some may have no direct Wazuh equivalent.	List every inbound and outbound connection with its owner, mark those to retire, and reuse Wazuh integrations where they exist.
Air-gap requirements	Offline installs need the offline installation guide, local package and update mirrors, and an offline vulnerability repository instead of the online threat intelligence feed. Each update path must be planned and tested.	Confirm the network model early, stage packages and vulnerability data on approved media, and document the update procedure.
Staffing and skills	Internal staff time covers source owners, rule owners and analysts who validate detections. Implementers add capacity for decoders, rules and hardening. Staff who know QRadar AQL and rule logic have to learn Wazuh rule syntax.	Name owners for each source and rule group, schedule analyst time for validation, and ask the implementer which tasks they will hand over to your team.
Parallel-run length	Running QRadar and Wazuh side by side doubles licensing, hardware and monitoring effort for as long as both are live. Length depends on how many detections must be proven equivalent.	Define exit criteria per use case, retire sources in stages, and set a fixed end date for each appliance in the plan.
Cost components and recurring spend	One-time costs include discovery, build, testing and migration. Recurring costs include Wazuh server and indexer infrastructure, storage, staff time, and support or retainers. QRadar licensing and appliance support continue until retirement.	Ask each quote to split one-time and recurring items, state who pays for infrastructure, and show how QRadar renewal dates align with the cutover plan.

What usually goes wrong in a QRadar to Wazuh migration

Most QRadar to Wazuh migrations fail in predictable places: detections that quietly stop firing, log sources that stop arriving, and history that cannot be queried the way analysts expect. Each card below names one failure point, why it matters for this move, and the check that prevents it before the appliances are switched off.

Detection gaps after cutover

QRadar offenses often depend on building blocks, reference sets and cross-source correlation that were never documented as a single list. When the appliance is retired, some of those detections simply stop firing, and nobody notices until an incident is missed. Build an inventory of every active rule and offense type, mark each one as rebuilt, replaced or retired, and run both platforms side by side against the same sample events until every entry has an owner.

Unvalidated rule translation

Translating a QRadar custom rule into a Wazuh rule changes the matching logic, field names and thresholds, so a rule can look correct and still fire on the wrong events. Test each translated rule against known-good and known-bad samples from the original data, and record the expected alert for each. A rule is only considered migrated when its test output matches the QRadar result for the same input.

Silent log source loss

Each QRadar Device Support Module maps to a Wazuh agent, a syslog listener or an API collector with its own decoders, and any source without a match falls out without an error. Systems that sent events to QRadar over a forwarding rule may keep sending to a destination that no longer listens. Compare the list of log sources QRadar reported as active against Wazuh's agent and syslog inventory, and alert on any source that goes quiet for longer than its normal interval.

History that cannot be searched the same way

Exported QRadar events are often stored as flat files or CSV, which means the fields QRadar parsed at ingest may not exist as indexed fields in the Wazuh indexer. Analysts who relied on AQL queries across years of data will find that old events are present but harder to filter. Decide which history must stay queryable, load a representative sample first, and confirm that field names and time zones match before you rely on the archive for investigations.

Missing integrations and downstream feeds

QRadar often feeds ticketing systems, SOAR playbooks, threat intelligence lookups and reporting jobs that were built around its API and syslog output. None of these move automatically, and a broken feed may only surface during an incident. List every inbound and outbound integration from QRadar's configuration, assign each one an owner, and test the replacement path end to end before the cutover date.

Under-sized indexer storage

The Wazuh indexer keeps alerts and archived events on the storage you provision, and retention is a decision the team must make rather than a default inherited from QRadar. Storage needs grow with event rate, event size and retention period, so a sizing estimate based only on current EPS can run out early. Ask for a written sizing method, measure actual daily volume during the parallel run, and set retention per data class before go-live.

Appliance support ending before parallel run completes

QRadar appliances and subscriptions run on contract dates, and a renewal decision made early can leave too little time for a full parallel run. If support lapses mid-migration, the team may lose vendor fixes and patches just when the old platform is still needed for lookback. Confirm the support end date with your IBM account team in writing, then schedule the parallel run and the read-only archive window so both finish before that date.

Questions teams ask before moving from QRadar to Wazuh

How much effort and time does a QRadar to Wazuh move take?

The effort depends mostly on how many log sources, custom DSMs, offense rules and building blocks you run, and on how much of the detection content you intend to rebuild rather than retire. No supplied figure fixes a duration, so treat any number you receive as conditional on an inventory. Start by counting active log sources, custom properties, rules and reports, and by listing which QRadar integrations feed other tools. A team with a small, well-documented estate will finish faster than one with years of undocumented tuning. Ask any implementation partner for a written scope that lists these inventories as the first deliverable, with timelines tied to them.

Can our own team migrate from QRadar to Wazuh without outside help?

Yes, a skilled internal team can run the migration, but the work is more than installing software. It requires knowledge of Wazuh decoders and rules, how your QRadar DSMs parse events, and how your detection logic maps to Wazuh rule syntax. Teams with a SIEM engineer who already knows QRadar AQL and offense tuning usually find the gap manageable, while teams without that depth often benefit from outside help on decoders and rule translation. Wazuh's documentation and community resources cover installation paths, including OVA, Docker, Kubernetes and offline guides. Decide early which parts your staff will own, then agree on a fixed-scope arrangement for the rest.

What does the migration need from our security and IT teams?

The migration needs named owners across security operations, network, endpoint administration and the teams that own each log source. Security operations must decide which detections matter and sign off on the rebuilt rules, because a rule that fires differently will change alert volume. Infrastructure staff must provide servers or virtual machines, storage sizing, network paths for agents and syslog, and change windows for appliance retirement. Endpoint teams must approve agent rollout, and application owners must confirm which logs they still need. Ask your implementation partner for a responsibility matrix before work starts.

Can we keep QRadar event history searchable after cutover?

Historical events can be exported from QRadar and retained, but they will not be searched through Wazuh's native interface unless you load them into a store that supports it. Export paths include Log Activity exports, Ariel API result downloads and the contentManagement.pl tool for rules, reports and saved searches, and each path leaves different content behind. Wazuh stores alerts in its indexer, so an archive for older data may need a separate search layer or a read-only QRadar appliance for a defined retention period. Confirm with your legal and compliance owners how long history must remain queryable, in what format, and who must be able to retrieve it.

Does Wazuh cover network flow analysis the way QRadar does?

Wazuh does not replace QRadar's flow analysis directly. Its strengths are log analysis, endpoint monitoring through agents, file integrity monitoring, vulnerability detection and compliance dashboards. Network flow visibility usually needs a separate tool, such as a flow collector or a network sensor platform, and some teams pair Wazuh with Security Onion for Zeek and Suricata data. Agentless monitoring of devices such as firewalls through syslog collection is available, but that is not a substitute for flow records. Map each QRadar flow use case to a named replacement before you retire the appliance, and confirm coverage with the vendor for your traffic volumes.

How does Wazuh licensing differ from QRadar licensing?

Wazuh is free and open source under the GNU General Public License version 2, with an exception that permits linking with the OpenSSL library. QRadar licensing is commercial and typically depends on event rates, flow rates or the Managed Virtual Server model, depending on your agreement. With Wazuh, the recurring costs shift to hardware or cloud capacity, storage, staff time and any outside support you buy. Ask IBM for your current licensing terms and any support renewal dates, and ask Wazuh or its partners which commercial support or cloud options fit your needs. Read the Wazuh LICENSE file yourself before you distribute modified code.

What should we confirm with IBM and in our own environment first?

Confirm your QRadar contract terms, including support end dates, licensing metric, data export rights and any notice periods for appliance retirement. In your own environment, confirm the full list of log sources, DSMs in use, custom rules, building blocks, reports and integrations, and check which events you must retain for audit. Verify that your target hardware, network paths, and offline or air-gapped requirements can support Wazuh's chosen deployment option. Also confirm which Wazuh release line you will standardize on, because patch cadence affects your change process. Write these answers down before any cutover plan is approved.

How DeployOpen scopes and runs a QRadar to Wazuh migration

DeployOpen is a Chainscore Labs company that plans, implements, integrates, hardens, backs up and documents self-hosted open-source platforms inside the client's own infrastructure, including their cloud accounts, data centers or air-gapped networks. For a QRadar to Wazuh move, that means the Wazuh indexer, server, dashboard and agents are deployed in your environment, with your team owning the data, the credentials and the decisions about which log sources move first. Most engagements of this kind are fixed-scope, so the written scope sets which QRadar log sources, offense rules and reports are rebuilt, which are retired, and what each deliverable looks like before any work starts.

A useful scope document lists the inventory of QRadar log sources and DSMs, the custom properties and building blocks in use, the event rate that must be sustained, the retention periods your auditors expect, and the appliances to be decommissioned. It should also state which parts are out of scope, such as network flow analysis, which Wazuh does not replace, and who signs off on the cutover. Ask for deliverables by name, for example the agent deployment plan, the decoder and rule mapping, the parallel-run report and the decommissioning checklist, together with the timeline agreed for each. A quote follows from that written scope. DeployOpen does not publish a price list, so the cost depends on what the scope contains.

After the initial build, many organizations keep a retainer for Wazuh upgrades, rule tuning and support, since the 4.14 line has seen regular patch releases. Ask any provider to explain how upgrades are tested against your custom rules and how backups of the indexer and server configuration are restored. DeployOpen can prepare systems and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make those determinations, so confirm early with your assessor which evidence they will accept.

Migrate from IBM QRadar to Wazuh