Wazuh vs OSSEC migration

The key fact that makes a staged migration practical is that OSSEC agents are compatible with the Wazuh server, so both agent types can report to one Wazuh server while the estate moves over. The Wazuh team forked OSSEC in 2015, and the Wazuh migration guide for version 3.13 describes this coexistence. Because that page documents 3.13, confirm each step against the current 4.14 documentation before you rely on it, including agent version support, the manager and agent upgrade order, and any changes to how agent keys and enrollment work.

Start by standing up the Wazuh server, indexer and dashboard in a non-production or parallel environment, then point a small pilot group of existing OSSEC agents at it. Validate that these agents report, that their events are decoded and that alerts reach the dashboard as expected. Check the same things you rely on today: file integrity monitoring baselines, log collection paths, active response behavior and the rules that fire on known test events. Do not begin wider replacement until the pilot has produced the alerts your analysts expect, since a silent agent is harder to spot once the estate is mixed.

Replace agents in waves, grouped by server role or business owner rather than by hostname, so each wave can be rolled back as a unit. Keep the OSSEC manager running until the last agent in the estate reports to Wazuh, and record which hosts are on which agent version so you can answer audit questions about coverage during the window. Ask your DeployOpen or internal team to confirm the wave sizes, the rollback trigger and the monitoring gaps you accept for each wave, since these depend on your own change windows and staffing.

Custom OSSEC rules and decoders need review before they go into Wazuh, not a blind copy of the rules and decoders directories. Wazuh ships its own ruleset and decoder set, so a local rule can collide with a built-in rule ID or be shadowed by a decoder that now matches the same log first. Inventory every local file in your OSSEC estate, record which rule IDs and decoder names it defines, and compare them against the Wazuh ruleset documentation so each custom item is classed as keep, rewrite, or retire. Where a custom rule duplicates coverage that Wazuh already provides, the decision is usually to retire it and rely on the built-in rule, with a note in your change record.

Test every custom rule you keep against replayed logs before cutover. Capture representative log samples from each source type, run them through a test Wazuh server with the wazuh-logtest tool, and confirm that the expected decoder fields are extracted and that the expected rule fires at the expected level. Do the same for the negative cases, since a rule that starts firing on benign traffic after migration is as much a regression as one that stops firing. Map each surviving alert to its entry in the Wazuh ruleset documentation, including any MITRE ATT&CK mapping, so that dashboards and any downstream tickets keep their meaning. Record the results so you can show an assessor or auditor which detections were verified and how.

This is where most of the migration effort concentrates for estates with heavy customization. A small OSSEC deployment with stock rules can move quickly, but an estate with years of local decoders, chained rules and site-specific alert handling needs a line-by-line review, and the testing time scales with the number of rules and log formats. Ask your implementation partner or internal team to estimate this work from your actual rule inventory rather than from the number of hosts, because the rule count drives the effort. Plan for at least one round of rule fixes after the first replay, and keep the OSSEC rule files under version control so each change is traceable.

Start by confirming which OSSEC version each agent runs and which operating systems it covers. The Wazuh documentation on migrating from OSSEC states that OSSEC agents are compatible with the Wazuh server, so mixed estates can report to one server during cutover. That compatibility statement is a documented starting point, not a substitute for testing. Build an inventory of agent versions, host operating systems and any platforms outside the standard Linux and Windows set, such as Solaris, AIX or HP-UX, and confirm each one against the current Wazuh agent support list before you schedule it. Note also which hosts use the OSSEC web interface or any Atomic OSSEC features, because those will not carry over as they are.

Next, inventory every custom rule and decoder, along with the ID ranges and the alert levels that downstream tickets or scripts depend on. Wazuh ships its own built-in rules and decoders, so some local rules may duplicate or overlap with them. Test each custom rule against sample logs on a non-production Wazuh server and record the results, rather than assuming a rule file loads cleanly. Confirm how your team manages those files today, since the location and override behavior of local rules is what most often breaks during a move. Plan who owns the sign-off for each rule that feeds an alert your SOC acts on.

Then size the indexer and the network path before you deploy anything. Estimate daily log and alert volume per endpoint group and the retention your compliance or incident response obligations require, and confirm the storage available for the Wazuh indexer, which stores alerts for search and analytics. Map every network path from agents to the Wazuh server, including the ports used, proxies, NAT and any firewall rules that treat the new server differently from the old OSSEC manager. Finally, decide whether any segments are offline. The Wazuh offline installation guide covers systems without internet connectivity, and vulnerability detection can use an offline vulnerability repository in place of the Wazuh Cyber Threat Intelligence platform, so confirm which of those applies before you choose an installation method.