Splunk or OpenSearch: which fits your renewal and team
When a Splunk renewal, a pricing change or a data residency requirement forces a decision, the answer depends on how your team works. Splunk fits teams that rely on SPL, its app ecosystem and vendor-backed support. Self-hosted OpenSearch fits teams that want Apache 2.0 software running in their own cluster and have the staff to own indexing, sizing and upgrades. Neither choice is correct for every organization, so start by writing down four things: which detection content you must keep, which query skills your analysts already have, how much data you ingest each day and how long you must retain it, and how many engineers can run a search cluster well.
Detection content is the first test. OpenSearch Security Analytics starts from prepackaged Sigma rules, applies them to a chosen log type through a detector, and adds a correlation engine that links findings into threat scenarios. Count the correlation searches and dashboards your SOC uses today, then check which ones have a Sigma equivalent and which need rewriting. Query skills are the second test. Analysts fluent in SPL will need time with OpenSearch PPL, which is a pipe-based language run from Query Workbench or the _ppl API. Confirm with your own analysts how long that takes and whether your Splunk apps have OpenSearch equivalents at all.
Operating capacity is the third test, and it drives the cost of ownership more than the license does. Splunk bills you for ingest or workload, while OpenSearch removes the license fee but leaves you paying for compute, storage, retention, engineering time and any outside support. Ask your team to name the person who will handle rolling upgrades, shard and index lifecycle policies, and security patches, since OpenSearch versions receive fixes but no new features during maintenance. If that ownership is not staffed, a fixed-scope implementation partner can build and hand over the cluster, but the operating plan still belongs to you.
Which option fits which scenario
This table matches common Splunk situations to the option that usually fits better, with the reason in plain terms. Read each row as a starting point, then test it against your own detections, data volumes and staffing before committing.
| Scenario | Better fit | Why |
|---|---|---|
| Heavy SPL and Splunk app dependence | Stay on Splunk for now | SPL, Splunk apps and saved searches would need rewriting as PPL or Dashboards queries, and that translation work is substantial. Confirm which apps and searches your team depends on. |
| Licensing or renewal change | OpenSearch, if detections can move | Removing the license line shifts cost to compute, storage and staff time. Model those components before deciding, since the savings depend on your volume and retention. |
| Data residency or air-gapped requirement | OpenSearch | Apache 2.0 software runs entirely in your own accounts, data centers or isolated networks. Confirm that every plugin and update path works offline in your environment. |
| Team with Elasticsearch or Kibana experience | OpenSearch | OpenSearch keeps wire compatibility with Elasticsearch 7.10 REST APIs and derives its Dashboards from Kibana 7.10.2, so existing query and index habits carry over with adjustments. Check newer Elasticsearch features that OpenSearch does not share. |
| Team with no platform engineers | Managed or simpler stack, or outside support | A cluster needs sizing, index lifecycle policies, security configuration, patching and upgrades. Without that skill, plan for a retainer or a lighter option such as Wazuh with its own indexer. |
| Need for Sigma-based detections and correlation | OpenSearch Security Analytics, with custom rule work | Prepackaged Sigma rules are a starting point, not full coverage. Expect to tune detectors and build correlation rules for your own log sources. |
| Team needing a finished SIEM workflow out of the box | Wazuh or a commercial SIEM | Wazuh bundles agents, decoders, rules and compliance views. OpenSearch gives you the search and analytics layer you assemble yourself. |
Where your log data lives and who controls it
Splunk Enterprise on premises, Splunk Cloud Platform and a self-hosted OpenSearch cluster place your log data in very different hands. The cards below cover where the data sits, who operates the platform, how access and encryption are handled, and what compliance evidence your team must assemble.
Hosting model and data location
With OpenSearch you choose the location: your cloud account, your data center or an air-gapped network with no outbound connection. Splunk Enterprise runs on hardware you manage, while Splunk Cloud Platform runs in Splunk-operated environments. Confirm which regions, subprocessors and support access paths apply to your contract before you decide where indexed events, snapshots and backups are stored.
Who operates the cluster
A self-hosted OpenSearch cluster makes your team responsible for node patching, storage, backups and capacity. Splunk Cloud Platform moves much of that operation to the vendor, so the question is which controls you keep in-house. Ask each option for a written responsibility split covering the operating system, the search tier, index data and vendor access to your tenant.
Identity and access controls
The OpenSearch Security plugin supports SAML, OpenID Connect, Active Directory, LDAP, Kerberos and JSON Web Token authentication. It also offers role-based access control, document-level and field-level security, and field masking. Map your existing identity provider groups to these roles before migration, and compare that mapping with how Splunk roles and authentication are configured today.
TLS and audit logging
OpenSearch Security provides TLS for node and client traffic and audit logs for the cluster. Decide which audit categories you need, where those logs are forwarded, and who can read them, since audit records for a security platform are themselves sensitive. Verify the TLS certificate chain, rotation process and cipher settings against your own policy, and confirm how Splunk audit trails will be preserved during the transition.
Compliance evidence you prepare
DeployOpen prepares systems, configurations, access reviews and evidence for compliance assessments. It does not issue audit reports, attestations or certifications, and independent auditors or certification bodies make those decisions. Whichever platform you choose, your team must collect retention settings, access logs, change records and vendor assurance documents for the assessor.
Foundation governance and project oversight
The OpenSearch Software Foundation is a Linux Foundation project whose board includes AWS, IBM, SAP and Uber. The Foundation is not involved in the technical oversight of OpenSearch, which is handled by the project itself. Include this in your vendor risk review, and confirm the upgrade and security patch commitments you rely on through the OpenSearch release policy rather than assuming them from the Foundation's membership.
How the OpenSearch security stack fits together
The data path runs in one direction: log sources send events to an ingestion layer, the events land in OpenSearch indices, and Security Analytics detectors read those indices against rule sets. Each detector is bound to a log type, so the first design decision is which sources feed which indices and how those indices are named and mapped. A detector applies its rules to the logs of its chosen type, and every match creates a finding. Findings are the unit analysts triage, so the index layout chosen at ingestion determines what a detector can see later. Correlation rules then link findings from different log types into threat scenarios shown in a correlation graph, which only works if the fields used to join those findings are normalized consistently across sources. Alerts go out to channels such as email or Slack when a detector matches. Before go-live, confirm which of the prepackaged Sigma rules are enabled for each log type and test that a known event produces a finding end to end.
OpenSearch Dashboards is the analyst interface for this path, and it derives from Kibana 7.10.2. Because OpenSearch keeps wire compatibility with the Elasticsearch 7.10 REST APIs, many Elasticsearch 7.10 clients, shippers and scripts can point at the cluster with configuration changes only. That compatibility does not extend to every product that claims Elasticsearch support, and newer Elastic clients or agents may refuse to connect or may rely on features that are absent here. List every client, shipper and integration that writes to or reads from the cluster, then test each one against the exact OpenSearch version you plan to run. Access control belongs in the same design review. The Security plugin provides role-based access control, document-level and field-level security, field masking and audit logs, and it can connect analysts to SAML, OpenID Connect or Active Directory identity sources. Map analyst roles to these controls early, because retrofitting them after dashboards and detectors exist is slower and more error prone.
What you pay for: license versus cluster and people
Splunk's cost is a vendor quote tied to ingest or workload, while OpenSearch carries no license fee but moves the cost into infrastructure and staff time. The cards below separate one-time work from recurring spend so you can build a like-for-like quote before a renewal.
Splunk license terms
Splunk prices are set by the vendor and depend on how your contract measures use, such as daily ingest or workload. Ask Cisco or your reseller to state the metric, the term, the overage rules and what happens to rates at renewal. Confirm whether search, premium apps and Splunk Cloud storage are priced separately, because those lines often decide the total.
OpenSearch software cost
OpenSearch is licensed under Apache 2.0 and the OpenSearch FAQ does not describe any paid edition, so the software line is zero. The recurring costs come from the infrastructure and people around it. Confirm with your own legal and procurement teams that the Apache 2.0 terms fit how you plan to bundle OpenSearch with your own components.
Compute for indexing and search
Indexing and query load drive the number of data and coordinating nodes you run, and that count is recurring. Cloud instances or on-premises hardware are billed monthly or refreshed on a cycle. Ask your team to size the cluster for peak ingest, query concurrency and replica count, and to show how each node type scales with growth in daily volume.
Storage, retention and tiers
Retention length and replica count multiply the storage you pay for, and this is the cost most often underestimated. Hot nodes serve recent searches and need fast disks, while cold or snapshot storage holds older events at lower cost. Use index lifecycle policies to move data between tiers, and ask for the retention periods your compliance owners require before sizing storage.
Backup and disaster recovery
Snapshots to object storage or a second site are a recurring cost driven by data volume and snapshot frequency. Splunk Cloud customers may already have archive options, while a self-hosted cluster needs its own snapshot repository, restore tests and retention for backups. Ask for the recovery point and recovery time objectives you need, then price the storage and test effort that meets them.
Staff time for detections and upgrades
Detection content, tuning, dashboards and upgrades are ongoing work that depends on who owns them internally. OpenSearch publishes a new minor version about every eight weeks and maintains each version until the next major version or one year, whichever is longer, so plan recurring upgrade windows. Estimate hours per month for rule tuning, on-call rotation and upgrades, and compare that with the Splunk administration work you stop carrying.
Outside support and implementation
Commercial support for OpenSearch comes from vendors and service firms, and it is optional but usually billed by the year. Initial design, Security Analytics content and migration are one-time project costs under a written scope. Ask any implementation partner for a fixed scope, named deliverables, handover documentation and a clear split between project work and the retainer for ongoing support.
What a move from Splunk to OpenSearch involves
The sequence turns Splunk searches, dashboards and history into a self-hosted OpenSearch cluster that has been checked against live data before Splunk is switched off. Exporting SIEM content and historical events is the largest share of the work, so the sequence starts with inventory.
Inventory sources, searches and dashboards
List every data source sending events to Splunk, every saved search, scheduled alert, correlation search, dashboard and lookup, and the users and roles that depend on them. Record which items feed a SOC workflow, a compliance report or an audit obligation, because those carry the strictest acceptance checks. The team that owns each source and each detection should sign off on the list. The step is done when every item has an owner, a priority and a target in the new platform, or a documented decision to retire it.
Size the cluster and set index lifecycle policies
Measure current daily ingest and retention per index in Splunk, then size OpenSearch data, master and dashboard nodes for that volume plus growth, replica count and the hot, warm and delete phases you need. Confirm the topology and deployment method (Docker, Helm, the OpenSearch Kubernetes Operator, tarball, RPM, Debian packages or the Ansible playbook) with your platform team, and document the sizing assumptions. The step is done when a test cluster ingests a representative sample, the lifecycle policies are applied and the storage and retention figures are approved in writing.
Configure security, access and TLS
Set up the OpenSearch Security plugin with TLS for node and client traffic, connect your identity provider through SAML, OpenID Connect, LDAP or Active Directory, and map Splunk roles to OpenSearch roles with index, document and field-level permissions. Decide which users need field masking or audit logs for regulated data. Ask your security and compliance leads to review the access model before any production data arrives. The step is done when test users can reach only their permitted indexes and the audit logging output has been reviewed.
Re-point ingestion in parallel with Splunk
Add a second output to existing forwarders, syslog relays or collectors so events flow to both Splunk and OpenSearch, and confirm parsing, timestamps and field names on the OpenSearch side. Splunk keeps receiving data during this stage, so no detection coverage is lost. The owner is the team that runs the log pipeline. The step is done when each source shows matching event counts and correct timestamps in both platforms over an agreed observation window.
Translate SPL to PPL, Security Analytics and dashboards
Rewrite each saved search in PPL, which chains commands with the pipe character in the form search source=<index-name> | <command>, and run it in Query Workbench to confirm results. Map detections that behave like rules to Security Analytics detectors, which start from the open Sigma rules and emit findings and alerts, and re-create correlation logic with correlation rules. Rebuild dashboards in OpenSearch Dashboards. Where a Splunk search uses a feature with no direct equivalent, record the gap and the compensating control. The step is done when each item in the inventory is marked as translated, replaced or retired, with the output compared against the Splunk result.
Export historical data and content
Retrieve retained events from Splunk using the CLI, which Splunk describes as its most stable retrieval method, the REST API, SDKs, the dump search command, or saved search exports in Splunk Web, and load them into OpenSearch indexes with matching mappings. Export saved searches, alerts and dashboard definitions as text so they can be reviewed and re-imported. This is usually the largest effort driver because volume, field mapping and export time all scale with history. Confirm with Splunk administrators which export formats and limits apply to your version and deployment. The step is done when record counts and sample checksums match between the export and the imported indexes.
Run both platforms until detections match
Keep Splunk and OpenSearch running together, compare alert volumes, true and false positive outcomes and dashboard figures for each detection over a defined period, and tune Sigma rules, thresholds and correlation logic until the results agree or the differences are explained. Analysts should work the alerts from both sides during this stage. The step is done when every production detection has a documented match or an approved difference, and the on-call runbooks point to OpenSearch.
Cut over, back up and plan upgrades
Switch alert routing, forwarders and dashboards to OpenSearch, freeze Splunk for read-only reference, and take snapshots of the OpenSearch cluster according to your backup design. Confirm the upgrade process for the OpenSearch version you deploy, since OpenSearch targets a new minor version about every eight weeks and maintenance releases carry security patches, and schedule that work with your change board. Decide the Splunk decommission date with your renewal owner. The step is done when alerts flow from OpenSearch, a tested restore has been completed and the upgrade runbook is accepted.
Upgrade cadence and what you own after go-live
OpenSearch releases are on a planned rhythm, and the team that runs the cluster owns every step of it. The OpenSearch releases page says the project targets a new minor version about every eight weeks, with 3.8.0 released on August 4, 2026 and 3.9.0 on September 29, 2026. Each version stays under maintenance until the next major version enters maintenance or one year passes, whichever is longer. Maintenance releases carry bug fixes and security patches but no new features. Your plan should set a fixed review point for each minor release, decide which version your cluster targets, and set how quickly security patches are applied to production. Confirm the current support windows on the releases page before you commit to a version, because they change with each release.
Upgrades are rolling, which keeps the cluster available during the work but still requires a test cycle. The OpenSearch FAQ states that the project can use indices from Elasticsearch 6.0 through 7.10 and supports rolling upgrades from those versions, so a legacy Elasticsearch or early OpenSearch estate can move forward without a full rebuild. Plan each upgrade as a change with a staging cluster, a snapshot taken before the change, and a regression check of the detectors, correlation rules, PPL queries and Dashboards views you depend on. Ask your implementation partner to document the rollback path for each node type, including the security plugin configuration and the Security Analytics content that must survive the upgrade. The migration guide in the OpenSearch documentation covers the upgrade paths and is the next read for planning.
Splunk Enterprise has its own minor-version support windows, which affect the decision only when the two platforms run side by side during a transition. Those windows are covered on the Splunk Enterprise end of support page, so this section does not restate them. What you own after go-live on the OpenSearch side is the cluster itself: operating system and Java patching, node capacity, shard and index lifecycle policies, certificate rotation for TLS, Security plugin role and authentication backend maintenance, and Sigma rule updates for Security Analytics. Each of these is recurring staff work. Before signing, ask the partner to show who performs each task, how often, and what evidence of each change is kept, and to state whether support and upgrades are covered by a fixed-scope project or a retainer.
Questions buyers ask before choosing OpenSearch over Splunk
What does it cost to move from Splunk to OpenSearch?
The software cost is zero, because OpenSearch is licensed under Apache 2.0 and the OpenSearch FAQ does not describe any paid edition. The real cost sits in components: compute and storage for the cluster, the retention period you choose, staff time to write detections and tune indexes, and any outside support you buy. Splunk's cost follows ingest or workload licensing, so the comparison depends on your daily volume, retention and how many searches run. Ask for a quote that splits one-time work (design, migration, dashboard and detection rebuild) from recurring work (hosting, patching, upgrades and on-call).
How long does a Splunk to OpenSearch migration take?
The timeline depends on how much SPL, how many dashboards and how many correlation searches you need to rebuild, how many data sources must be re-pointed, and how long you run both platforms in parallel. Retention requirements and the amount of historical data to export also shape the schedule. DeployOpen agrees timelines in writing as part of a fixed-scope engagement, after the inventory of sources, searches and dashboards is complete. Ask any provider for a timeline tied to that inventory rather than to a generic duration.
What does the internal team need to do during the switch?
Your team needs people who know your log sources, your detection logic and your retention obligations. They decide which Splunk searches stay, how indexes map to OpenSearch indices, and who approves cutover. Engineers also need working knowledge of cluster sizing, index lifecycle policies, TLS and role-based access. Plan for analysts to validate detections against known events, because a translated search that runs without errors is not the same as one that catches the same activity. Confirm these commitments before signing a scope.
Can our team migrate to OpenSearch without outside help?
Yes, a capable platform team can run a migration without an implementation partner, provided it has time, a test environment and a clear inventory of Splunk content. The work that most often stalls internal projects is sizing the cluster, building secure ingestion, rewriting detections, and keeping upgrades current. OpenSearch documents installation through Docker, Helm, the Kubernetes Operator, tarball, RPM, Debian packages and an Ansible playbook, so the deployment method is a choice you make. Many teams use outside help for the design and cutover while keeping daily operations in house.
Does OpenSearch Security Analytics match Splunk Enterprise Security content?
Not one to one. Security Analytics uses prepackaged, open source Sigma rules as a starting point, and a detector applies those rules to a chosen log type. Its correlation engine links findings across log types into threat scenarios, and alerts can notify channels such as email or Slack. Splunk Enterprise Security has its own content library, risk-based alerting and app ecosystem, and some of that has no direct equivalent. Compare the detections you actually rely on, test each one against your data, and record every gap before you decide.
How do we get an accurate quote from DeployOpen?
DeployOpen does not publish a price list. A quote follows from a written scope, which DeployOpen agrees with the client before work starts. The scope lists the platforms, log sources, detections, dashboards, retention targets, environments and deliverables, and sets the timelines. Most engagements are fixed-scope, and ongoing support, upgrades and continuous testing are available as retainers. Send your Splunk license terms, daily volume estimate, source inventory and compliance obligations so the scope reflects your environment.
How much ongoing work does a self-hosted OpenSearch cluster create?
Ongoing work covers cluster health, capacity planning, index lifecycle management, backups, certificate rotation and upgrades. OpenSearch releases a new minor version about every eight weeks, and each version stays under maintenance until the next major version enters maintenance or one year passes, whichever is longer. During maintenance, versions receive bug fixes and security patches but no new features. Budget staff time for regular upgrades, and confirm with DeployOpen whether an upgrade retainer fits your schedule.
How DeployOpen helps you evaluate, implement or migrate
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For Splunk versus OpenSearch, that means agreeing in writing which log sources, searches, detections and dashboards are in scope before any cluster is built, then working through the indexing, security and upgrade decisions with your team.
How we scope
- Inventory the log sources, daily volumes and retention periods that the OpenSearch cluster must carry.
- Map which SPL searches, dashboards and Security Analytics detections need a PPL, Dashboards or Sigma-based equivalent.
- Agree the written scope, deliverables and timeline in advance, since most engagements are fixed-scope.
How we build
- Size and deploy the OpenSearch cluster in your environment, with index lifecycle policies set for your retention needs.
- Configure the Security plugin for SAML, OpenID Connect or LDAP sign-in, role-based access and audit logs.
- Build Security Analytics detectors and correlation rules, then test them against sample events before they go live.
How we hand over
- Document cluster topology, index layout, detector inventory and each rule's origin and tuning notes.
- Run Splunk and the new stack in parallel so your analysts can confirm detection results before cutover.
- Hand over runbooks for upgrades, backups and the OpenSearch release cadence, with your team trained to operate them.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover.
- Plan each OpenSearch minor upgrade against the release schedule, testing detectors and dashboards before rollout.
- Prepare control evidence for your compliance assessments; independent auditors remain responsible for the audit opinion.
