Migrating from Wazuh to nPro: a planning guide
nPro Team · 18 September 2026 · 2 min read
Nobody leaves Wazuh because it detects badly. They leave because the indexer, the storage and the tuning became somebody's full-time job. What to inventory, what carries over, and when to stay put.
Wazuh is free, open source and genuinely capable. Teams rarely abandon it because the detection disappointed them. They abandon it because of what sits underneath.
Wazuh stack
Agents
Wazuh manager
Filebeat
OpenSearch indexer
cluster to tune
Dashboards
Separate NMS
second tool
nPro stack
Agents
nPro backend
ClickHouse
one store
dashboards and network monitoring included
Red blocks are where the operational load accumulates.
Four reasons teams actually move
None of these are detection problems.
Indexer cost outgrew the security budget. Retention gets trimmed to control storage, and the trimming always lands on the verbose sources that made lateral movement visible.
Upgrades became risky. Version drift between components, shard rebalancing, and the occasional weekend spent on an index that will not recover.
The person who configured it left. Custom rules nobody now understands, and no appetite to touch a working system.
Network monitoring lives in a separate tool. Correlating a security incident with its performance impact is a manual job across two interfaces.
Run both before you decommission either
A hard cutover on a security platform means a window where nothing is watching. Parallel running costs a fortnight of duplicated effort and removes that risk completely.
WK 1
Inventory
Agents, sources, retention, custom rules
WK 2
Deploy alongside
Wazuh stays untouched
WK 3 to 4
Diff detections
Same sources into both
WK 5
Decommission
Archive the old index
General guidance for any security platform migration, not an official nPro process.
The diff in weeks three and four is the part worth protecting. Anything one platform catches and the other misses is either a rule you need to rebuild or a genuine difference in coverage, and you want to know which before the old system is gone.
What you keep, what you rebuild
Both platforms share the same mental model: agents on hosts, rule-based detection, findings mapped to MITRE ATT&CK. The concepts transfer even where the implementation differs.
Carries over
Needs rebuilding
Custom rules are the item people underestimate. Wazuh rule syntax does not port directly, so budget time to translate the ones you rely on rather than assuming an import will handle it. Inventory them in week one and you will know the real size of the job before committing.
The storage difference
The architectural change that matters is the store. Wazuh indexes into OpenSearch. nPro writes to ClickHouse, a columnar database built for time-series data, which compresses log data heavily and removes the cluster tuning that consumes most Wazuh administration time.
That is the difference behind the cost complaint. It is not that Wazuh charges you anything. It is that the layer required to make Wazuh searchable at scale has its own hardware bill and its own maintenance burden, and neither appears in a comparison of licence fees.
Do not migrate if
Wazuh is working and you have an engineer who is comfortable running it. The licence is free, the rule engine is mature and the community is large. Migration is worth the disruption when the operational load is the problem, not when the detection is.
If you are still deciding rather than planning, the SIEM platform battlecard compares fifteen platforms including both, and nPro vs Wazuh covers the head-to-head in more detail.
Related reading
- How to Measure Your SIEM Compression Ratio (and Why the Published Figure Does Not Apply) Published compression ratios cannot tell you what your logs will compress to. Here is how to measure your own ratio and use it for sizing.
- Is there a self-hosted platform that combines SIEM, XDR and DLP? Most teams run SIEM, XDR and DLP as three separate products, and the DLP part usually inspects data in a vendor cloud. Here is what a single self-hosted platform looks like, the options available, and when it is the wrong choice.
- SIEM Storage Sizing: How to Calculate What You Actually Need The gigabytes-per-day figure is the least useful input. Here is how to size SIEM storage from your own event rate, compression ratio and retention policy.
See how nPro implements this
The documentation covers configuration, agent deployment and the current status of each capability.