Migrate from Splunk to Wazuh

Migrate from Splunk to Wazuh: what the move involves and who does it

Moving security monitoring from Splunk to Wazuh is a rebuild of collection, detections and retention, not a copy of data from one store to another. If your renewal, data residency requirement or licensing change is what brings you here, plan the work as four workstreams: replacing forwarders with Wazuh agents, rewriting correlation searches as decoders and rules, deciding what historical data leaves Splunk and where it lives, and running both platforms until detections agree. Splunk has real strengths here, including SPL, a mature app ecosystem and years of tuned content, and your team will lose some of that convenience. The work is also where most of the effort sits, because every saved search has to be understood before it can be reproduced.

Security engineering usually leads the move, with the platform team owning the indexer and server sizing, the agent rollout and the upgrade calendar. An implementation partner is often brought in for the parts that are easy to underestimate: decoder work for custom log sources, rule translation, the parallel-run comparison and the hardening of the new environment. Wazuh is licensed under the GNU General Public License version 2, so the software itself carries no license fee, but you pay for compute, storage, staff time and any outside support you choose. Its four components are the Wazuh indexer, which stores alerts, the Wazuh server, which runs decoders and rules, the Wazuh dashboard, and the agents on endpoints. Confirm each component's sizing against your current daily volume and retention targets before you commit a budget.

The effort and risk depend mostly on how many correlation searches and alerts you run, how many log sources feed them, and whether your auditors expect continuity of evidence across the cutover. Ask any partner to inventory every saved search, alert and dashboard before quoting, and to state which items they expect to rebuild, which they expect to retire and which need your decision. Keep a dated record of each detection's old and new behavior, because that record is what your assessors will ask to see. Keep Splunk running in read-only mode until both platforms have produced matching alerts for an agreed period, and agree in writing who signs off the cutover.

Which Splunk capabilities map cleanly to Wazuh and which need rework

This table maps the Splunk capabilities most teams depend on to their Wazuh equivalents and marks each as clean, needs rework or gap. Use it to scope the migration backlog, then confirm each row against the Wazuh documentation for your version. The main takeaway is that agents, FIM, vulnerability data and compliance dashboards have direct Wazuh counterparts, while SPL correlation logic and custom Splunk apps need rewriting and testing.

Splunk capability	Wazuh equivalent	Status
Universal forwarders	Wazuh agents on Linux, Windows, macOS, Solaris, AIX and HP-UX, managed centrally by the Wazuh server; agentless syslog collection covers devices such as firewalls	Clean for endpoints; rework for forwarder inputs that need custom parsing
SPL correlation searches	Wazuh decoders extract fields and rules raise alerts; multi-event logic needs rules written and tested against sample events	Needs rework
Saved-search alerts	Wazuh rules with alert levels and output to the dashboard, syslog or integrations; scheduled SPL timing must be reproduced in rule logic	Needs rework
Splunk Web dashboards	Wazuh dashboard views for security events, agents and alerts; custom panels built in the dashboard tooling	Needs rework
Compliance views	Prebuilt Wazuh dashboard views for PCI DSS, GDPR, HIPAA and NIST 800-53; confirm control mapping against your own assessor's requirements	Clean for the listed frameworks
File integrity monitoring	Wazuh syscheck-based file integrity monitoring on monitored agents, with alerts indexed for search	Clean
Vulnerability data	Wazuh vulnerability detection correlating agent software inventory with CTI or an offline repository	Clean; confirm feed source for air-gapped sites
Splunk Web users and roles	Wazuh dashboard user administration, with single sign-on configurable per the Wazuh SSO guide; confirm role mapping to your current Splunk roles	Needs rework
Custom Splunk apps and Splunk-specific searches	No direct equivalent; confirm each item against the Wazuh documentation before scoping	Gap, to confirm

Exporting historical Splunk events through the CLI and REST API

Before any Wazuh rule is written, the historical events you need for investigations and audit must leave Splunk in a form you control. Splunk documents several export paths: saved search results through Splunk Web, the CLI, the REST API, the SDKs, the dump search command and data forwarding. Splunk describes the CLI as its most stable retrieval method, so for scripted, repeatable pulls of large result sets it is usually the first path to test. Use Splunk Web for small, one-off extracts that an analyst needs to review, and reserve the REST API and SDKs for cases where a script must page through results over time. Data forwarding moves live events rather than history, so it belongs to the parallel-run phase, not the archive phase.

