If you’re still on Splunk Enterprise 9.3, you have until July 24, 2026 before it goes end of support. After that date there are no more security patches, no bug fixes, and no TAC tickets. Your cluster keeps running — nothing flips off at midnight — but you’re now operating unsupported security-monitoring infrastructure, which is exactly the kind of thing an auditor circles in red.
That’s the awkward part. Splunk is often the tool watching everything else for compliance. Running it on an unpatched version undercuts the entire reason you bought it. So the question isn’t really “should I upgrade” — it’s “9.4 or straight to 10.0, and what’s going to break when I do.”
I’ve been through enough Splunk upgrades to tell you the answer up front: for most teams, go straight to 10.0. But 10.0 has a couple of genuinely nasty gotchas that 9.x never had, and one of them can leave you unable to start the service on hardware that worked fine the day before.
What “end of support” actually costs you
Splunk’s support policy gives each minor release roughly two years from its release date. 9.3 shipped in mid-2024, so July 24, 2026 is its number. For comparison, 9.4 runs until December 16, 2026, and the 10.x line is where the long runway is — 10.4, the current release as of mid-2026, is supported through May 2028.
End of support means three concrete things stop:
- Security patches. Any CVE found in 9.3 after July 24 stays open on your systems. For a SIEM sitting on privileged log data, that’s not theoretical risk.
- Vendor support. TAC won’t take your P1. If your indexer cluster wedges at 2am, you’re on Splunk Community and your own runbooks.
- Compliance standing. PCI, SOC 2, FedRAMP, HIPAA — they all have language about running supported software. An unsupported SIEM is a finding waiting to happen.
If you’re in a FIPS-mode deployment, that deadline already passed. Splunk set March 8, 2026 as the hard date for FIPS environments to be on 10.0, because 10.0 introduces a new FIPS 140-3 validated cryptographic module. If that’s you and you’re reading this in July, you’re not planning an upgrade — you’re remediating a compliance gap, and it needs to jump the queue.
9.4 as a stepping stone, or straight to 10.0?
The instinct with big version jumps is to do it in stages: 9.3 → 9.4 → 10.0, testing at each hop. It feels safer. For Splunk 10.0 specifically, I don’t think it buys you much.
Here’s the reasoning. 9.4 buys you five extra months of support (December vs July) and not much else you care about long-term — you’d just be doing the whole validation-and-rollback dance twice. The real breaking changes all live in the jump to 10.0, and you have to face them either way. Doing 9.3 → 9.4 first doesn’t defuse a single one of them; it just delays them behind an extra migration.
Go to 9.4 first only if one of these is true:
- You’re time-boxed against July 24 and can’t finish full 10.0 validation in time. 9.4 gets you back into supported territory fast, and you follow with 10.0 before December.
- You have a sprawling app/add-on estate and want to isolate “does my stuff survive a minor upgrade” from “does my stuff survive the Python and OpenSSL changes.” Splitting the variables makes debugging cleaner.
For a typical single-site or small-cluster deployment with a manageable app list, one well-tested jump straight to 10.0 is less total work. Just respect the gotchas below, because 10.0 is not a routine upgrade.
The three things in 10.0 that will actually bite you
1. The CPU requirement nobody expects
This is the one that catches people. Splunk Enterprise 10.0 requires processors with AVX, SSE4.2, and AES-NI instruction support. If your CPU doesn’t have them, 10.0 will not run — the KV Store won’t start, and by extension neither will a lot of your deployment.
In practice this means roughly Intel Sandy Bridge (2011) or newer, or AMD Bulldozer-era and up. Most modern hardware clears this without a thought. The trap is older virtualized environments and — this is the sneaky one — VMs where the hypervisor masks CPU features or pins an older CPU model for live-migration compatibility. Your bare metal might have AVX; your VM might not expose it.
Check before you touch anything. On Linux:
grep -o -E 'avx|sse4_2|aes' /proc/cpuinfo | sort -uYou want all three to come back. If one’s missing on a VM, it’s usually a hypervisor CPU-model setting, not a hardware limit — but you need to fix it (or move the workload) before upgrade day, not discover it at cutover.
2. Python 3.7 is gone
Splunk 10.0 moves the bundled interpreter to Python 3.9 and drops 3.7 entirely. Any custom scripted input, alert action, modular input, or add-on with Python that imports something removed or changed between 3.7 and 3.9 will break — silently in some cases, since a broken scripted input just stops producing data rather than throwing a banner.
This is where your Splunkbase apps matter most. Before upgrading, list every app and add-on and check each one’s stated Python/version compatibility on Splunkbase. Pay special attention to:
- Anything you wrote in-house years ago and forgot about
- Older TAs (technology add-ons) for data sources that haven’t been updated
- Premium apps like Enterprise Security or ITSI, which have their own version requirements against the core platform
Don’t assume “it’s a Splunk app so it’ll be fine.” The whole point of the staging validation step is to catch the add-on that quietly died.
3. OpenSSL 3.0 and the TLS cleanup
10.0 moves to OpenSSL 3.0. If any of your Python code has a direct dependency on the old OpenSSL 1.0.2 low-level APIs — more common in FIPS setups — it can fail after the upgrade, because some of those APIs aren’t FIPS-compliant under 3.0. Apps calling OpenSSL directly need to be updated to supported 3.0 APIs.
Alongside that, SSLv3 and TLS 1.0/1.1 are deprecated. They still work in 10.0 but throw warnings, and you should be planning your move to TLS 1.2+ regardless. If you’ve got legacy forwarders or integrations pinned to old TLS, flag them now.
There are a couple of smaller removals worth a mental note: Hadoop Data Roll is gone (archive aged buckets to local storage instead), and you cannot do an in-place upgrade to 10.0 on macOS — fresh installs only, on Intel Macs meeting the CPU requirement. Neither affects most production Linux deployments, but if either describes your setup, plan around it.
Forwarders: the part that’s actually easy
Good news for once. Universal forwarders support a direct upgrade from 9.4.x and higher to 10.0, and the forwarder-to-indexer compatibility rules are forgiving — a forwarder on the same or a lower major version than the indexer generally works, so you don’t have to upgrade thousands of endpoints in lockstep with your indexers.
The sane order is indexers and search heads first, then forwarders on your own schedule. Your 9.x forwarders will keep sending to 10.0 indexers while you roll the fleet. Just don’t leave forwarders on unsupported versions forever — “works” and “supported” aren’t the same, and you’ll want them current for the next TLS tightening.
If you’re managing Linux UFs at scale, the deployment server path still works, but confirm your deployment clients are 7.0.0+ and that your rollout tooling handles the restart cleanly.
The pre-upgrade backup that saves your weekend
Whatever path you pick, do not skip this. The single most common cause of a bad Splunk upgrade turning into a bad Splunk weekend is a missing or untested backup. Before you upgrade anything in production:
- KV Store. Back up every KV Store database. 10.0 requires KV Store server 7.0+ and auto-upgrades the store during install — and that migration is the step most likely to go sideways. A KV Store backup is your only clean rollback.
- Configs. Snapshot
$SPLUNK_HOME/etcin full — apps, users, system local, everything. This is your entire configuration surface. - Indexes. You generally don’t roll back indexed data on an upgrade, but know your retention and replication state going in, especially on clustered indexers.
Then validate in staging. Stand up a 10.0 instance, restore a representative slice of your config and apps, and actually run your critical searches, dashboards, and alerts against it. The apps that break tend to break quietly, so you’re looking for missing data and dead panels, not just error banners.
A rollout that lets you sleep
Here’s the sequence I’d run for a clustered deployment:
- Inventory and check. List all apps/add-ons with their Python compatibility. Run the CPU check on every host. Note anything on OpenSSL 1.0.2 APIs or old TLS.
- Staging validation. Build 10.0 in staging, restore config, run your real searches and alerts. Fix or replace what breaks. This is where the time actually goes — budget for it.
- Back up production. KV Store,
etc, cluster state. Verify the backups restore, don’t just take them. - Enable maintenance mode on your indexer cluster manager before touching cluster members. This stops the cluster from trying to fix “failures” that are just you doing a rolling upgrade.
- Upgrade the tier order: cluster manager / license manager, then search heads, then indexers (rolling), then forwarders on their own timeline.
- Verify at each tier before moving on. Searches returning data, KV Store up, forwarders connecting.
Your rollback plan is the KV Store and config backups plus a documented “reinstall 9.3 and restore” runbook. Write it before you need it. The worst time to figure out your rollback is while a stakeholder is asking why the SOC dashboards are blank.
The bigger question hiding under the deadline
A forced upgrade is also a natural moment to ask whether you should be upgrading at all, or switching. Splunk’s per-GB ingest pricing is the reason “Splunk cost shock” is a phrase, and a lot of teams hit their EOS deadline and use it as the trigger to evaluate alternatives — Microsoft Sentinel’s consumption model, Elastic’s node-based pricing, or a flat-rate option like Google Chronicle.
I’m not going to pretend that’s a quick decision. Migrating a mature Splunk deployment — with its SPL, its dashboards, its years of tuned detections — is a multi-quarter project, not a weekend. If your renewal is close and the number stings, it’s worth costing out in parallel. But if you’re staring down July 24 with no migration underway, the pragmatic move is clear: upgrade to 10.0 now to close the support gap, then evaluate stay-vs-switch on a calm timeline instead of a deadline.
The one thing you shouldn’t do is nothing. An unsupported SIEM isn’t a “we’ll get to it next quarter” item — it’s the tool your auditors and your incident responders are both counting on, running without a safety net.
Start with the CPU check. It takes thirty seconds and it’s the one thing that can turn a routine upgrade into a stalled cluster. If every host comes back clean on AVX, SSE4.2, and AES-NI, the rest is just careful sequencing.
Sources: Splunk Software Support Policy, About upgrading to 10.0 — READ THIS FIRST, Welcome to Splunk Enterprise 10.0, Preparing to upgrade from 9.x to 10.0 — Splunk Lantern, Splunk End of Support Dates