What a Wazuh migration involves
A move to Wazuh from another SIEM, a log platform or an older OSSEC deployment changes far more than the server. Detection content, decoders, agents, stored alert history, dashboards, user access and the cutover date all move together, and each one needs an owner. Teams that treat it as a server swap usually discover missing rules or lost history only after the old platform is switched off.
Common triggers include a change in license or support terms for the current tool, a decision to consolidate several security tools, an OSSEC version that no longer receives updates in your environment, or a new need for vulnerability detection or compliance views. Each trigger sets different priorities. A support-driven move may prioritize keeping alerts flowing, while a consolidation may prioritize retiring duplicate sources. Write the trigger down first, because it determines what success looks like.
What your team usually keeps in-house: the inventory of log sources, the list of detections the business relies on, decisions about retention and who may see which data, and the cutover sign-off. These depend on knowledge of your own systems and obligations. Confirm with your security and compliance leads which of these they can staff.
A partner is often asked to take on decoder and rule mapping, agent rollout, indexer and dashboard setup, and parallel-run testing, where the work is repetitive but error-prone. Ask any provider to state in writing which items they own, which they review and which remain yours, and to confirm how the Wazuh release line in use will be handled during the move.
What the migration work includes
A fixed-scope migration usually runs through the workstreams below, and each one ends in a named deliverable you keep. The exact set depends on how much of your existing SIEM or OSSEC content you plan to carry forward.
Source inventory and rule audit
We catalog the existing rules, decoders, alerts, log sources and agent configurations from your current platform, including which ones fire, who owns them and which are still used. The output is a source inventory and a list of content to retire, keep or rebuild. Check that alert owners and SOC analysts have confirmed the list before mapping starts.
Decoder and rule mapping
Each source format and rule is mapped to its Wazuh decoder and rule equivalent, or flagged where no equivalent exists. Because OSSEC rule IDs and Wazuh rule IDs do not line up one to one, the mapping records the ID changes that downstream tickets and playbooks will need. The deliverable is a source-to-decoder map and a rule gap register with an owner for each open gap.
Custom decoders and rules
Where a gap is worth closing, we write custom decoders and rules for your log formats and detection logic, then test them against sample events captured from your environment. Testing shows whether a rule fires on the expected events, but it does not prove detection parity with the old platform. The deliverable is a set of tested custom rules with test records and version control notes.
Indexer, server and dashboard build
We build the Wazuh indexer, server and dashboard inside your environment, with the sizing, certificates, storage and access settings agreed in the scope. Check early which parts of the stack your platform team will operate after handover. The deliverable is a documented, running installation and an as-built record of hosts, versions and configuration.
Agent replacement and enrollment plan
We plan how existing OSSEC or other agents are removed or replaced by Wazuh agents across each operating system in your fleet, including the order of waves, the enrollment method and agent group design. Confirm early which hosts cannot be touched during change windows. The deliverable is an enrollment plan with wave lists, rollback steps and group definitions.
Parallel running and comparison
The old and new platforms run side by side for an agreed period so the SOC can compare alerts from the same sources. Differences are logged and classified as missing coverage, extra noise or changed severity. The deliverable is a parallel-run comparison report with a disposition for each difference and a sign-off record from the SOC owner.
Cutover and decommissioning
We prepare the cutover runbook, the rollback plan and the timing of alert routing, ticketing and playbook changes, then retire the old platform once the agreed exit criteria are met. Decommissioning includes removing old agents and storing or deleting retained data as your retention policy requires. The deliverable is a cutover runbook, a decommissioning checklist and a closure record.
What drives migration effort and cost
This table lists the drivers that change effort and duration in a Wazuh migration and how to reduce each one before a quote is agreed.
| Driver | Why it moves cost or effort | How to keep it down |
|---|---|---|
| Log sources and endpoints | Each source needs a decoder path, a collection method and validation. Agentless devices add separate syslog or API setup. | Inventory sources from the old SIEM configuration and retire feeds nobody uses. Start with high-value sources. |
| Custom rules and decoders | Rules written for OSSEC or another SIEM rarely load unchanged, so each one needs review, rewriting and testing. | Export and count existing rules, retire duplicates and unused ones, and map the rest by detection purpose. |
| Alerts and dashboards to reproduce | Every alert the SOC depends on needs a Wazuh equivalent and a dashboard view that analysts accept. | Agree a short list of must-keep alerts with analysts and leave the rest out of the first release. |
| Agent replacement scope | Each host platform needs its own package, enrollment path and configuration check across Linux, Windows and macOS. | Count hosts per platform first, group them by role and roll out in waves. Automate with Ansible or Puppet where possible. |
| Historical data to keep or archive | Migrating old events into the indexer consumes storage and processing time. External archives add a separate retrieval path. | Set retention per data class and migrate only the history that auditors or investigators need. |
| Compliance mappings in use | Teams relying on PCI DSS, GDPR, HIPAA or NIST 800-53 views need those mappings rebuilt and checked against their evidence. | List the frameworks and reports in use today and confirm which controls each one must evidence in Wazuh. |
| SSO and access model | SAML integration, role mapping and the number of dashboard user groups change configuration and testing work. | Reuse existing identity groups and define administrator and read-only roles before cutover. |
| Number of environments | Each environment, such as lab, staging and production, repeats the installation, rule sync and agent tests. | Keep staging small, promote rules through version control and limit parallel running to a defined window. |
| Air-gapped or offline constraints | Offline installation and an offline vulnerability repository change packaging, update and approval steps. | Confirm offline needs early and plan how updates and vulnerability data reach the network. |
Migration phases and what each produces
The sequence moves detection from the current platform to Wazuh, with each phase producing the evidence the next phase depends on.
Inventory the current SIEM or OSSEC estate
DeployOpen and your team list every log source, agent, decoder, rule set, alert destination, retention rule and integration in the current platform, with a named owner for each. The output is an estate inventory marking which items must be reproduced in Wazuh. Approval gate: the security owner signs off that the inventory is complete.
Design the target Wazuh architecture
Size the Wazuh indexer, server and dashboard against measured event volume, retention periods and agent count, and decide between a single-node or clustered layout and where each component runs in your infrastructure. The output is an architecture and sizing document. Approval gate: infrastructure and security leads approve the design before any resources are ordered.
Map rules and decoders into a gap register
Map each existing rule, decoder and alert to its Wazuh equivalent, or to a custom decoder or rule that must be written. Anything without an equivalent goes into a gap register with an owner, a risk rating and a decision to rebuild, accept or retire it. The output is the mapping and the gap register. Approval gate: the detection owner and compliance lead sign off on every accepted gap.
Build the platform and test in a lab
Deploy the Wazuh components in a lab that mirrors the target design, load the custom decoders and rules, and replay sample logs from representative sources. The check confirms that expected alerts fire and that noise stays within agreed limits. The output is a tested build and per-rule test results. Approval gate: the test results are accepted and the build is frozen as the pilot baseline.
Pilot agent replacement and roll out
Replace the existing agents on a small pilot group, then expand in waves through agent groups, checking enrollment, configuration delivery and log flow at each wave. The old collector is removed from a host only after its wave is confirmed healthy. The output is an enrollment record for every endpoint and a list of hosts still pending. Approval gate: the operations owner confirms each wave before the next begins.
Run both platforms in parallel
Keep the existing platform and Wazuh receiving the same events, then compare alerts side by side for missed detections, new noise and timing differences. Each difference is logged and resolved against the gap register. The output is a comparison report with a disposition for every difference. Approval gate: the SOC lead and detection owner agree that no open difference affects a required detection.
Cut over and decommission the old platform
Move alert routing, response playbooks and reporting to Wazuh, keep the old platform read-only for the retention period agreed with compliance, and then retire its agents, collectors and servers. The output is a cutover record, updated runbooks and a decommissioning record for each removed component. Approval gate: the compliance lead confirms that log retention and evidence access are met before shutdown.
What to keep in-house and what to outsource
This table separates the migration decisions that stay with your security team from the build tasks that partners often take on, with the skills each side needs.
| Migration part | Usually kept in-house | Often outsourced | Skills required |
|---|---|---|---|
| Risk acceptance | Your security leadership decides which gaps from the old platform are accepted, deferred or closed during the move | Not applicable | Risk management, knowledge of your regulatory obligations, authority to accept residual risk |
| Which detections matter | Your analysts choose which legacy rules and alerts carry over, change or retire | Not applicable | Threat modeling, incident history, familiarity with current detection use cases |
| Alert triage ownership | Your SOC owns queues, severity definitions, escalation paths and on-call coverage for Wazuh alerts | Not applicable | SOC operations, incident handling, Wazuh alert levels and dashboard use |
| Cutover sign-off | Named owners approve the parallel-run results and the date the old SIEM stops receiving data | Not applicable | Change control, service ownership, evidence review for audit |
| Inventory tooling | Not applicable | Scripts and reports that list log sources, agents and existing rules from the old platform | Scripting, knowledge of the source SIEM export formats, log source inventory |
| Decoder and rule translation | Your engineers review translated logic and confirm intent for each rule | Converting legacy parsing and correlation logic into Wazuh decoders and rules | Wazuh rule and decoder syntax, regular expressions, SIEM content engineering |
| Platform build | Your team approves architecture, hosting location and retention settings | Installing and configuring the Wazuh indexer, server and dashboard in your environment | Wazuh indexer operations, Linux administration, certificate handling, sizing |
| Agent automation | Your endpoint team approves the agent groups and rollout waves | Playbooks or Ansible roles that remove old agents and enroll Wazuh agents | Linux and Windows agent administration, Ansible or Puppet, service accounts |
| Parallel-run comparison scripts | Your analysts define which event counts and alert pairs count as a match | Scripts that compare alert volumes and matched events between the old and new platforms | Query languages for both platforms, data analysis, log source knowledge |
| Runbooks | Your operations owners approve procedures and acceptance criteria before go-live | Drafted runbooks for installation, agent recovery, upgrades and rollback | Technical writing, Wazuh operations, knowledge of your change process |
What usually goes wrong in a Wazuh migration
Most migration problems trace back to detection logic, agent coverage, validation criteria, history and access that were never written down. Settle each item in the plan before cutover.
Rules and decoders that do not map cleanly
Rules from another SIEM or OSSEC rarely translate one-to-one into Wazuh rules and decoders, so a detection can disappear without any error. Export every active rule and local decoder, map each to a Wazuh equivalent or a documented gap, and record which log sources feed it. Review unmapped items with the detection owners before cutover.
Agent version and OS coverage gaps
Older Linux, legacy Windows, AIX or HP-UX hosts may not be supported by the Wazuh release you target, and the gap often appears during rollout. Build an inventory of operating systems and agent versions across the estate, then check each against the Wazuh compatibility documentation for your chosen 4.14 release before setting rollout dates.
Parallel running without success criteria
Running both platforms side by side proves little unless the team agrees in advance what a match means. Define measurable checks such as alert counts per source, detection of a fixed set of test events, dashboard and report parity, and an acceptable false positive rate. Get security operations to sign them off before parallel running starts.
History left behind without an archive plan
Old alerts and logs are often needed for investigations and audit evidence long after cutover, but migration plans frequently cover only new data. Decide how long historical data must stay searchable, whether it moves into the Wazuh indexer or an archive, and who may query it. Confirm the retention periods your auditors and legal team expect.
SSO and role mapping gaps at cutover
Local accounts, directory groups and SAML attributes from the old tool seldom line up with Wazuh roles on the first attempt. Map every identity provider group to an administrator or read-only role, test sign-in with each group in staging, and keep a local break-glass account with a tested recovery procedure.
Vulnerability detection that needs an unreachable feed
Wazuh vulnerability detection correlates agent software inventory with vulnerability data from the Wazuh CTI platform or an offline repository. In restricted networks that cannot reach the feed, results can be empty or stale. Confirm network paths early, and if the feed is blocked, set up the offline repository and plan how it will be updated.
How the migration changes by starting point
An older OSSEC deployment usually has the most familiar building blocks, since agents, decoders and rules have related concepts in Wazuh. The work is less about translation and more about confirming which pieces still apply.
- Agents: Plan agent replacement and enrollment with the Wazuh server, and confirm which agent versions can be upgraded in place.
- Rules and decoders: Compare local rules and decoders against the current Wazuh ruleset, since IDs, file names and behavior may differ. Confirm the mapping for your exact OSSEC version.
- Configuration: Confirm how your existing configuration files translate into Wazuh settings and agent groups.
- Alert history: Decide whether past OSSEC alerts are archived, imported or left in the old system, and confirm what the Wazuh indexer can ingest.
A commercial SIEM usually brings licensed content, proprietary agents and query logic that does not move automatically. The migration depends on how much of that content you can export and how much you need to rebuild.
- Licensed content: Confirm with the vendor which content packs, correlation rules and dashboards you are entitled to export, and whether they can be used outside that product.
- Exported rules: Review exported rules and convert them into Wazuh rules and decoders, testing each one against sample logs.
- Query logic: Rewrite vendor-specific search and correlation logic for the Wazuh dashboard and indexer, since query syntax differs.
- Agents and sources: Map each proprietary agent or connector to a Wazuh agent or agentless collection method, and confirm supported log sources in your environment.
A general log platform stores and searches events, but it usually does not detect threats the way a SIEM does. Parsing, searches and dashboards need to be rebuilt as Wazuh rules and views, and detection logic often starts from scratch.
- Parsing: Rebuild field extraction as Wazuh decoders, and test each source against representative events before enabling it.
- Searches and dashboards: Recreate saved searches as Wazuh dashboard views and confirm which visualizations your analysts actually use.
- Alert logic: Define detection rules and alert levels that replace any alerting in the old platform, and confirm how notifications are routed.
- Retention and access: Confirm retention requirements, user roles and any data that must stay in the old platform for a defined period.
An air-gapped deployment changes how Wazuh is installed and updated, and it changes where vulnerability data comes from. The Wazuh offline installation guide and offline vulnerability repository replace the online components that a connected deployment would use.
- Installation: Follow the offline installation guide, and plan how packages and dependencies are transferred into the network.
- Vulnerability data: Use an offline vulnerability repository in place of the Wazuh Cyber Threat Intelligence platform, and plan how it is refreshed.
- Updates: Plan how Wazuh patch releases and agent updates are staged, tested and moved across the boundary.
- Source migration: Confirm whether your old SIEM or OSSEC data can be moved inside the isolated network, and which approval steps apply.
What the client needs to provide
Before design begins, confirm the exact version of your current SIEM or OSSEC deployment and that the Wazuh target is the 4.14 patch line, the current release line at the time of scoping. Then collect exports of your existing detection content: custom rules, decoders, alert definitions, dashboards and retention settings. Ask the current owner which exports are authoritative and whether anyone edited rules directly on the server without keeping them in source control. Those undocumented edits are the most common gap in a migration inventory.
Provide an inventory of every endpoint and log source with its operating system version, agent version and role. List agentless devices such as firewalls and syslog senders separately, because they are collected differently. Map the network paths from each subnet to the Wazuh server, including any segments without internet access, since those hosts will need the offline vulnerability repository. Confirm the agent connection requirements in the Wazuh documentation for the 4.14 line against your firewall rules before the design is fixed.
Identify the hosts, virtual machines or cloud accounts that will run the Wazuh indexer, server and dashboard, along with the sizing inputs your team can supply, such as expected event volume and agent count. If single sign-on is in scope, provide the identity provider type, the SAML metadata your administrators can export, and the group names that should map to administrator and read-only roles. Name one owner each for detection content, cutover approval and alert triage.
Two decisions shape the plan and should be made early. The first is the length of the parallel-run window and the criteria that allow cutover, such as agreed alert coverage and an acceptable false-positive rate for the top rules. The second is historical data retention: whether old alerts are imported into the new indexer, kept read-only in the previous platform, or left to expire under existing policy. Have your compliance lead confirm any legal hold or retention obligation before that choice is made.
Frequently asked questions about Wazuh migration
Can our own team migrate from another SIEM to Wazuh without a partner?
Yes, if your team has Linux administration skills, hands-on experience running the Wazuh indexer, server and dashboard, and enough time to map detections and test them. The self-hosted Wazuh software has no license fee, so your main costs are staff time, infrastructure and testing. Teams without recent Wazuh operations experience often find rule mapping, validation and cutover take the most attention. Confirm your skills, capacity, rollback plan and change-control requirements before you decide.
What drives the cost and effort of a Wazuh migration?
The main drivers are the number of agents and log sources, the volume and complexity of existing rules and parsers, the event volume and retention you need, and how long the old and new platforms must run side by side. Cost falls into a few components: infrastructure for the indexer, server and dashboard, staff or partner time for mapping and testing, and ongoing support. Mapping, testing and cutover are one-time work, while infrastructure, upgrades and support recur. Ask any quote to itemize these components.
Do existing SIEM or OSSEC rules convert automatically into Wazuh?
No. Rules from another SIEM or an older OSSEC deployment must be inventoried, mapped to Wazuh decoders and rules, and tested before you rely on them. Field names, severity models and correlation logic often differ, and custom decoders need review even when the logic looks similar. Build a set of representative sample events with expected alerts for each detection, then confirm every mapped rule fires as intended and does not flood the dashboard with noise.
What happens to historical alerts when we move to Wazuh?
Alerts stored in the old platform do not move into the Wazuh indexer automatically. Common options are keeping the old system read-only for the required retention period, exporting records to an archive in a documented format, or loading selected records into the indexer for search. Each option carries storage, access and compliance implications. Confirm retention obligations with your compliance owner and check what export options the old platform offers before cutover.
Is parallel running required when moving to Wazuh?
It is not a technical requirement, but it is the usual way to show coverage before you switch. Run Wazuh alongside the existing SIEM, compare alerts for the same sources and close gaps before cutover. The length depends on how many sources and detections need comparison, how agents are replaced, and your change-control rules. Decide with your risk owners how long the comparison must run and which detections need sign-off before the old platform is retired.
How is a partner quote formed from a written migration scope?
DeployOpen works from a written scope agreed before work starts, and most engagements are fixed-scope. The quote follows from the scope items: source inventory, agent and platform counts, rules to map, decoders to write, test cases, parallel-running support, cutover support, documentation and handover. Ask that each item list its deliverables and assumptions, what is excluded, what you must provide, and which changes would trigger a change request. DeployOpen does not publish a price list.
How DeployOpen delivers Wazuh migrations
DeployOpen plans and implements Wazuh inside infrastructure you control, so a move from another SIEM, a log platform or an older OSSEC deployment is scoped, built and tested against your own rules, agents and retention needs. Engagements are fixed-scope, with the work agreed in writing before it starts.
How we scope
- Inventory current sources, agents, decoders, rules and alert consumers to show what must map to Wazuh and what can be retired.
- Agree in writing which log sources, rule sets, dashboards and integrations the migration covers and which are out of scope.
- Confirm the target deployment model, such as an offline installation guide for restricted networks, before any build begins.
- Record cutover criteria and the parallel running period so both sides agree what success looks like before work starts.
How we build
- Translate existing detection logic into Wazuh decoders and rules, then test each mapping against replayed or sample events from your environment.
- Plan agent replacement and enrollment by platform, covering Linux, Windows and macOS, with configuration managed centrally through agent groups.
- Run Wazuh alongside the existing platform in parallel, comparing alert volumes and detections before any source is switched over.
- Document each custom decoder and rule with its purpose and owner so later upgrades can be tested against a known baseline.
How we hand over
- Deliver runbooks for cutover, rollback, agent enrollment and day-to-day operation of the indexer, server and dashboard.
- Provide test results that show which detections were reproduced, changed or intentionally retired during the migration.
- Hand over configuration, custom rule sets and access controls in your repositories, with your team trained on operating them.
- Confirm decommissioning steps for the old platform, including data retention and archive handling agreed with your compliance owners.
How we support
- Offer ongoing support and upgrades on the Wazuh 4.14 line as a retainer, scoped separately from the migration project.
- Retest custom rules and decoders after each Wazuh patch release before they reach production.
- Review alert quality and tuning after cutover, adjusting rules where the new platform produces noise or gaps.
- Confirm with DeployOpen during scoping which support hours, response expectations and service terms apply to your retainer.