Match the path to the volume. For a short window of a few hosts, a CLI search that writes JSON or raw events to a file is enough. For a full retention period across all sources, run the export in time-bounded slices, such as one day or one index at a time, and record the row count and a checksum for each slice so you can prove completeness later. Expect exported raw events or JSON to be plain text, not Wazuh alerts. Each source format must be re-ingested through a Wazuh decoder and the matching rules before the events are searchable as security data, so test the decoder on a sample of each sourcetype before you start bulk re-ingestion. Confirm with your Wazuh deployment team how the historical events will be indexed, so they do not mix with live alerts or distort dashboards.

Retention of exported data is a policy decision, not a technical default. Decide with legal, compliance and the data owners which indexes must be kept, for how long, where the files are stored, who may read them and how they are deleted at the end of the period. Record that decision before the first export runs. If you use Splunk Cloud Platform, archive options for expired index data are covered in the export guide linked from this page, but access to those archive features depends on your subscription and roles, so confirm with Splunk what your account permits before you plan around them.

The migration sequence from inventory to Splunk decommissioning

This sequence moves security monitoring from Splunk to Wazuh in controlled stages, so each source group is proven against existing detections before Splunk stops receiving it. Each stage ends with a named output that the next stage depends on.

Inventory sources, forwarders and correlation searches
Build a source register that lists every host, network device and application sending data to Splunk, the forwarder or input that carries it, and the index it lands in. Export the saved searches, correlation searches and alerts that depend on those sources, and tag each one with the owner who relies on it. Ask your Splunk administrator to confirm which data is actually consumed by a search or dashboard, since unused feeds are the easiest to retire. The step is complete when the source register and a list of detections both cover every feed, with no unowned entries left.
Stand up Wazuh and pilot agents on one host group
Deploy the Wazuh indexer, server and dashboard using one of the documented deployment options, then install Wazuh agents on a defined host group, such as a single server role or one business unit. Where the network has no internet access, follow the Wazuh offline installation guide, and plan the offline vulnerability repository if vulnerability detection is needed. Write the first decoders and rules for the pilot sources, and confirm that agent check-ins, file integrity monitoring and log analysis all appear in the dashboard. The output is a working pilot with a documented decoder and rule set, kept in version control.
Rewrite correlation searches as Wazuh rules
For each SPL correlation search in the source register, define the equivalent Wazuh decoder fields and rule logic, including the time window, thresholds and grouping that the original search used. Document any search that depends on a Splunk app, lookup or enrichment that Wazuh does not provide, and assign it to a custom integration or to a separate tool. Review each rule with the team that owns the detection, because the logic is rewritten rather than copied. The output is a versioned rule set with a mapping table from each original search to its Wazuh rule or documented gap.
Run Splunk and Wazuh in parallel and compare matches
Keep the pilot host group sending data to both platforms, and run the rewritten rules against the same period of events. Compare the alerts each platform raises, and record every case where one fires and the other does not, with the reason. Adjust decoders and rules until the alerts match for the agreed test cases, and document any intentional differences for sign-off by the detection owners. The output is a match report that shows, for each detection, whether it matched, diverged or was retired, and who approved the result.
Cut over source groups with a runbook
Move the remaining source groups one at a time, starting with those that carry the fewest dependencies, and repeat the parallel run for each group before its Splunk forwarder is removed. For each group, write a cutover runbook that lists the agent deployment method, the configuration change, the validation checks, the rollback path and the named approver. Use the Wazuh server's remote configuration and upgrade management to keep agents consistent across the groups. The output is a completed runbook per group and a record that Splunk no longer receives that group's data.
Export historical data and decommission Splunk
Before turning off Splunk, export the search results and events that your retention or audit obligations require, using the retrieval methods that Splunk documents, such as the CLI for large volumes. Store the exports in an access-controlled archive with checksums and a retention schedule that your compliance team has approved. Confirm the archive can be read without Splunk, then disable inputs, remove licenses and shut down the indexers only after the archive is verified. The output is a verified archive, a decommissioning record signed by the platform owner, and a final list of anything that was intentionally not carried over.

