Which open-source Splunk alternative fits your renewal situation
If your Splunk renewal is coming up and you want to stay on self-hosted infrastructure, Wazuh fits teams that need SIEM and XDR with compliance content, Graylog fits teams whose core need is log management and search, and OpenSearch fits teams that want a general search and analytics engine they can build on themselves. Wazuh bundles its own indexer, server, dashboard and lightweight agents, so it is the closest match when detection, file integrity monitoring and compliance reporting are the main requirements. Graylog is better suited when the work is centered on collecting, searching and alerting on logs. OpenSearch gives you the most control, but you will assemble the detection and dashboard layer yourself or on top of a product that uses it.
Teams start this search for a few recurring reasons. Cisco completed its acquisition of Splunk on March 18, 2024, and a change of ownership is a common trigger for a licensing review, especially when a renewal date falls within the next budget cycle. Other teams are reacting to data residency requirements or to a wish to avoid lock-in to a single vendor's query language and content. Before you open a renewal conversation, confirm with your Splunk account team which products, ingestion or workload terms, and support tiers your current contract covers, and export a list of the data sources, saved searches and alerts that depend on them. That inventory decides which alternative is realistic for you.
Open-source pricing is different from open-source cost. Graylog Open is free to self-manage under the Server Side Public License with no ingestion caps, so its software line item is zero, but you still pay for the servers, storage, backups, staff time and any support contract you choose to buy. Wazuh is free and licensed under GPLv2, and OpenSearch is licensed under Apache 2.0, so the same cost components apply. Ask any implementation partner for a quote that separates one-time work (migration, content translation, hardening) from recurring work (upgrades, patching, on-call, storage growth) and states the assumptions behind the daily data volume and retention period.
Wazuh, Graylog or OpenSearch: which option matches your Splunk use
Splunk teams usually replace one of three things: security monitoring, general log search, or a search engine they build dashboards on. Wazuh, Graylog and OpenSearch each start from a different one of those needs, so the right choice depends on which Splunk workload you are moving and how much detection content you must rebuild.
Wazuh for endpoint-driven SIEM
Wazuh is a free, open-source XDR and SIEM platform licensed under GPLv2 and derived from OSSEC. It combines the Wazuh indexer, server, dashboard and lightweight agents, with log analysis, file integrity monitoring and vulnerability detection. It fits teams whose Splunk use centers on host telemetry and compliance reporting for PCI DSS and GDPR. Check agent coverage across your fleet, because most of its detections depend on agents, and confirm that your SPL correlations map to its rule format before cutover.
Graylog Open for log search
Graylog Open is free to self-manage under the Server Side Public License, with no ingestion caps. It fits teams whose Splunk use is mainly centralized log search, dashboards and alerting across application and infrastructure logs. Graylog Enterprise adds data lake and storage options with support, and Graylog Security adds SIEM, threat detection and anomaly detection, so ask which tier covers the features you use. Confirm the license terms with your legal team, since the Server Side Public License is not the same as the Apache or GPL licenses used by the other options.
OpenSearch as a search engine
OpenSearch is licensed under Apache 2.0 and was forked from Elasticsearch 7.10.2 and Kibana 7.10.2. It keeps wire compatibility with Elasticsearch 7.10 REST APIs, so existing clients and queries written for that version often carry over. It fits teams that want to build their own detections, dashboards and pipelines on a general-purpose engine. The trade-off is that you assemble the SIEM yourself, so plan for detection content, alerting and case workflow as separate build work.
Security Onion for network monitoring
Security Onion is a free Linux distribution for threat hunting, security monitoring and log management. It bundles Suricata, Zeek and the Elastic Stack. Its repository is licensed under the Elastic License 2.0, which differs from the Apache and GPL licenses of the other options, so review those terms before embedding it in a product. It fits teams that need network-level evidence alongside log data. Security Onion Pro is a paid tier, so compare its feature set against your Splunk apps before committing.
How Splunk capabilities map to open-source options
This table maps the main Splunk capabilities to the open-source platforms that can cover them: Wazuh, Graylog, OpenSearch and Security Onion. Read each row as a coverage note, not a feature checklist, since most rows need a pilot to confirm how close the match is to your current content.
| Capability | Open-source options | Coverage notes |
|---|---|---|
| Log ingestion and forwarding | Wazuh agents and server, Graylog inputs, OpenSearch Data Prepper or Logstash style pipelines | Forwarders and inputs must be re-pointed on every host. Confirm parsing parity for each source type before retiring Splunk forwarders. |
| SPL search | Graylog query language, OpenSearch query DSL and PPL, Wazuh indexer queries | No direct SPL equivalent in any listed option. Commands such as stats, eval and transaction must be rewritten, and some pipelines need redesign. |
| Saved searches and dashboards | Graylog dashboards, OpenSearch Dashboards, Wazuh dashboard | Dashboards must be rebuilt by hand. Splunk dashboard XML and app-packaged views do not import directly, so budget review time for each panel. |
| Alerting | Graylog alert conditions and notifications, OpenSearch alerting plugin, Wazuh active responses | Alert thresholds, throttling and recipients need to be recreated and tested. Confirm notification channels match your ticketing tools. |
| Correlation rules and detections | Wazuh rules and decoders, Graylog Security (paid tier) detections, OpenSearch Security Analytics, Sigma rules | Splunk Enterprise Security correlation searches and risk-based alerting have no drop-in equivalent. Expect to rebuild and validate detections in a pilot. |
| Threat intelligence | Wazuh CDB lists and integrations, Graylog lookup tables, OpenSearch threat intel feeds | Feed licensing and enrichment logic must be confirmed per source. Splunk threat intelligence framework content is not portable as is. |
| User and entity analytics | Graylog Security anomaly detection, OpenSearch anomaly detection, Security Onion Pro features | Behavioral analytics depth varies widely. Confirm which models you need and whether they are in the free tier or a paid tier. |
| Compliance reporting | Wazuh PCI DSS and GDPR modules, Graylog reporting, OpenSearch dashboards | Wazuh bundles compliance mappings, but reports must be checked against your own control evidence. Auditors make the final assessment. |
| RBAC and multi-tenancy | Graylog roles and streams, OpenSearch security plugin roles and tenants, Wazuh user roles | Confirm role granularity against your current Splunk roles and index permissions. Multi-tenant isolation often needs separate clusters. |
| Apps and add-ons | Wazuh rulesets, Graylog content packs, Security Onion components, community OpenSearch plugins | Splunkbase apps have no one-to-one replacement. Each app must be inventoried, replaced, or retired, and its content tested. |
| Data retention tiers | Graylog archive and data lake options, OpenSearch index lifecycle policies, Wazuh indexer retention | Hot, warm and cold tiering must be designed around your storage. Storage sizing needs your own ingest volume and retention figures. |
How to translate SPL searches and dashboards without losing detections
SPL does not port one to one, so the translation work has to be planned as a detection migration, not a copy-paste exercise. OpenSearch expects queries in its query DSL or in PPL-style syntax, Graylog uses its own search language with stream and field routing, and Wazuh detections are written as XML rules that match decoded log fields. A pipeline such as stats, eval, transaction or a subsearch will usually need a different construct on each target, and some SPL commands have no direct equivalent at all. Before you start, confirm with each platform's current documentation which operators, aggregations and time functions it supports, because the gap list determines how much rework each search needs.
Start with an inventory of every saved search, alert, scheduled report and dashboard panel in Splunk, and export the definitions rather than working from memory. For each item, record its schedule, its owner, the index and sourcetype it reads, the action it triggers and the last time it fired. Then rank the list by two factors: how often it runs and whether it feeds a compliance control or an incident response runbook. Detections that fire every few minutes and map to a control your auditors will ask about go first, while dashboards that nobody has opened in a year can be retired after a sign-off. Ask the business owner of each compliance-linked report to confirm the required output format and retention, since those requirements are often the hardest to reproduce.
Confirm each translated query against the same historical events in a pilot before you retire the Splunk original. Replay a fixed window of raw logs into the new platform, run the old and new searches over that window, and compare hit counts, field values and alert timing, investigating every difference. Keep the Splunk search running in parallel for a defined period, and treat a mismatch as a blocker until the cause is understood, whether it is a time zone, a field extraction or a missing lookup. Document each accepted difference and the person who approved it, because that record is the evidence an assessor will request when asking how detections were preserved. Your Splunk export options, covered in the next section, are what make this replay practical.
How to export historical Splunk data through the CLI or REST API
This sequence moves historical Splunk events into a self-hosted target such as OpenSearch, Graylog or Wazuh with counts and checksums that prove nothing was lost. It also gives the compliance owner a documented record before any source data is removed.
Confirm retention and chain-of-custody requirements
Before any export, the compliance owner confirms in writing how long each index must be kept, which logs are subject to legal hold, and what evidence the auditor or regulator expects to see for moved data. The retention window is set by policy and by the regulations that apply to your organization, not by Splunk, so confirm it with the compliance owner rather than inferring it from the current Splunk configuration. The step is done when the owner signs off on a retention matrix listing each index, its retention period and its custody requirements.
Inventory indexes and choose formats per data type
The Splunk administrator lists each index, sourcetype and saved search that must be preserved, along with its approximate volume and the fields analysts rely on. Raw events suit forensic evidence because they keep the original bytes, while JSON or CSV suit structured analysis and loading into OpenSearch or Graylog. Splunk exports search results as raw events, CSV, JSON, XML or PDF, and PDF is useful for reports but not for reloading data. The step closes with a table that maps each data type to one format and one retrieval method.
Scope export time ranges and retrieval method
Split each index into bounded time ranges so that every export job is small enough to rerun if it fails. Splunk recommends its CLI as the most stable retrieval method, so use the CLI for bulk jobs and the REST API for scripted or incremental pulls, and record the exact search string, earliest and latest times and output format for each job. The administrator runs a dry search first to confirm the range returns events. The step is complete when every range has a logged job definition that another engineer could rerun.
Run exports and capture job metadata
An engineer runs the scoped export jobs from a controlled host with a service account that has the minimum search capability needed. Each job writes its output file, the job identifier, the start and end times and the hash of the output file to a manifest kept with the evidence. Failed or partial jobs are rerun for the same range rather than merged by hand, so that the manifest stays a faithful record. The step closes when every planned range has an output file and a matching manifest entry.
Verify row counts and checksums
Compare the event count in each output file against the count Splunk reports for the same search and time range, and recompute the checksum of each file to confirm it matches the manifest. Any mismatch in counts or hashes sends that range back for re-export before loading. Spot-check a sample of events for field values, timestamps and time zone handling, since these are the most common losses in format conversion. The step is done when every file passes both the count and the checksum comparison, and the results are stored with the manifest.
Load data into the target and reconcile
Load the verified files into the self-hosted target, such as an OpenSearch index, a Graylog archive or a Wazuh indexer, using the ingestion method the platform documents for that format. After loading, run the same count and time-range queries against the target and compare them with the source counts from the manifest. Keep original timestamps and source fields so that historical searches return the same events. The step is complete when reconciliation shows matching counts for every range, with any differences explained and documented.
Retain source data and record the handover
Keep the Splunk source data and the manifest in place until the compliance owner has accepted the reconciliation report and the retention matrix has been applied. Only then, under the approved retention plan, does anyone remove or archive the Splunk copy, and each action is logged. The handover document lists the target locations, hashes, reconciliation results and the owner's approval. The step closes when the owner signs the handover and the deletion or archive record is filed with the evidence.
What self-hosted Splunk replacement costs by component
This table breaks the cost of leaving Splunk into components, showing who is paid, whether each item is one-time or recurring, and what drives it up. Use it to structure a written quote and to compare your current Splunk subscription against self-hosted infrastructure, licensing, migration and staffing. No figures are given because prices depend on your ingestion volume, retention and availability design.
| Cost component | Who is paid or who carries it | One-time or recurring | Main cost drivers and what to request in a quote |
|---|---|---|---|
| Splunk subscription or license (current state) | Splunk or Cisco, under your existing contract | Recurring until the contract ends | Daily ingestion volume, term length, and any renewal uplift. Confirm the exit date and notice terms with your account team. |
| Open-source licensing (Wazuh, OpenSearch) | No license fee to the project, since both are free and open source | Not applicable | Wazuh is GPLv2 and OpenSearch is Apache 2.0. Confirm any add-on or support subscriptions you choose to buy separately. |
| Graylog licensing | Graylog Open is free to self-manage. Graylog Enterprise and Graylog Security are paid | Recurring if you buy paid tiers | Whether you need data lake storage, enterprise support or SIEM and anomaly detection features. Ask the vendor which tier covers each requirement in writing. |
| Compute and indexer storage | Your cloud provider or data center team, or the hardware vendor | Recurring (cloud) or mostly one-time (hardware) | Ingestion volume, retention period, and replica count. Ask for sizing based on your measured daily volume and retention. |
| High availability design | Your infrastructure team and the implementation partner | One-time build, recurring capacity | Number of nodes, cluster layout, and failover testing. Request the node count and the failover test plan as separate line items. |
| Network and backups | Your network provider and backup platform owner | Recurring | Data transfer, backup retention, and offsite copies. Confirm whether backups of indexed data are in scope. |
| Implementation and detections rebuild | Implementation partner or internal engineers | One-time | Number of SPL searches, dashboards and alerts to translate, and forwarder re-pointing. Ask for a fixed scope listing each item. |
| Historical data export | Internal staff or implementation partner | One-time | Volume of indexed history you must keep and how it is exported through the Splunk CLI or REST API. Request an export plan that names formats and target storage. |
| Dual running period | Your operations team, plus double infrastructure during overlap | One-time, but recurring during overlap | Length of the overlap and the detections you must run in both platforms. Ask the quote to state how long Splunk stays active and who signs off cutover. |
| Support and internal skills | Internal staff, vendor support, or retained partner | Recurring | Staffing for OpenSearch, Wazuh or Graylog administration, upgrades and on-call. Ask for the skills gap assessment and any retainer terms. |
How to size self-hosted storage for Splunk-scale log volumes
Storage sizing for a Splunk replacement starts with one number you already have: how much data Splunk indexes each day, measured at the indexer rather than estimated from source systems. Daily ingestion, retention period, replica count, compression and the split between hot and warm tiers together determine how much disk you need and how many data nodes you need to hold it. In OpenSearch, each index shard keeps replicas, so raising the replica count multiplies disk use. Graylog stores messages in Elasticsearch or OpenSearch indices under its own index sets, so the same arithmetic applies to its retention settings. Wazuh indexer sizing follows the same inputs, so the same measurements carry over to a Wazuh deployment.
Retention is often the largest lever, and it is set differently on each side. Splunk retention is governed by index settings and bucket lifecycle, while OpenSearch uses index lifecycle policies and Graylog uses index set rotation and retention. Keep hot data on faster storage for active searches and move older data to warm nodes or snapshots, which lowers the cost of nodes that serve rarely queried history. Compression ratios vary widely by log source, so measure them on your own sample rather than assuming a figure from a vendor brochure. Ask each vendor for its current sizing guidance for your exact version, and confirm how that guidance treats replicas, merge overhead and free disk headroom.
Run a sizing test before you commit to hardware or cloud instances. Load a representative slice of production traffic into a pilot cluster, run your heaviest saved searches and dashboards against it, and record disk growth, search latency and heap pressure at your target retention. Repeat the test at peak ingestion, not only at the daily average. Document the results as the basis for the node count in the quote, and ask the implementation partner to state which assumptions the quote depends on, such as ingestion growth, retention changes and whether cold data sits on object storage or local disk.
What you give up when leaving Splunk and the usual workarounds
Moving off Splunk changes more than the storage layer. The risks below cluster around query language, content, vendor relationships and people, and each has a workaround that is usually a planning task rather than a product purchase. Map each one before the cutover date is set.
Loss of SPL and its commands
Splunk Processing Language has commands such as stats, transaction, tstats and lookup that many detections depend on, and no open-source platform reproduces it one for one. Graylog uses its own query syntax and OpenSearch uses Lucene or PPL, so each search needs a rewrite and a test against known events. Inventory the saved searches and alerts by owner and by how often they fire, then rebuild the most critical ones first. Expect some SPL constructs to have no direct equivalent and plan to simplify them.
Splunk apps and add-ons
Many teams depend on Splunkbase apps and add-ons for parsing, dashboards and vendor data sources. Few of these have a drop-in equivalent on Wazuh, Graylog or OpenSearch, so the parser or dashboard usually has to be written again. Make a list of every installed app, the data sources it reads and the dashboards it feeds. Confirm with each vendor whether an open-source collector or integration exists before you assume one does.
Enterprise Security content and workflows
If Splunk Enterprise Security drives correlation searches, notable events, risk scoring or investigation queues, that workflow is a product layer, not only a set of searches. Wazuh and Graylog Security cover parts of detection and triage, but the case management and risk model will need to be designed and documented. Decide which analyst workflows must survive unchanged and which can be simplified. Test each replacement with replayed historical events.
Vendor support and certified integrations
Splunk's paid support tiers and certified integrations give some teams a single escalation path and vendor-verified connectors. Self-hosted platforms move that responsibility to your team or to a partner. Compare the support options for Wazuh, Graylog Enterprise and OpenSearch distributions, and ask who answers for each component. Confirm the response expectations in writing before you retire the Splunk contract.
Staff familiarity with SPL
Analysts who write SPL daily will lose speed when the query language changes, and that loss shows up in incident response times before it shows up in a report. Plan structured training on the new query language, dashboards and alert logic, and pair experienced analysts with the people who rebuild content. Run tabletop exercises on the new tooling during the parallel run so gaps appear before a real incident.
Retaining a narrow Splunk tier
A common workaround is keeping a small Splunk tier for historical searches, audit evidence or a few sources that have not been ported yet. This reduces migration risk but keeps licensing and operational cost running, so set a retirement date and a list of exit criteria. Ask your Splunk account team which tier fits a read-only or archive role, and confirm the terms in writing.
How the move from Splunk to open source runs in seven phases
The sequence turns an undocumented Splunk estate into a tested, self-hosted replacement in which each phase produces evidence that the next phase depends on. Detections keep running throughout, and nothing is decommissioned until retention obligations are confirmed as met.
Inventory sources, searches, alerts, dashboards and users
Export a complete list of data inputs, forwarders, saved searches, scheduled alerts, dashboards, apps, lookups and user roles from the Splunk administration views and configuration files. Record which sources feed which alerts and which teams rely on each dashboard, so that unused content can be retired instead of migrated. The phase is complete when the inventory is reviewed and signed off by the SOC lead and the owner of each log source, and every item is tagged as migrate, rebuild, retire or retain.
Export historical data for retention
Determine which data must be kept and for how long based on your retention obligations, then export it. Splunk supports several retrieval paths, including the CLI, which Splunk describes as its most stable retrieval method, the REST API and saved search exports in Splunk Web. Confirm the export formats and volumes with your Splunk administrator and the target platform owner before starting, and check that exported files preserve timestamps, source and sourcetype fields. The output is an archive with checksums and a restore test, signed off by compliance or records management.
Map queries and detections to the target platform
Translate each SPL search, alert and dashboard panel into the query language of the chosen platform, whether Wazuh, Graylog or OpenSearch. Expect manual rework for stats, lookups, macros and time-based logic, and treat automated conversion as a starting point that needs review. Each detection should carry a written intent statement, the data it depends on and the expected output, so that a reviewer can judge equivalence. The phase closes when the detection engineering lead has approved the mapping and gaps are logged with a decision on each.
Build and test the pilot on a subset of sources
Deploy the target platform in your own environment and onboard a small group of low-risk sources, such as one network segment or a set of servers with well-understood logs. Verify ingestion, parsing, field names, timestamps and dashboard rendering against the same events in Splunk. Test alert firing with controlled events and confirm that notifications reach the on-call channel. The pilot is complete when the platform owner and SOC lead agree on a list of defects, all of which are fixed or accepted in writing.
Run both platforms in parallel
Send the same events to Splunk and the new platform at the same time, and compare alert outcomes, search results and dashboard values over an agreed period. Keep a discrepancy log that records each difference, its cause and its resolution. Parallel running also shows the storage and compute load under real volumes, which informs the sizing of production capacity. The phase produces a parity report that the SOC lead and the CISO review before any source is moved.
Cut over by source group with a rollback plan
Move sources to the new platform in groups, starting with the least critical, and stop forwarding to Splunk only after each group passes its parity check. Document the rollback steps for each group, including how to restore forwarder configuration and re-enable Splunk detections, and rehearse at least one rollback. Confirm that detections covering the moved group are firing on the new platform before the next group starts. Each cutover closes with a signed change record from the data owner and the SOC lead.
Decommission Splunk after retention obligations are met
Once all sources are live, the compliance team has confirmed that exported and retained data meets its obligations, and the audit trail for the migration is complete, turn off Splunk ingestion and remove forwarders and licenses according to your contract terms. Confirm with your Splunk account team and your legal team how data held in Splunk is returned or deleted, and document the decision. The phase is complete when the compliance lead accepts the retention evidence and the platform owner records the final decommissioning in the asset register.
Which Splunk replacement fits your situation
A renewal notice or a change in licensing terms is the most common trigger. The question is usually whether the platform you run today can be reproduced at a lower total cost of ownership, and which open-source option carries the fewest surprises once running. Graylog Open is free to self-manage under the Server Side Public License with no ingestion caps, so the cost shifts to infrastructure, operations and any support or Enterprise features you choose to buy. Wazuh is free and open source under GPLv2 and suits teams whose main need is detection, file integrity monitoring and vulnerability visibility alongside log analysis.
- Graylog Open fit: Log search, dashboards and alerting for teams that mainly need centralized log analytics.
- Wazuh fit: Endpoint-centric detection, file integrity monitoring and compliance content from the same agent deployment.
- Cost model: Split costs into storage, compute, staff time for upgrades and tuning, and any paid support or Enterprise add-ons.
- Recurring versus one-time: Build and migration effort is one-time, while storage growth, infrastructure and operations recur.
- Quote request: Ask for a written scope that prices each component separately so you can compare it with the renewal.
The first question to answer: how much of your Splunk spend is ingestion, and how much is search, apps and support? Confirm the licensing terms of any Graylog tier you plan to use directly with the vendor.
When a regulator, contract or internal policy requires log data to stay in a specific region or inside a network with no internet path, the deciding factor is where the platform runs. Self-hosted OpenSearch, licensed under Apache 2.0, can run in your own cloud accounts, data centers or air-gapped networks, and Wazuh can be deployed the same way. Neither option sends events to a vendor-hosted service by default, so the residency decision becomes an architecture decision about storage placement, backups and access paths.
- OpenSearch fit: A search and storage backend you deploy in a named region or isolated enclave.
- Wazuh fit: Agents and a server that stay inside the same boundary, with the indexer holding detection data.
- Backup location: Snapshots and archives must also stay in the approved region or enclave.
- Update path: Air-gapped installs need a controlled way to bring in packages, signatures and rule updates.
- Access model: Analysts, administrators and any vendor support sessions need documented access inside the boundary.
The first question to answer: which data classes must stay in region, and which teams and tools will read them from outside it? Confirm with your legal and compliance owners before choosing a topology.
Some teams replace Splunk because they want to build their own analytics rather than configure a packaged product. OpenSearch, forked from Elasticsearch 7.10.2 and Kibana 7.10.2 and keeping wire compatibility with Elasticsearch 7.10 REST APIs, gives engineers a search and analytics engine they can script against. This route suits organizations with data engineers who can own indexes, pipelines and dashboards, but it asks more of the team than a turnkey SIEM does.
- Query translation: SPL searches must be rebuilt as OpenSearch queries or aggregations, and some Splunk commands will not map one to one.
- Pipeline ownership: Ingestion, parsing and index lifecycle become your responsibility.
- API use: Custom integrations rely on the REST API, so define versioning and access control early.
- Detection content: Sigma-style or custom rules may need a separate execution layer, which you must select and confirm.
- Version planning: Track the OpenSearch release you deploy and test upgrades before they reach production.
The first question to answer: which of your current Splunk searches and dashboards do analysts use every week, and who will own their rewrite? Confirm the compatibility of any Elasticsearch-based client library you plan to reuse.
Organizations under PCI DSS or GDPR obligations need more than a log store. They need log collection, monitoring, access records and evidence that the controls work. Wazuh is described as offering log analysis, file integrity monitoring, vulnerability detection and compliance support for PCI DSS and GDPR, which makes it a common starting point for teams that want compliance content close to the agents. Evidence preparation is still a separate job: DeployOpen prepares systems, controls and evidence for assessments, while independent auditors and certification bodies issue any reports or attestations.
- Compliance content: Map the PCI DSS and GDPR requirements you must meet to the Wazuh rules, dashboards and checks you enable.
- Integrity monitoring: Define which paths and configuration files are monitored and who reviews alerts.
- Retention and access: Document retention periods, role-based access and log protection set by your own policy.
- Evidence pack: Collect configuration baselines, alert handling records and change history for the assessor.
- Gap review: Compare the built-in content with your control matrix and record what needs custom work.
The first question to answer: which specific PCI DSS requirements and GDPR obligations does your assessor expect the logging platform to support? Confirm the scope with your assessor before building anything.
Questions buyers ask before replacing Splunk
How much does a migration from Splunk cost and what drives it?
The cost has two parts: what you pay to run the new platform and what you pay to move to it. Self-hosted Wazuh, Graylog Open and OpenSearch carry no license fee, so the recurring spend is infrastructure (compute, storage, network and backup), staff time and support if you buy it. The one-time spend is the migration itself: translating SPL searches and dashboards, exporting history, rebuilding detections and testing. The main drivers are daily ingestion volume, retention period, the number of data sources and parser or content rewrites, and how many detections you run. Ask for a quote that breaks out each component and states which items are one-time and which recur. Ask the provider to show the assumptions for ingestion and retention so you can change them.
How long does a Splunk to open-source migration take?
The timeline depends on scope more than on the platform choice. The biggest variables are how many saved searches, dashboards, alerts and data sources need to move, how much history must be kept accessible, how many compliance reports depend on current content, and how much parallel running your change process requires. Splunk's CLI and REST API can export search results, but the time to export large history sets depends on your data volume and storage throughput. Phase the work by data source so high-priority detections move first. Request a written schedule with milestones, acceptance criteria for each phase and the dependencies on your staff, and treat any duration given without a stated scope as an estimate to challenge.
Can our own team migrate from Splunk without outside help?
Yes, many teams do, provided they have engineers who know Linux, networking, the chosen platform and their own detection content. A self-managed migration usually needs skills in log pipeline design, index or storage sizing, query translation, access control and backup. The common gap is detection engineering: SPL logic does not carry over line by line, and the team must confirm each rule still fires on the same behavior. Outside help is most useful for fixed-scope work such as sizing, a pilot, translating a defined set of content, or hardening and documenting the result. DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades and documents self-hosted platforms in your environment, and most engagements are fixed-scope with the scope agreed in writing before work starts.
What does the migration need from our security and platform staff?
Expect staff time in four areas: inventory, design, validation and operations. Inventory means listing sources, forwarders, saved searches, alerts, dashboards and the owners of each. Design means choosing the platform components, storage layout, retention, authentication and network zones. Validation means replaying known events and comparing alert outcomes with Splunk. Operations means someone owns patching, capacity, backups and on-call response after cutover. Name the individuals and the hours you can release in the written scope, because a delayed review by a detection owner is the most common cause of schedule slip. Ask the provider which tasks they will do and which they expect your team to perform.
Can we keep a Splunk tier running during the transition?
Yes, a parallel run is the normal approach. Keep Splunk Enterprise or Splunk Cloud receiving the same sources while the new platform ingests them, then compare alerts and reports before retiring anything. Two points need confirmation with Splunk and your contract: the term and any renewal dates, and whether you need to keep ingesting into Splunk to retain access to historical data. Parallel running doubles some ingestion and storage costs for its duration, so limit it to the sources and detections that are still being verified. Cisco completed its acquisition of Splunk on March 18, 2024, so confirm current licensing terms and support contacts directly with Splunk or your reseller.
How do we verify that detections still match after cutover?
Verify each detection against a known test, not against a visual check of the new dashboard. Build a test set from historical events and from controlled simulations, run the same events through both platforms, and record which alerts fire, at what time and with which fields. Investigate every difference: a missing alert may mean a translation gap, a missing parser or a timing change. Keep a traceability list that maps each Splunk search to its replacement, its owner and its test result. Security testing can be scoped to exercise detections, and DeployOpen runs security testing for applications, infrastructure and AI systems. Ask for the acceptance criteria in writing before cutover, and confirm that compliance evidence for the replaced controls is kept.
Does exporting Splunk history need the CLI or the REST API?
Splunk documents several export paths: Splunk Web, the CLI, the REST API, SDKs, the dump search command and data forwarding. Splunk describes the CLI as its most stable retrieval method, which makes it a sound default for scripted bulk exports. Export format matters for the target platform: raw events preserve the most detail, while CSV or JSON keep fields for re-indexing. Test one time range end to end, confirm field names and timestamps, and check the volume against your storage plan before running the full export. Confirm the export method and format in your scope, since exports of very large histories can take longer than expected.
Official sources for Splunk export and open-source platform licensing
Before you plan an export or a platform choice, read the primary sources yourself. Splunk's documentation on exporting search results describes the formats Splunk supports (raw events, CSV, JSON, XML and PDF) and the retrieval paths available, including Splunk Web, the CLI, the REST API, SDKs, the dump search command and data forwarding. Splunk describes the CLI as its most stable retrieval method, which is the path most teams should test first when moving historical data. Read the page for the exact Splunk version your environment runs, because option names and limits can differ between Splunk Enterprise and Splunk Cloud Platform. Ask your Splunk administrator which deployment type you have before you copy any command into a runbook.
Next, confirm the license terms of each candidate platform against the source, not a summary. The Wazuh GitHub repository documents the GPLv2 license and the component layout of the indexer, server, dashboard and agents. The Graylog Open page explains that Graylog Open is self-managed under the Server Side Public License and separates it from the paid Enterprise and Security tiers, so have legal review what your use case requires. The OpenSearch FAQ states the Apache 2.0 license and the Elasticsearch 7.10.2 fork lineage, which matters when you assess client compatibility. The Security Onion GitHub repository is licensed under the Elastic License 2.0, which is not the same as Apache 2.0, so route it through your open-source policy review.
Record the results of this review in your migration decision log with the date, the version you checked and the named owner. Licensing pages change, and a decision based on a version you have not verified is hard to defend during audit or procurement review. If your legal team needs a written position on a specific license, request it from counsel or the project maintainers rather than relying on this page or on DeployOpen's reading of the terms.
How DeployOpen scopes, migrates and supports a Splunk replacement
DeployOpen plans, implements, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside your own infrastructure, including the Wazuh, Graylog and OpenSearch options covered on this page. Engagements start with a written, fixed scope so that search translation, data export, storage sizing and detection cutover are agreed before any work begins.
How we scope
- Inventory of Splunk apps, saved searches, alerts, dashboards and data sources in use
- Agreed list of detections and dashboards to rebuild, retire or leave out
- Written scope, deliverables and timelines confirmed before work starts
How we build
- Deploy the chosen platform in your cloud account, data center or air-gapped network
- Translate SPL searches into the target query language and test results against exported Splunk data
- Rebuild dashboards and run parallel detections until alert outcomes match
How we hand over
- Documentation of architecture, data flows, retention settings and access controls
- Runbooks for exporting historical data through the Splunk CLI or REST API and archiving it
- Knowledge transfer sessions with your security operations and platform teams
How we support
- Ongoing support, upgrades and continuous testing available as a retainer
- Backup and restore testing for the new platform, scheduled with your operations team
- Control and evidence preparation for compliance assessments, with auditors issuing any reports
