Splunk vs Wazuh: when each fits and what the decision turns on
A security or platform lead facing a Splunk renewal, a licensing change or a data residency requirement usually needs one answer first: is the team buying a search language and an app ecosystem, or buying a security platform it can run itself? Splunk fits teams that are invested in SPL, Enterprise Security content and the Splunk app ecosystem, and that accept a commercial license tied to their data or workload. Wazuh fits teams that want a free, GPLv2 XDR and SIEM platform inside their own infrastructure, with its own agents, rules and dashboards, and that are willing to operate it. Cisco completed its acquisition of Splunk on March 18, 2024, so a renewal now sits inside a larger vendor's roadmap, which is one reason many buyers start this comparison.
Wazuh is not a drop-in copy of Splunk. It is four components: the Wazuh indexer, which stores alerts, the Wazuh server, which decodes and analyzes agent data with rules, the Wazuh dashboard, and the Wazuh agents on endpoints. Its agents cover Linux, Windows, macOS, Solaris, AIX and HP-UX, and agentless devices such as firewalls can feed it through syslog and periodic API probing. The dashboard ships prebuilt compliance views for PCI DSS, GDPR, HIPAA and NIST 800-53. Splunk's strength sits elsewhere: SPL, mature correlation content in Enterprise Security, and a large set of third-party apps. Teams should inventory their existing correlation searches and dashboards and decide how many can be rebuilt as Wazuh rules and decoders, and how many would be lost.
The decision turns on four things. First, detection content needs: list the correlation searches that matter most and check which have Wazuh rule equivalents. Second, team skills: SPL expertise is not the same as writing Wazuh decoders and rules, and an in-house team may need training or outside help. Third, endpoint and agentless coverage: confirm which operating systems and network devices must send data, and which can only use syslog. Fourth, operating effort: Wazuh removes the license line, but the indexer sizing, cluster design, upgrades and rule tuning fall to your team or a partner. Ask any implementation partner for a written scope covering those items before comparing prices with a Splunk quote.
Which platform fits which buyer situation
This table maps common buyer situations to the platform that usually fits better and the reason behind it. Read each row as a starting point: the fit depends on your sources, staff and existing Splunk content, so confirm each reason against your own environment before deciding.
| Buyer situation | Better fit | Reason |
|---|---|---|
| Renewal driven by license cost | Wazuh, with the Splunk renewal priced as a separate line | Wazuh is free under GPLv2, so the recurring license fee disappears, but you still fund compute, storage, staff time and any outside support. Ask Splunk for a renewal quote and model the same inputs for Wazuh before deciding. |
| Strict data residency or air-gapped networks | Wazuh | Wazuh documents an offline installation guide for systems without internet connectivity, and vulnerability detection can use an offline vulnerability repository instead of the CTI platform. Confirm that every component and update path works inside your boundary. |
| Heavy SPL and Enterprise Security content | Splunk, for the near term | Splunk's search language and Enterprise Security app hold years of correlation searches and workflows. Rewriting them as Wazuh decoders and rules is real work, so plan a parallel run and check detection parity before cutting over. |
| Endpoint-focused compliance reporting | Wazuh | Wazuh agents cover Linux, Windows, macOS, Solaris, AIX and HP-UX, and the dashboard includes prebuilt views for PCI DSS, GDPR, HIPAA and NIST 800-53. Ask an assessor which evidence they accept from these views before relying on them. |
| Mixed estate with network devices and firewalls | Wazuh, with syslog collection | Wazuh supports agentless monitoring of devices such as firewalls through syslog collection and periodic API probing. Confirm the log volume and parsing needs of each device class before assuming full coverage. |
| Large log volumes beyond endpoint security | Splunk or OpenSearch, depending on use | Wazuh's indexer stores alerts, so general application and infrastructure log analytics may need a separate OpenSearch cluster. Test indexing and retention at your daily volume before choosing one platform for everything. |
| Thin SIEM staff | Splunk or a managed Wazuh service, to be checked | Wazuh requires you to maintain the indexer, server, dashboard and agents, and patch releases arrive roughly every one to two months. If staff time is limited, compare a fixed-scope implementation and retainer with Splunk's support model. |
How Wazuh covers endpoint monitoring and compliance views
Wazuh covers endpoint monitoring through four components: the Wazuh indexer, which stores and searches alerts, the Wazuh server, which analyzes agent data with decoders and rules, the Wazuh dashboard, which is the web interface, and the Wazuh agents installed on endpoints. The agents run on Linux, Windows, macOS, Solaris, AIX and HP-UX, so the first check is an OS inventory of your fleet against that list. Confirm the agent versions your endpoints can run and whether any legacy or specialty hosts need a different approach. For devices that cannot host an agent, such as firewalls, Wazuh collects syslog and probes APIs on a schedule. Your team should confirm which log formats and API endpoints each device model supports before counting those devices as covered.
Wazuh also adds file integrity monitoring and vulnerability detection on the same agents. Vulnerability detection correlates the software inventory that agents collect with vulnerability data from the Wazuh Cyber Threat Intelligence platform or from an offline repository you maintain. Networks without internet access should plan for the offline repository from the start, using the offline installation guide, and should confirm how often that repository is refreshed. The dashboard ships prebuilt compliance views for PCI DSS, GDPR, HIPAA and NIST 800-53. Treat these views as readiness aids that show which rules and alerts map to each framework. They do not establish compliance. Your assessor or certification body decides whether your controls meet a requirement, so ask them early which evidence they expect from the dashboard and which exports they will accept.
Where Splunk's search language and app ecosystem still lead
Splunk's advantages sit mostly in how analysts query data, how much prebuilt content they inherit, and how easily they can take results out. Each point below matters only under specific conditions, and each one has a cost to plan for when the platform moves to Wazuh and OpenSearch.
SPL depth for ad hoc investigation
SPL lets analysts pivot, aggregate and correlate events in a single search line without building an index or a rule first. Teams that hunt across unfamiliar data sources every week will feel the difference most. Before committing, have two or three senior analysts write their usual investigations in the Wazuh dashboard and in OpenSearch query tools, and time how long each one takes.
Breadth of Splunk apps and add-ons
Splunk's app and add-on catalog covers many vendor products with parsing, field extraction and dashboards already written. This matters when your estate includes many niche SaaS or on-premises sources. Inventory every data source you ingest today, then check which ones have a maintained Wazuh decoder or an OpenSearch ingestion path, and which ones you would write yourself.
Dashboards and saved searches built by staff
Years of saved searches, alerts and dashboards carry operational knowledge that is hard to see in a single export. Their value rises with the number of people who depend on them each day. Export the list of saved searches and alerts, mark which ones drive on-call paging or audit evidence, and decide which ones must be rebuilt before cutover.
Vendor-supplied detection content
Splunk Enterprise Security ships correlation searches and detection content maintained by the vendor, which reduces the authoring work your own team carries. Wazuh ships its own rules and decoders, but your team owns the tuning and the coverage gaps. Ask Splunk for the list of content enabled in your environment and map each item to a Wazuh rule, a custom rule or a gap you accept.
Export paths as a retention consideration
Splunk exposes search results through Splunk Web, the CLI, the REST API, SDKs and saved searches, which gives you several routes to keep evidence after a move. The right route depends on the volume you must retain. Confirm with Splunk which method your team will use for historical events, test a large export end to end, and store the output in a format your auditors can read.
Rewriting searches as Wazuh rules and decoders
SPL searches do not translate directly into Wazuh decoders and rules. Each correlation needs to be expressed as a decoder for parsing and a rule for matching, and some logic will need a different design. Choose a representative set of twenty or so high-value searches, rewrite them, and run both systems in parallel until alert output matches what your analysts expect.
How the Wazuh indexer and server scale with volume
The first scaling decision is which Wazuh component is the bottleneck, because the Wazuh server and the Wazuh indexer grow for different reasons. The Wazuh server analyzes agent data with decoders and rules, and it can run as a cluster for horizontal scaling. The cluster also lets you manage agent configuration and upgrades remotely, which matters once you have more than a handful of endpoint groups. The Wazuh indexer is the full-text search and analytics engine that stores alerts, so its disk, memory and shard layout determine how long you can keep searchable history. Plan these two tiers separately rather than assuming one node size fits both.
Sizing is driven by four inputs: the number of enrolled agents, the sustained event rate per agent, the retention period for alerts and archived events, and the alert volume that your rules produce. Alert volume is the input teams most often underestimate. A noisy rule set multiplies storage and dashboard load even when the raw event rate is modest, so tuning detections before you size the cluster reduces hardware spend. Ask your Wazuh contact or the vendor documentation for the current sizing guidance for each component and the hardware profiles it assumes, and confirm which of those assumptions match your environment.
Do not rely on general figures for throughput. Run a proof of concept in your own environment with a representative subset of agents, your real log sources, your production retention settings and your actual rule set, then measure indexing lag, query response in the dashboard and disk growth over several days. Record the results and compare them with the sizing guidance, and repeat the test after you add the next group of agents. If you need outside help with the proof of concept, the scope, deliverables and timeline should be agreed in writing before the work starts.
Data location, hosting models and identity implications
Splunk Enterprise and Splunk Cloud Platform place your data in different locations, so the first question is which one your contract covers. With Splunk Enterprise, indexes, configuration and search heads sit on servers you or your hosting provider operate, so data location follows your own infrastructure. With Splunk Cloud Platform, Splunk operates the environment, and the region and data handling terms come from the agreement and service documentation. Since Cisco completed its acquisition of Splunk on March 18, 2024, ask whether any support, telemetry or hosting arrangements have changed under the new ownership.
- Enterprise hosting: Confirm which data center or cloud account holds indexes, hot and cold buckets, and backups.
- Cloud region: Ask Splunk which region hosts your stack and whether it can be fixed in writing.
- Support access: Find out whether Splunk staff can reach your data during support cases and under what controls.
- Export path: Confirm the methods available to take data out, since Cloud deployments may restrict direct access to the underlying storage.
- Identity: Check whether Splunk authentication uses local accounts, LDAP or SAML, and who manages those identities.
Ask for the data flow diagram and the current data handling terms in writing before your auditor's first evidence request.
Self-hosted Wazuh keeps alerts, agent data and the indexer in infrastructure you choose, whether that is your own cloud accounts, a data center or an air-gapped network. The Wazuh indexer stores alerts and the Wazuh server analyzes agent data, so both components inherit the location you deploy them to. Wazuh documents an offline installation guide for systems without internet connectivity, and vulnerability detection can use an offline vulnerability repository in place of the Wazuh Cyber Threat Intelligence platform. The agent, server, indexer and dashboard can be placed in separate network zones, which lets you keep the data plane inside a restricted boundary.
- Offline installation: Follow the offline installation guide to build the stack without outbound internet access.
- Offline vulnerability data: Plan how the offline repository is updated, approved and transferred into the enclosed network.
- Network zones: Decide where the indexer and server sit relative to agents and the dashboard users.
- Backups and snapshots: Define where indexer snapshots are stored and who can restore them.
- Operator access: Limit administrative access to the servers that hold alert data.
Confirm your residency and key management requirements with your assessor and your own environment team before selecting a topology.
Wazuh supports single sign-on for the Wazuh dashboard, so you can tie analyst access to your existing identity provider rather than maintaining separate local accounts. Configuration is set in the dashboard and server settings and covers how users are mapped to roles. Identity decisions affect audit evidence directly: an assessor will want to see who could sign in, how access was granted and removed, and how that record matches your identity provider. Review the Wazuh single sign-on documentation for the supported protocols and the exact configuration steps for your version.
- Protocol choice: Confirm which single sign-on protocol the dashboard supports for your release before you design the integration.
- Role mapping: Map identity provider groups to Wazuh roles and document the mapping.
- Local fallback accounts: Decide whether an emergency local account exists, who holds it and how its use is logged.
- Deprovisioning: Test that removing a user in the identity provider blocks dashboard access.
- Agent enrollment: Keep agent registration credentials separate from analyst sign-in.
Before go-live, test the sign-in path, role mapping and removal of a test user, and keep the results with your access review records.
Wazuh Cloud is a managed offering from the Wazuh project and should be evaluated as a separate decision from self-hosting. Moving to it changes who operates the platform, where the data is stored and which contractual terms apply, so it is not the same residency position as running Wazuh in your own accounts. Read the service documentation for hosting location, data handling, support access and identity options before comparing it with self-hosted Wazuh. Ask the provider to confirm each point in writing.
- Hosting location: Confirm the region and whether it can be fixed for your data.
- Operator access: Find out who at the provider can access your environment and under which controls.
- Identity: Check whether single sign-on is available on your plan and how it is configured.
- Terms and evidence: Ask what reports, logs and attestations the provider can supply for your own assessment.
- Exit path: Confirm how alert data and configuration can be exported if you leave.
Treat Wazuh Cloud as its own vendor review, separate from the open-source license, and record the decision with your residency analysis.
Cost components on each side and what drives them
Splunk and Wazuh differ most in what you pay for: a commercial license and renewal on one side, and no license fee but real infrastructure, staff and support costs on the other. The cards below separate one-time work from recurring spend so you can build a like-for-like quote request.
Splunk licensing and renewal terms
Splunk is a commercial product, and its cost is set by the license agreement, the metering model and the renewal terms in your contract. The metering model (for example, how data volume or workload is counted) is the first thing to confirm with Splunk, because it determines how cost moves when your log volume grows. Ask for the renewal uplift, the true-up rules and which premium apps are included or billed separately.
Wazuh license and support terms
Wazuh is free and open source under GPLv2, so there is no license fee to pay for the platform itself. Any recurring vendor spend is optional: you may buy support, a managed service or a cloud offering, and those are priced separately. Ask any Wazuh partner or vendor to split their quote into software (zero), support subscription and services, so you can see exactly what you are paying for.
Indexer and server compute and storage
Compute and storage for the Wazuh indexer and server are the largest recurring infrastructure costs, and they scale with event volume and retention. The indexer stores alerts and is the component that needs the most disk and memory, while the server can run as a cluster when throughput grows. Your cloud or data center bill is recurring, so model it against your daily event volume and the number of nodes you need for redundancy.
Retention and archive policy
Retention is where storage costs quietly multiply, since regulators often require months of searchable data and older data may be archived. On Splunk, retention interacts with the metering model and with any archive option you use. On Wazuh, retention is set by your indexer policy and your own storage tier. Decide the searchable window and the archive window separately, then price each against its storage class.
Agent deployment and endpoint effort
Wazuh agents are installed on each endpoint, and you pay in packaging, rollout and change control rather than in agent licenses. Splunk forwarders have a similar deployment effort, so the difference lies in how agent configuration and upgrades are pushed. Count the one-time rollout across Linux, Windows and macOS hosts, plus the recurring effort to keep agents patched and enrolled as the fleet changes.
Staff time for rules, decoders and upgrades
Staff time is the cost most often underestimated on the open-source side. Someone must write and tune decoders and rules, translate existing Splunk correlation content, and apply platform patches. Wazuh's 4.14 line has shipped patch releases six times in 2026 (17 March, 23 April, 1 July, 29 July, 23 September and 14 October), so plan a recurring upgrade window. Ask a vendor to estimate this work in hours per month for your environment.
Implementation and outside support
Implementation is mostly one-time: architecture, installation, integration with identity and ticketing, and migration of detections. Outside support is recurring if you retain a partner for upgrades, tuning and incident help. Ask for a fixed-scope written statement with deliverables and acceptance criteria, and list which items are one-time and which are retainer-based, so you can compare a Splunk support contract with a Wazuh services agreement on equal terms.
What a move from Splunk to Wazuh involves at a high level
The sequence moves security monitoring in controlled stages, so each Splunk detection is either rebuilt in Wazuh, retired on purpose or accepted as a gap before any forwarder is switched off. Teams end with a tested Wazuh deployment and a documented record of what matched.
Inventory data sources and Enterprise Security content
Your security team lists every index, forwarder, saved search, correlation search, dashboard and alert action in Splunk, and marks which ones feed a compliance report or an incident playbook. Ask the Splunk administrator for the Enterprise Security content export and the list of apps in use, since premium app content often carries the detections that matter most. The step is done when each data source has an owner and each detection has a keep, rebuild or retire decision on record.
Deploy Wazuh in a test environment
Platform engineers install the Wazuh indexer, server and dashboard in a non-production network segment using the deployment method your standards allow, such as the all-in-one installation, Docker, Kubernetes or the offline guide for networks without internet access. Confirm the target version against the release notes before you install, because the 4.14 line receives frequent patch releases. The step is done when the dashboard loads, the cluster health is green and a test agent reports to the server.
Replace forwarders with Wazuh agents
Engineers deploy Wazuh agents to a pilot group of Linux, Windows and macOS hosts, and configure agent groups and file integrity monitoring centrally from the server. Universal forwarders stay in place on the same hosts until the pilot proves that log sources arrive as expected. Network devices that cannot run an agent are usually onboarded by syslog collection instead, so list them separately. The step is done when pilot hosts show current inventory and events in the dashboard and each source type is accounted for.
Rewrite correlation searches as decoders and rules
Detection engineers translate each kept SPL correlation search into Wazuh decoders, which extract fields from raw events, and rules, which fire alerts on conditions and can be chained by frequency or timing. Some searches, especially those using statistical functions across long windows or lookups against large external tables, will not map directly and need a redesign or a custom integration. Ask Wazuh specialists and your own analysts to review each mapping. The step is done when every kept detection has a Wazuh rule, a documented gap or a retirement record.
Export historical events through the CLI or REST API
Where investigations or compliance evidence need older Splunk data, the platform team exports the required time ranges through the Splunk CLI, which Splunk describes as its most stable retrieval method, or through the REST API for smaller pulls. Large exports take longer and need storage planned in advance, and the Wazuh indexer is not a drop-in target for raw Splunk buckets, so decide whether historical data is replayed, archived or kept read-only in Splunk. The step is done when the exported sets are checksummed, stored under your retention policy and spot-checked for completeness.
Run both platforms in parallel until detections match
Security operations runs Splunk and Wazuh side by side, feeding the same sources to both, and compares alert volumes, true positive rates and analyst findings for each detection over an agreed period. Mismatches are either fixed in Wazuh or documented as accepted differences with a named owner. Keep Splunk receiving data until the comparison is signed off, since switching early removes the fallback. The step is done when the security lead signs a parallel-run report listing each detection and its outcome.
Cut over and decommission Splunk
After sign-off, the team switches alerting and on-call routing to Wazuh, removes the remaining forwarders, stops Splunk ingestion and records the final state of the environment. Confirm your Splunk license or subscription end date with Splunk or Cisco before planning decommissioning, because contract terms set the date you can stop paying. The step is done when no active sources send to Splunk, the archive is verified and the cutover record is filed with your compliance evidence.
Questions buyers ask before switching from Splunk to Wazuh
What does switching from Splunk to Wazuh cost in effort, and who does the work?
The switch cost is mostly staff and services time, not a license fee, because Wazuh is free under GPLv2. Your team carries the work of deploying the Wazuh indexer, server, dashboard and agents, rewriting correlation searches as decoders and rules, and retiring forwarders. Costs you should expect to separate are one-time items (design, rule migration, testing, documentation) and recurring items (patching, rule tuning, infrastructure, and any paid support you choose). Ask any outside provider for a fixed-scope quote that lists each deliverable, the systems in scope and who performs each task.
How long does a parallel run between Splunk and Wazuh take?
The length of a parallel run depends on how many detections you must prove, how many log sources you onboard and how much change control your organization requires. Run both platforms until Wazuh raises the same alerts as Splunk for the same test events, and until analysts accept the new alert quality. Drivers that lengthen the run include regulated change windows, large numbers of custom correlation searches and log sources with unusual formats. Confirm the expected duration with your provider in the written scope rather than relying on a general estimate.
Can our team migrate to Wazuh without outside help?
Many teams with Linux and security operations experience can run a Wazuh deployment in-house, especially if they start from the documented all-in-one installation or a prebuilt OVA. The harder parts are the translation of Splunk correlation logic, indexer sizing and compliance evidence. Assess your team against those tasks honestly. If you use outside help, scope it in writing for specific deliverables, such as an architecture review, rule migration or hardening, and keep ownership of the running platform with your staff.
Can we keep our Splunk searches and dashboards after moving to Wazuh?
Not as they are. Splunk searches written in SPL do not run unchanged on Wazuh, which uses its own decoders, rules and dashboard views. Plan to inventory saved searches, alerts and dashboards, then classify each as rebuild as Wazuh rule, rebuild as dashboard view, or retire. Where you need the flexibility of SPL-style analysis that Wazuh does not match, confirm the gap with the vendor before committing to a scope.
How do we export historical Splunk data for the move?
Splunk supports several retrieval paths: Splunk Web saved searches, the CLI, the REST API, SDKs, the dump search command and data forwarding. Splunk describes the CLI as its most stable retrieval method, and the export options include raw events, CSV, JSON, XML and PDF. Choose the method by volume and by whether you need raw events or summarized results. Confirm the retention and archive rules of your own Splunk deployment, since they determine what history actually exists to export.
What skills does our staff need to run Wazuh?
Operators need Linux administration, familiarity with agent deployment and configuration management, and enough understanding of security monitoring to write and tune rules and decoders. Someone must also manage the indexer and dashboard, handle upgrades and watch disk growth. Wazuh supports remote agent configuration and upgrades, which reduces manual work on endpoints. Assess whether your team already covers these skills, and ask any provider which parts of knowledge transfer are included in the scope.
Does Wazuh alone replace Splunk Enterprise Security?
Wazuh covers log analysis, file integrity monitoring, vulnerability detection and compliance views, but it does not automatically replicate every feature of a commercial SIEM premium app. Splunk Enterprise Security content, such as its specific correlation searches, risk-based workflows and app-based investigations, must be mapped to Wazuh rules or to additional tools. Make an inventory of the detections, workflows and integrations you actually use, then confirm each gap with the vendor or in a proof of concept before you decide what Wazuh replaces.
How DeployOpen helps evaluate, implement or migrate
DeployOpen plans, implements, customizes, hardens, backs up, documents and supports self-hosted Wazuh inside your own infrastructure, whether that is your cloud accounts, your data centers or an air-gapped network. For a Splunk Enterprise Security replacement, that work usually starts with the architecture decisions that Wazuh leaves to you: how many Wazuh server nodes form the cluster, how the Wazuh indexer is sized and retained, which of the four components (indexer, server, dashboard and agents) run where, and how the dashboard is protected with single sign-on. DeployOpen also covers the hardening and backup of each component, the upgrade path across the 4.14 patch releases, and the operating documentation your own staff need after handover. Security testing of the deployed platform, its APIs and its agent enrollment path can be scoped separately, and DeployOpen prepares the controls and evidence that your compliance assessors will ask for. It does not issue audit reports, attestations or certifications. Independent auditors and certification bodies do that work. Most engagements are fixed-scope. Before any work starts, DeployOpen and your team agree the scope, the deliverables and the timelines in writing, and the quote follows from that written scope rather than from a published price list. To make that scope precise, ask for it to name the agent count and operating systems in use, the log sources that will be connected, the compliance views in the Wazuh dashboard that you need, whether vulnerability detection will use the Wazuh Cyber Threat Intelligence platform or an offline repository, and which detection content is being rebuilt from your Splunk correlation searches. Each of these items changes the effort, so check them before you compare quotes from different suppliers. After go-live, many teams keep a retainer for ongoing support, upgrades and continuous testing, because Wazuh ships patch releases every one to two months and each upgrade needs regression checks on your rules and decoders. Ask any provider, including DeployOpen, to state in the retainer which upgrades, rule changes and incident support are included, how requests are prioritized, and who on your side approves changes. Confirm those terms in writing before you sign, so that the operational responsibility for Wazuh is clear from day one.