How the migration differs by estate size and deployment model

A small estate with a limited number of endpoints and one site can usually start with Wazuh's prebuilt virtual appliance or the all-in-one installation. These options place the indexer, server and dashboard on one host, which keeps the first build short and gives the team a working environment to test decoders and rules against real Splunk data. The work shifts toward agent rollout and rule translation, because the platform side is already assembled.

Install method: The prebuilt OVA or the all-in-one script puts all four components on one system, which suits a pilot or a single-site deployment.
Agent rollout: Replace Universal Forwarders host by host, starting with the hosts that feed the highest-value Splunk correlation searches.
Rule work: Map each saved search to a Wazuh decoder and rule, then test it against exported events before retiring the Splunk alert.
Growth limit: Confirm that one node will hold the planned retention and event rate before the parallel run ends, because a later move to a cluster is extra work.
Exit plan: Keep Splunk receiving the same data until the Wazuh alerts match the expected results.

Before committing, ask your implementation partner to confirm the node sizing for your current daily event volume and your retention period.

What drives the cost and duration of the Wazuh migration

This table lists the cost components of moving from Splunk to Wazuh and the drivers that move effort up or down for each. Read it as a checklist for scoping and for comparing written quotes, since no price or duration is given here.

Driver or component	Why it moves cost or effort	How to keep it down or what to ask for
Internal staff time for detection rewriting	Each SPL correlation search must be re-expressed as Wazuh decoders and rules, then tested against the same events. Complex searches with lookups, subsearches or statistical thresholds take longer than simple field matches.	Inventory searches by alert volume and business owner first. Retire unused searches before rewriting. Ask the quote to state how many searches are in scope and who validates each rule.
Number of forwarders and endpoints	Every universal forwarder replaced by a Wazuh agent needs a deployment, a group assignment and a check that events arrive. Large fleets add rollout waves, change windows and exceptions.	Group endpoints by operating system and role so one configuration covers many hosts. Ask for the rollout method (Ansible, Puppet or configuration management) and the rollback plan.
Compliance scope	Each framework in scope, such as PCI DSS, GDPR, HIPAA or NIST 800-53, adds mapping work, dashboard checks and evidence collection. Wazuh's dashboard includes prebuilt views for these frameworks, but assessors still expect your own control mapping.	Limit the first phase to frameworks that the next audit actually tests. Confirm with the assessor which evidence they accept from Wazuh views and exports.
Historical retention and export	Splunk search results can be exported through the CLI or REST API, but large historical sets need time-bounded searches and storage in the new indexer. Longer retention raises indexer disk, backup and search cost.	Decide the retention period per data type before export. Export only the window that open investigations or audits need, and ask the quote to separate export effort from storage sizing.
Air-gapped or offline requirements	Wazuh's offline installation guide covers systems without internet connectivity, and vulnerability detection can use an offline repository instead of the Wazuh CTI platform. Offline updates, package transfer and repository refreshes add recurring operator work.	Confirm early whether the environment is air-gapped. Ask the quote to include the offline update process and who performs it each cycle.
Infrastructure for indexer, server and dashboard	Recurring hosting cost depends on event volume, retention, cluster size and high availability. The Wazuh server can run as a cluster for horizontal scaling, which adds nodes and load balancing.	Size from measured daily event volume during the parallel run, not from estimates. Ask for the sizing assumptions in writing.
Parallel-run licensing overlap with Splunk	Splunk licensing or subscription continues while Wazuh runs beside it, so the overlap period is a cost in its own right. The length of that period is set by how long detections take to match.	Negotiate the Splunk renewal term against the parallel-run plan before the renewal date. Track the exit criteria so the overlap ends when detections match.
Outside implementation and ongoing support	Fixed-scope implementation is priced from the written scope. Ongoing support, upgrades and continuous testing are separate retainers. Wazuh releases patch updates regularly, so upgrade work recurs.	Ask for a written scope listing deliverables, timelines and exclusions. Separate one-time migration work from recurring upgrade and support items in the quote.

