Splunk Enterprise Security is usually the best security product in the building and the one finance asks about first. That tension is the whole migration. The platform is priced on how much you send it, so the security team’s instinct (log everything, keep it forever) is in permanent conflict with the budget, and every new log source turns into a business case. Wazuh is the most common open destination because it is the only free platform that covers log collection, correlation, file-integrity monitoring, and compliance reporting in one project. What it is not is a drop-in replacement for a search platform, and the gap is where migrations fail.
Start by auditing what actually fires
Do not begin with architecture. Begin with a query against your own alerting history, because the single biggest determinant of how hard this migration is is a number you probably do not know yet: how many of your correlation searches have produced an alert a human acted on in the last twelve months.
In most estates the answer is uncomfortable. A few dozen searches carry the entire programme, several hundred exist because someone enabled a content pack, and a long tail has been silently erroring since a field extraction changed. Rank them by real-world usefulness and draw a line. Everything above the line gets reimplemented deliberately. Everything below it gets deleted, and deleting it is a genuine improvement rather than a compromise, because carrying dead detection content into a new platform is how you arrive on day one with a console nobody trusts.
Do the same exercise for sourcetypes. For each one, ask what detection or investigation would become impossible without it. Sources that survive that question are the ones you re-point at Wazuh. Sources that do not are the ones you stop paying to index anywhere.
The mapping
- Universal forwarders → Wazuh agents, deployed via the same configuration management you already use for the forwarder estate.
- HTTP Event Collector and syslog inputs → Wazuh’s syslog listener, Filebeat, or the agent’s
localfilecollection. - Field extractions and CIM normalization → Wazuh decoders, which parse at ingest rather than at search time.
- Correlation searches → Wazuh rules (XML, evaluated as events arrive), with
frequencyandtimeframefor the stateful ones. - Lookups and asset lists → CDB lists, the flat key-value files Wazuh rules can test against.
- Notable events and incident review → an external case platform (TheHive is the usual pairing); Wazuh does not provide this.
- Adaptive response actions → Wazuh active response scripts.
- ES compliance dashboards → Wazuh’s SCA policies and regulatory templates (PCI DSS, HIPAA, NIST 800-53).
The search-time versus ingest-time inversion
This is the conceptual shift that catches teams, and it is worth understanding before you write a single rule. Splunk indexes raw events and does the clever work when you search: schema-on-read means you can ask a question today about data you collected last year, using a field you only just decided to extract. Wazuh decodes and evaluates at ingest: a rule either matched when the event arrived, or it did not.
The practical consequences are concrete. Retroactive hunting across historical data, the thing an analyst does when a new indicator lands, is materially weaker in Wazuh because the correlation already happened or did not. Conversely, detection latency improves, because you are not waiting for a scheduled search to run. And crucially, if you get a decoder wrong, you do not silently get worse search results, you get no alert at all. Decoder testing therefore becomes a first-class activity rather than an afterthought, and wazuh-logtest becomes the tool your detection engineers live in.
Teams that need genuine retrospective search alongside Wazuh’s real-time rules usually keep the OpenSearch indexer’s raw data queryable through the dashboard and accept that the query language and ergonomics are a step down from SPL. Be honest with your analysts about that up front rather than letting them discover it in week three.
Sizing the thing you now own
Splunk’s licence made capacity somebody else’s problem in one specific sense: you knew what a gigabyte cost. Self-hosting inverts that. The Wazuh manager handles decoding and rule evaluation and is CPU-bound; the indexer stores and searches and is disk and memory-bound; the dashboard is comparatively trivial.
Size the indexer from daily indexed volume and required hot retention, not from endpoint count, and add capacity for at least one replica shard unless you are genuinely willing to lose a node’s worth of data. Put hot indices on fast local storage, because search performance on spinning disk will destroy analyst confidence faster than any missing feature. Then plan the lifecycle policy that moves warm data to cheaper storage and eventually deletes it, and make sure the deletion point is the one your compliance obligation actually requires rather than the one someone guessed.
Budget for this properly. A self-hosted SIEM at real enterprise volume is a multi-node cluster with a maintenance burden, and pretending otherwise is how these projects acquire a reputation for false economy.
Running both, and the order of operations
- Audit sourcetypes and correlation searches as above, and get the retention obligation per source in writing.
- Build the Wazuh cluster sized for your surviving volume, with the indexer lifecycle policy configured from day one rather than retrofitted.
- Onboard sources in tiers, starting with the ones whose decoders are easiest to validate (endpoint agents, standard syslog) and ending with the bespoke application logs that needed custom field extractions in Splunk.
- Reimplement the surviving detections, testing every decoder with
wazuh-logtestand every rule against a replayed sample of real events before enabling it. - Wire up case management and active response, so an alert has somewhere to go and something to do.
- Parallel-ingest through a full detection-test cycle and at least one month-end, comparing what fires on each platform and investigating every discrepancy in both directions.
- Reduce the Splunk licence tier first, cancel second. Dropping ingest volume while keeping search access is the low-risk intermediate step, and it starts saving money months before the cutover completes.
The commercial timing that actually matters
Splunk contracts renew annually and the notice period is usually generous to Splunk, not to you. Work backwards from the renewal date with real dates: the parallel-ingest quarter, the tiering-down step, and the notice deadline. Teams that start this project three months before renewal end up either signing another year under time pressure or cutting the validation period short, and the second option is how a coverage gap gets into production.
If your renewal is closer than two quarters, the honest play is to negotiate a shorter or reduced-volume term now with the migration as your stated leverage, then execute properly against the following renewal.
Clearing the bar before you cut over
The acceptance criteria are specific and testable. Every surviving detection has fired correctly against a replayed real event. Every decoder has been validated against live production log samples, not synthetic ones. Analysts have worked real incidents end to end in the new case workflow. Compliance reports render with the evidence your auditor asked for last cycle. Indexer capacity has survived a peak day with headroom. And you know, in writing, what happens to historical data.
The short version
Splunk ES to Wazuh removes an ingest meter and hands you a cluster to operate, a decoder estate to maintain, and a weaker retroactive-search story in exchange. It is a genuinely good trade for organisations whose detection content is smaller than their licence suggests, which is most of them, and a poor trade for teams who use SPL as an investigative tool every day. Audit what fires before you cost anything, model the per-endpoint figures in the calculator above as illustrative, and treat the storage and staffing you take on as part of the price rather than a rounding error.