Splunk Enterprise end of support: what the date forces and the short answer
Many security and platform teams face the same budget problem this year: the Splunk renewal and the next Splunk Enterprise upgrade land in one planning cycle. The date that shapes the decision is December 16, 2026, when support for Splunk Enterprise 9.4 ends. Each Splunk Enterprise minor version is supported for 24 months, so a team still on 9.4 has a fixed window to move, and the renewal conversation should start from that date rather than from price alone. Confirm your exact running version, its end-of-support date and the patch and upgrade paths that Splunk currently documents with your account team before you sign anything.
The short answer is that upgrading stays the lower-change path for Splunk-centric teams. An in-place upgrade keeps your SPL correlation searches, dashboards, saved searches, apps and universal forwarders working, so the work is mostly compatibility testing and a staged rollout. The replacement path splits the job in two: Wazuh for detection, agents and compliance views, and OpenSearch for search, dashboards and retention. That path is worth the effort when the team has a weak hold on its Splunk content, wants to end the license exposure, or needs data to stay in a self-hosted environment with no vendor dependency on the search layer. For most teams, the deciding question is how much SPL content, how many dashboards and how many forwarders the team owns and can rewrite within its window.
What end of support requires from your Splunk estate
Splunk Enterprise 9.4 support ends on December 16, 2026, and each minor version has a 24-month support window. Every requirement below comes from that date, and each one applies whether you upgrade Splunk or move to Wazuh and OpenSearch.
Supported version on every component
Check the version of each search head, indexer, forwarder and deployment server, not only the version of the front door. A single node left on 9.4 after the deadline keeps the estate outside vendor support, and mixed versions can complicate cluster upgrades. Build an inventory from your deployment server and cluster manager, then record the current version and owner for each host. Confirm the target version and the support window with Splunk before you commit to a date.
Dated upgrade path
Set the cutover date from the support calendar and work backward. Decide which environments move first, which stay on the old version for the longest, and who approves each change. Confirm with Splunk which upgrade sequence applies to your topology, including any intermediate versions. If you plan to replace the platform instead, the same calendar sets the latest date for dual running.
Forwarder and agent coverage
Every universal forwarder, heavy forwarder and syslog path must either be upgraded or given a successor. If you move to Wazuh, each endpoint needs a Wazuh agent, and agents are available for Linux, Windows, macOS, Solaris, AIX and HP-UX. Devices that cannot run an agent, such as firewalls, need syslog collection and periodic API probing. List each source, its collection method and its owner before you plan the cutover.
Detection and dashboard continuity
Inventory every saved search, correlation search, alert and dashboard, and mark which ones your SOC uses weekly. During cutover, run the old and new detections side by side and compare the alerts they produce on the same events. Keep a sign-off record for each detection, because auditors and incident responders will ask how alerting behaved before and after the move. Rewriting SPL is the largest unknown, so scope it early.
Historical data that stays searchable
Decide which events must remain searchable after the cutover and for how long your retention policy requires. Splunk search results can be exported as raw events, CSV, JSON, XML or PDF, and Splunk describes the CLI as its most stable retrieval method. Test a full export of a representative index before you rely on it, and confirm that exported files keep timestamps and fields. Store the archive under the same access controls as the live data.
Upgrade in place, replace, or run both: which path fits which team
Teams with large libraries of SPL correlation searches, custom apps and saved alerts carry the most detection logic, so the choice depends on how much of that logic must survive the change. Upgrading Splunk Enterprise keeps the search language and app behavior intact, which limits rework to testing. Replacing it means each correlation search is rewritten as a Wazuh decoder and rule set, and any app-level views need to be rebuilt in the Wazuh dashboard or OpenSearch Dashboards.
- Detections: Upgrade keeps SPL searches working after testing. Replacement requires translating each search and validating it against the same test events.
- Dashboards: Custom Splunk dashboards and app views need rebuilding in a different dashboard tool.
- Agents: Universal forwarders can stay during an upgrade. Replacement moves endpoints to Wazuh agents.
- History: Export historical events before any cutover, using the CLI or REST API, so past searches can still be checked.
- Parallel run: Keep Splunk receiving data while the rewritten rules are compared against its alerts.
Before deciding, confirm with Splunk which apps your team depends on, which versions of those apps support your next target release, and whether your renewal terms cover the upgrade window.
Teams that use Splunk mainly for log search, operational dashboards and occasional alerts usually have less SIEM-specific content to move. Their main question is whether the search and dashboard workload can run on OpenSearch with acceptable query translation and sizing work. Because the security content is light, an OpenSearch-based replacement can be scoped around ingestion and dashboards first, with Wazuh added only if endpoint monitoring is also needed.
- Detections: Few rules usually exist, so the effort goes into alerts and dashboard queries rather than a full rule rewrite.
- Dashboards: SPL searches and dashboard panels are translated into OpenSearch queries and OpenSearch Dashboards visualizations.
- Agents: Forwarders can be replaced by Fluent Bit, Fluentd or the OpenTelemetry Collector, or kept in place during a transition.
- History: Retention policy and index lifecycle decisions determine how much history must be exported and how much can expire.
- Parallel run: Dual ingestion lets analysts compare search results from both platforms before retiring Splunk searches.
Before deciding, ask Splunk for the exact retention settings and export options for your indexes, and confirm the data volume you expect to keep online after the move.
Teams in networks without internet access must check two things early: whether the Splunk release they need to run is available through their offline media process, and whether the replacement can be installed and kept current without a live connection. Wazuh documents an offline installation guide and can use an offline vulnerability repository in place of its online threat intelligence platform. OpenSearch documents tarball, RPM and Debian packages that can be staged inside the network. The work is mostly in the update path, since each patch must be tested and delivered by hand.
- Detections: Rules and decoders move through your own change control, so updates depend on the offline repository you maintain.
- Dashboards: Dashboards are rebuilt or exported as files, which must be imported on the isolated network.
- Agents: Wazuh agents on isolated endpoints need a route to the manager, or a staged package path that your environment allows.
- History: Exports from Splunk leave the network through an approved transfer path, so plan the media and approvals in advance.
- Parallel run: Feeding both platforms from the same collectors keeps Splunk current while the replacement is validated.
Before deciding, confirm with your Splunk account team which offline and air-gapped delivery options are supported for your target version, and ask the replacement's vendors how patch delivery works without a connection.
Most teams that move off Splunk do not switch on a single day. A parallel run keeps both platforms receiving the same data, so detections, dashboards and alert volumes can be compared before Splunk is retired. This matters most when the upgrade and the renewal fall together, because the team may need Splunk through the transition window. Dual collection adds cost for as long as both run, so the length of the overlap should be set by the detection comparison, not by habit.
- Detections: Each rule is marked as matched, missing or noisy against the other platform's alerts before cutover.
- Dashboards: Analysts check that the replacement views answer the same questions as the Splunk views.
- Agents: Collectors send data to both destinations, so no endpoint is removed from Splunk early.
- History: Historical exports are validated against the replacement's indexes before old data is archived.
- Cost: Double ingestion and storage during overlap are direct costs to model with both vendors.
Before deciding, ask Splunk how its license or workload terms treat dual ingestion during the overlap, and agree on an exit date in writing with your implementation partner.
Upgrade Splunk, replace with Wazuh and OpenSearch, or split the workload
This table compares three ways to meet the December 16, 2026 end of support date for Splunk Enterprise 9.4: upgrading Splunk, replacing it with Wazuh and OpenSearch, or splitting security monitoring and log search between them. Read each row across the options to see the work and trade-offs, then match the path to your renewal and your team's SPL and detection content. The main takeaway is that the split path is often easier to stage than a single cutover, but it means running and securing two platforms.
| Decision area | Upgrade Splunk Enterprise | Wazuh and OpenSearch replacement | Split: Wazuh for security, OpenSearch for logs |
|---|---|---|---|
| How it meets end of support | Moves to a Splunk version still in its support window, which Splunk documents per minor release. Confirm the target version and its end date with Splunk before committing. | Removes Splunk from the stack once data, content and users have moved. Support then comes from your provider or internal team, not Splunk's lifecycle. | Removes Splunk for both workloads over time. Security monitoring moves first, while log search can stay on Splunk until its own move. |
| Main work created | Upgrade testing of apps, add-ons, custom searches, alerts and forwarders, plus an upgrade path for each indexer and search head. | Rewrite SPL correlation searches as Wazuh decoders and rules, rebuild dashboards in OpenSearch Dashboards, re-point ingestion and set index lifecycle policies. | Two pipelines in parallel: Wazuh agents and rules for detections, and OpenSearch ingestion and dashboards for search. Both need their own tuning and access controls. |
| Search language and content | No change. Existing SPL, saved searches and app content continue to run on the upgraded platform. | Wazuh has no SPL. Detection logic is rewritten in Wazuh rules and decoders, and ad hoc search moves to OpenSearch query tools. | SPL stays for log search only if it is kept. Detection content must still be rewritten for Wazuh, so SPL knowledge is needed for both paths. |
| Maintenance and patching | Splunk sets the patch and support cadence for each minor version. Plan upgrades within the vendor's published window. | Wazuh 4.14 receives patch releases roughly every one to two months. OpenSearch versions get security patches only during a maintenance window, so plan minor and major upgrades. | Two release cycles to track. Wazuh and OpenSearch patch schedules must be combined into one maintenance calendar. |
| Licensing and cost drivers | Splunk licensing continues to apply. Confirm current terms and renewal scope with Splunk or Cisco before comparing totals. | Wazuh is GPLv2 and OpenSearch is Apache 2.0, so no license fee applies. Costs are compute, storage, staff time and any outside support you buy. | Lower license exposure than Splunk, but two sets of infrastructure, staff time and support contracts. Count both in the total. |
| Trade-offs to weigh | Lowest disruption to current searches and alerts. Does not reduce license exposure or change the platform's long-term direction. | Full move to open source with a single platform for detections and search. Requires the most rule rewriting and testing before cutover. | Lets teams move detections first and keep Splunk search running. Adds integration work between the two systems and a longer period of dual operation. |
| When to choose it | Choose this when the renewal is near, the team relies on many Splunk apps, and a short-term upgrade is the priority. | Choose this when the team can rewrite detections and accepts a single cutover with a defined rollback plan. | Choose this when security content can move in stages and log search needs more time to change. Confirm the target workloads before deciding. |
How to deploy Wazuh and OpenSearch under your change window
This sequence takes a team from an isolated test environment to a Wazuh and OpenSearch stack that runs alongside Splunk long enough to prove detections match before any cutover decision is made.
Choose the deployment method and network model
The platform or security architect picks one documented route: all-in-one or step-by-step installation, the prebuilt OVA, Docker, Kubernetes, Ansible, Puppet, or the offline installation guide if the network has no internet access. The choice depends on your change control, your configuration management and whether packages can reach the network at all. Record the decision, the host sizing and the version you will pin. The step is done when the target hosts are provisioned in the isolated environment and the chosen method is written into the change ticket.
Install the Wazuh indexer, server and dashboard
The platform engineer installs the Wazuh indexer, which stores alerts and runs full-text search, then the Wazuh server, which applies decoders and rules to agent data, then the Wazuh dashboard. Install the components in the order the chosen guide specifies and confirm that each service starts and reports healthy before moving on. Plan for the server to run as a cluster later if volume grows, since the server supports horizontal scaling. The step is done when all three components answer health checks and a test login to the dashboard succeeds.
Enable TLS, authentication and index lifecycle settings
The security engineer configures TLS for node and client traffic, sets up authentication against your identity provider where the platform supports it, and defines role-based access for analysts, administrators and read-only auditors. Create index lifecycle policies that match the retention your compliance obligations require, and confirm the policies with your legal and compliance owners rather than assuming a default. Document every setting in the configuration baseline. The step is done when an unauthenticated request is refused, a test analyst sees only the roles granted to them, and an index lifecycle transition is observed on a test index.
Enroll agents through remote management
The endpoint or operations team deploys Wazuh agents to a pilot group of Linux, Windows or other supported hosts, then enrolls them through the server so that configuration and agent upgrades are managed remotely. Start with a set of hosts that already produce well-understood Splunk events, so you have a reference for comparison. Add agentless sources, such as firewalls, through syslog collection where you cannot install software. The step is done when every pilot agent shows as active in the dashboard and its events appear in the indexer.
Load vulnerability data from the right source
The vulnerability management owner confirms whether the environment can reach the Wazuh Cyber Threat Intelligence platform. If it cannot, configure vulnerability detection to use an offline vulnerability repository instead, and confirm how that repository is refreshed and who approves each update. Vulnerability detection correlates the software inventory collected by the agents with that data, so verify that inventories appear for the pilot hosts. The step is done when a pilot host shows a populated software inventory and its vulnerability findings come from the data source you approved.
Rebuild detections and enable the compliance views
The detection engineer translates the highest-value Splunk correlation searches into Wazuh decoders and rules, starting with the detections that drive incident response. Enable the prebuilt dashboard views for the frameworks your auditors use, such as PCI DSS, GDPR, HIPAA or NIST 800-53, and check that each view maps to evidence you can show. Record which Splunk detections were not rebuilt and why. The step is done when each rebuilt rule has a named owner, a test event that triggers it and a documented gap list for anything still unmatched.
Run both platforms in parallel and compare alerts
The security operations lead keeps Splunk receiving the same sources while the new stack receives copies, then compares alerts from both over a period agreed in the change plan. Review each divergence, classifying it as a missing rule, a parsing difference or a genuine detection gap, and assign the fix. Keep the Splunk exports and the cutover criteria in the change record so that the decision can be audited. The step is done when every divergence is closed or accepted by the platform owner, and the cutover criteria are signed off before any Splunk renewal or upgrade decision is taken.
Exporting Splunk history before the support date passes
Before you choose between the next Splunk upgrade and a move to Wazuh and OpenSearch, confirm that you can get your historical events out of Splunk in a form you can use. Splunk exports search results as raw events, CSV, JSON, XML or PDF, and you can run the export through Splunk Web, the CLI, the REST API, the SDKs, the dump search command or data forwarding. Splunk describes the CLI as its most stable retrieval method, so it is the first option to test for large retrievals. Which method fits depends on volume: Splunk Web suits small saved-search exports, while the CLI, REST API and dump are better suited to bulk pulls. Your Splunk administrator should confirm the exact export limits for your version against the Splunk export documentation, since those limits depend on the deployment.
Run a sample export this month, not after the renewal is signed. Pick one index, one sourcetype and a time range that covers a known incident, export it with each method you expect to use, and then reload the output into a test OpenSearch or Wazuh indexer. Check event counts, timestamps, time zones, field names and the handling of multi-line events. A CSV or PDF export loses fields that a JSON or raw export keeps, so compare the outputs before you decide what counts as your record of history. Keep the sample and its checksums with your change records.
Confirm two things with Splunk before you plan. First, confirm your deployment type, because Splunk Enterprise and Splunk Cloud Platform handle bulk export and archive differently. Second, ask whether your environment has any archive or self-storage option for expired index data, and who owns the cost and the access keys for it. Ask your account team to put the answers in writing, along with what the upgrade path and the 9.4 end-of-support date mean for your version. Those answers determine whether you export everything, archive in place, or split the work across both.
Evidence assessors and regulators ask for during a platform change
A platform change from Splunk Enterprise is judged on records, not intentions. The six items below connect the version inventory, the approval trail, the detection comparison, the retained data and the access controls, so an assessor can follow one change from start to finish. DeployOpen prepares this evidence, while independent auditors and certification bodies issue any audit opinion.
Inventory of versions and components
List every Splunk Enterprise instance, its installed minor version, its forwarders, indexers, search heads and apps, and the end-of-support date for each minor version. Splunk Enterprise minor versions are supported for 24 months, and 9.4 support ends on December 16, 2026. Record which hosts are still on 9.4 so the upgrade or replacement deadline is visible to the approvers and the auditor.
Change and approval records
Keep a dated record of the decision to upgrade or replace, the risk assessment, the rollback plan, the named approvers and the change windows. For a replacement, add the target versions of Wazuh and OpenSearch and the owner of each component. Assessors usually ask who approved a change and whether the approval came before the work started.
Parallel-run detection comparison
Run Splunk and the new platform side by side on the same log sources, then compare alerts, detections and false positive rates for each use case. Keep the query used on each side, the time window, the sample of events reviewed and the reasons for every difference. Without this record, a team cannot show that a detection that fired in Splunk still fires in the replacement.
Retention and export records
Show that historical events are still searchable or archived after cutover. Record the export method used for each dataset, such as Splunk Web, the CLI, the REST API or data forwarding, the row counts, the hash or checksum of each export, and the restore test. Confirm the retention periods that your own regulator or policy requires before you set them in the new platform.
Access control and encryption
Document the authentication backend, role-based access rules, audit logging and TLS settings for the new platform. In OpenSearch, that means the Security plugin with SAML, OpenID Connect or LDAP, role mappings, field-level security and TLS for node and client traffic. Also record how Wazuh dashboard access is federated and who holds administrator rights.
Patch and upgrade cadence
Record the patch policy for the new platform, including who tracks release notes, how often patches are applied and how security fixes are tested. Wazuh shipped 4.14 patch releases several times in 2026, and OpenSearch targets a new minor version about every eight weeks. Assessors look for evidence that the platform stays on a supported line and that each upgrade follows the same change process.
What does a Splunk end-of-support move cost and require?
What drives the cost of a Splunk upgrade compared with a replacement?
The main cost driver is how much Splunk content you must carry across: the number of indexes, forwarders, saved searches, dashboards, correlation searches and apps. An in-place upgrade to a supported Splunk Enterprise version keeps that content and the existing license, so the work centers on testing apps, forwarders and custom configuration against the new version. A replacement with Wazuh and OpenSearch adds new compute, storage and retention design, rewriting detections as Wazuh rules and decoders, and parallel running. Ask any provider to break the quote into those components so you can compare like with like.
Which Splunk costs are one-time and which recur after a move?
Recurring costs are the Splunk license or subscription until the day it ends, plus the infrastructure and staff time to run whichever platform you keep. One-time costs include planning, inventory, content translation, testing, cutover and documentation. On a self-hosted stack, Wazuh and OpenSearch carry no license fee, but compute, storage for your retention period, patching, rule maintenance and outside support recur. Splunk's support window is set by its 24-month rule per minor version, with 9.4 support ending on December 16, 2026, so model the one-time work against the date your current license term ends. Confirm exact Splunk renewal terms with your Splunk account team.
Can our own team handle a Splunk end-of-support move without a partner?
A team with Linux, Elasticsearch-family and SIEM experience can often do an upgrade in house, especially if the environment is small and well documented. A replacement is harder to staff alone because it needs decisions on data flow, detection logic, access control and retention, and someone must own the rules after go-live. Most teams find the gap is in the translation work, not the installation. Assess your own skills honestly, list the people who know your SPL content, and decide which parts you would hand to a fixed-scope engagement.
How long does a Splunk upgrade or replacement usually take?
No single duration applies, and this page does not give one. Timing depends on the number of data sources and forwarders, how many correlation searches and dashboards need rebuilding, the retention you must keep, how much historical data you migrate, and how long parallel running lasts before detections match. Access approvals and change windows often set the pace more than the technical work. Ask for a timeline in the written scope that lists each phase and the assumptions behind it, and check it against the 9.4 end-of-support date of December 16, 2026.
What must our team supply before an engagement starts?
Start with a complete inventory of indexes, forwarders, inputs, apps, saved searches, alerts, dashboards and data sources, with owners for each. Provide read access to the Splunk environment, a test or staging copy where possible, and the list of compliance frameworks your reports must cover. Also supply SPL correlation content, sample events for each source, retention requirements and the change windows and approvals your organization needs. For exports, Splunk offers the CLI, REST API and SDKs, and the CLI is the method Splunk calls its most stable retrieval option, so confirm early which export path your data volume needs.
How do we request a fixed-scope quote for this work?
Send a written description of your current Splunk version, deployment type, data sources, search and dashboard counts, retention needs, target platform, compliance obligations and the dates that matter to you. DeployOpen plans and delivers most engagements as fixed scope, with scope, deliverables and timelines agreed in writing before work starts. DeployOpen does not publish a price list, so a quote follows from that written scope. Ask any provider to state assumptions, exclusions, the handover format, what happens if data volumes differ from the inventory, and whether ongoing support or upgrades are priced separately.
What compliance evidence does a Splunk replacement need to preserve?
Preserve the controls and logs that auditors already rely on: which sources are collected, how long logs are retained, who can search them, what alerts fired, and how changes to detection content were approved. Wazuh includes prebuilt dashboard views for frameworks such as PCI DSS, GDPR, HIPAA and NIST 800-53, but those views do not replace your own control mapping. DeployOpen prepares systems, controls and evidence for compliance assessments, while independent auditors and certification bodies issue any reports or certifications. Confirm with your assessor which records they will need before cutover.
How DeployOpen plans a Splunk end-of-support move
DeployOpen plans a Splunk Enterprise end-of-support move as a fixed-scope engagement inside your own infrastructure. The work starts with a written scope that compares the next Splunk upgrade with a Wazuh and OpenSearch build, so the decision rests on your data sources, detections and compliance evidence.
How we scope
- Inventory current Splunk versions, apps, forwarders, indexes and scheduled searches before any decision is made
- Agree in writing which detections, dashboards and exports must survive the move, and which can be retired
- Confirm hosting, air-gap, data residency and retention requirements so the target design fits your environment
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts
How we build
- Size and deploy Wazuh server, indexer and dashboard, or an OpenSearch cluster, in your cloud account or data center
- Rewrite priority correlation searches as Wazuh decoders and rules, and test them against recent historical events
- Run Splunk and the target platform in parallel while detections are compared event by event
- Configure TLS, role-based access, single sign-on and audit logging to match your existing security baseline
How we hand over
- Document the architecture, data flows, retention settings, detection inventory and rollback steps
- Deliver an export of retained Splunk data in agreed formats, with a record of what was exported and verified
- Train your operations and security staff on alert triage, rule changes and routine upgrades
- Prepare control mapping and evidence for your compliance assessors, who issue any audit report or certification
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover
- Track Wazuh and OpenSearch release cycles and plan patch windows with your change board
- Re-run detection tests after upgrades so rule behavior is confirmed before production changes
- Agree retainer scope, response expectations and review cadence in writing as part of the quote