What usually goes wrong when moving from Splunk to Wazuh

Most failed Splunk to Wazuh moves do not fail at installation. They fail in the gaps between what Splunk searches expected and what Wazuh decoders, rules, agents and retention actually deliver. The cards below cover the risks that tend to surface during parallel running and cutover, with a prevention step for each.

Decoders missing SPL fields

An SPL search that filters on a field such as a user, process or destination port will return nothing if no Wazuh decoder extracts that field from the same log. Inventory every field your correlation searches reference, then sample each source type and confirm the decoder produces the same field name and value format before you retire the Splunk search. Treat a silent empty result as a failure, not a clean bill of health.

Alert volume drift in parallel runs

Running Splunk and Wazuh side by side will show different alert counts because rule logic, thresholds and deduplication differ between the two platforms. Without a comparison method, teams either ignore the gap or tune Wazuh until it looks quiet, which hides real detections. Record alert counts per rule and per source for the same time window in both systems, then investigate each mismatch until the reason is known and accepted in writing.

Hosts with no Wazuh agent

Splunk coverage is often built from forwarders that were deployed years ago and never inventoried, so some servers, appliances or cloud workloads may send logs to Splunk but have no Wazuh agent after cutover. Hosts without an agent also lose file integrity monitoring and inventory data. Reconcile the Splunk forwarder list against the Wazuh agent inventory, and cover agentless sources such as firewalls through syslog collection where an agent cannot be installed.

Retention gaps for historical searches

Wazuh stores alerts in the indexer on retention settings you define, so historical Splunk data does not move automatically. Investigators who later need six months of raw events may find that only the Splunk archive holds them. Decide retention per data class before cutover, then export the Splunk results your auditors and investigators need through the CLI or REST API, and confirm the export is readable before you decommission Splunk storage.

Unplanned upgrades within 4.14

Wazuh patch releases in the 4.14 line arrive roughly every one to two months, and an upgrade can change decoders, rule files or dashboard behavior that your tuned detections depend on. An upgrade made during a parallel run makes the comparison meaningless. Pin a change window, test each patch on a copy of your rules and decoders, and record the version in every detection review so a sudden change in alert counts can be traced.

Losing saved-search ownership

Splunk saved searches, alerts and dashboards are usually owned by named analysts, and their logic often lives only in those personal objects. When the migration ends, nobody may know which detection covered which control. Export the saved-search inventory with owner, schedule and purpose, then map each entry to a Wazuh rule, a dashboard or a documented retirement decision with a named owner who signs off.

Questions buyers ask before moving from Splunk to Wazuh

How much effort does a move from Splunk to Wazuh take?

The effort depends mostly on how much detection logic lives in Splunk and how many sources report to it. Each forwarder you replace with a Wazuh agent is a deployment and configuration task, and each SPL correlation search has to be rewritten as Wazuh decoders and rules and then tested. Teams with a small set of saved searches and a few source types usually have a much smaller job than teams with custom apps, dozens of dashboards and many alert actions. Ask for an inventory of forwarders, indexes, saved searches, alert actions and dashboards before anyone estimates the work, because that inventory sets the scope.

How long does a Splunk to Wazuh migration take?

The timeline depends on the size of the inventory, the number of endpoints and log sources still to onboard, how many detections need rewriting, and how long you run both platforms in parallel before cutting over. Change approval windows, the availability of security analysts to validate alerts, and the release cadence of your own change process also affect the schedule. Wazuh's 4.14 release line receives patch releases roughly every one to two months, so plan an upgrade window into the project. Agree on a written timeline with milestones, and confirm the dates with your own change board.

Can our internal team migrate from Splunk to Wazuh alone?

Many teams with Linux administration skills and an experienced security engineer can deploy the Wazuh server, indexer and dashboard and roll out agents themselves, because Wazuh is free under GPLv2 and documents several installation paths. The harder parts are translating detections, tuning rules to remove false positives, and validating coverage against compliance expectations. If those skills or hours are missing internally, a fixed-scope engagement can cover planning, implementation, integration and documentation with deliverables agreed in writing before work starts. DeployOpen implements and hardens self-hosted platforms in your environment, and it does not issue audit reports or certifications.

What does the work need from our internal staff?

Internal staff need to supply the knowledge that no migration tool carries over. Security analysts must explain which alerts they act on, which ones they ignore, and which compliance views auditors expect. Platform engineers must provide access to network segments, cloud accounts, identity systems and change windows. System owners must approve agent rollouts on production hosts. Plan for these people to be available during detection validation, because Splunk searches often encode local knowledge that is not written down anywhere. Name an owner for each detection before the rewrite starts.

Can we keep historical Splunk data when we move to Wazuh?

Yes, historical events can usually be kept, but they do not move into Wazuh automatically. Splunk exports search results as raw events, CSV, JSON, XML or PDF through Splunk Web, the CLI, the REST API, SDKs, the dump search command or data forwarding. Splunk describes the CLI as its most stable retrieval method, which suits large exports better than a browser download. Decide which data must stay queryable, which can move to cold archive files, and which can be dropped under your retention policy. Confirm the retention periods your compliance obligations require before you choose an export method, and keep the exported files encrypted and access-controlled.

Do we have to run Splunk in parallel with Wazuh?

Running both platforms in parallel is the safer route for most security teams, because it lets you compare alerts until the Wazuh detections match what Splunk produces. Keep Splunk receiving the same sources while Wazuh agents and rules are validated, and compare alert volumes, true positives and missed events for each detection. Parallel running has a cost: you keep paying for Splunk licensing or workload charges, and you run two stacks. Set an end date for the overlap in advance, and confirm the Splunk renewal terms with your vendor so that the parallel period does not extend the contract by accident.

How DeployOpen scopes, runs and supports the Splunk to Wazuh move

DeployOpen is a Chainscore Labs company that plans, implements, integrates, hardens, backs up, documents and supports Wazuh inside your own infrastructure. The cards below follow the order of a typical engagement: a written scope first, then the build and cutover, then the evidence and the run phase that follows.

Written scope before any build

Most engagements are fixed-scope, so the agreed scope, deliverables and timelines are written down before work starts. For a Splunk to Wazuh move, that scope should list the forwarder fleet, the Splunk apps and saved searches in use, the correlation searches to be rebuilt, and the data sources that stay on Splunk during parallel running. Ask for the scope in writing and check that each Splunk use case has a named owner and a success check.

Quotes follow from the scope

DeployOpen does not publish a price list. A quote follows from the written scope, so the inputs that move cost are the number of endpoints and network devices, the number of detection use cases, the volume of historical data to export, and the compliance frameworks in scope. Ask any provider, including DeployOpen, to itemize build, data migration, testing and handover so you can see what is one-time and what recurs.

Agent rollout and decoder work

Replacing universal forwarders with Wazuh agents is a deployment project in its own right. Agents must be installed, enrolled and tested on each platform class, and custom decoders and rules must parse the log sources that Splunk previously indexed. DeployOpen plans that rollout with your change process, configures agent groups and central configuration, and documents the exceptions for hosts that cannot take an agent.

Hardening the Wazuh deployment

A Wazuh server, indexer and dashboard hold security telemetry, so their own hardening matters. The work covers TLS between components, access control for the dashboard, single sign-on where your identity provider supports it, host baselines, and network segmentation. Confirm which Wazuh single sign-on options fit your identity stack before the design is frozen.

Backup, restore and upgrade planning

Backups of the Wazuh indexer and configuration, tested restores, and a documented upgrade path are what keep a self-hosted SIEM recoverable. Wazuh publishes patch releases on a steady cadence, so the upgrade procedure is a recurring task rather than a one-off. Ask how restores are tested and who signs off that a restore met the recovery target.

Documentation and compliance evidence

DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies perform those assessments. The handover pack typically includes architecture, data flow, detection catalog, runbooks and the evidence that each in-scope control operates, so your auditor has material to test.

Retainers for upgrades and support

Ongoing support, upgrades and continuous testing are available as retainers after the initial move. A retainer usually covers patch application, rule tuning, agent health checks and incident support, and it is priced from the agreed scope of that support. Ask what response commitments the retainer contains in writing, and whether the retainer covers Wazuh upgrades on your schedule.

Migrate from Splunk to Wazuh