Splunk 9.3 Is Past End of Support: Which 10.x to Land On
9.3 went out on 24 July 2026 and 9.4 follows on 16 December, so the stepping-stone plan is gone. Splunk sells 24 months from a minor's release date, which makes the version you pick a purchase of months. The walls are the CPU, the certificates, and the forwarders.
Splunk Enterprise 9.3 reached end of support on 24 July 2026. No more security patches, no more bug fixes, and TAC will not take the ticket when your indexer cluster wedges at two in the morning.
The advice everyone gave before that date was to hop through 9.4 first, on the theory that two small jumps beat one large one. That plan has expired. 9.4 goes out on 16 December 2026, which is under four months away, so the stepping stone now costs a full validation cycle and buys a single quarter before you do the whole thing again.
Which leaves one real question, and it is not the one the version numbers suggest.
Splunk sells months, and it starts the clock without you
Each minor release is supported for 24 months from the date that minor shipped, not from the date you installed it. Splunk publishes both columns in the support policy, and lining them up changes what a version choice means.
10.0 shipped on 28 July 2025, so landing on it today buys eleven months. 10.4 shipped on 18 May 2026 and buys twenty-one. Same upgrade work, same validation cycle, roughly double the runway. Unless something in your app estate is pinned to 10.0 or 10.2, the newest supported minor is the cheapest one per month of coverage, and that stays true every time this comes around.
The counterweight is patch maturity. 10.0 is on 10.0.7 and 10.2 is on 10.2.4, while 10.4 is still on its initial release. If your deployment is the SOC’s only view of the estate, 10.2 is a defensible middle: nine months longer than 10.0, with four maintenance releases behind it.
The wall that stops the service from starting
Before anything else, check the CPU. Splunk 10.0 requires AVX, SSE4.2, and AES-NI, because KV Store will not start without them. This is not a warning or a deprecation notice. The service does not come up.
grep -o -E 'avx|sse4_2|aes' /proc/cpuinfo | sort -uThree lines back means you are fine. The hardware is rarely the problem, since anything from Sandy Bridge or Bulldozer onward has all three. The problem is virtualization: a hypervisor pinned to an older CPU model for live-migration compatibility will mask the flags even though the metal underneath has them. Run this on every host, not one representative host, because CPU model pinning tends to be set per cluster and your indexers may not live where your search heads do.
The certificates are the second wall
10.0 moves the bundled OpenSSL from 1.0.2 to 3.0, and Splunk’s upgrade guidance spells out what that rejects. Certificates with SHA-1 signatures are no longer accepted and have to be reissued with SHA-256 or better. CA certificates now have to carry the X509v3 Basic Constraints extension with CA:TRUE.
That second one is the quiet killer. Plenty of Splunk deployments run on an internal CA somebody generated years ago with a short openssl req incantation, and that incantation does not add Basic Constraints unless you ask it to. The certificate has worked perfectly under 1.0.2 for its whole life. It stops working the moment the forwarders try to connect to a 10.x indexer.
Audit what you have before you schedule anything:
openssl x509 -in $SPLUNK_HOME/etc/auth/mycerts/myServerCert.pem -noout -text \
| grep -E 'Signature Algorithm|CA:'Reissuing an internal CA and redistributing it across a forwarder fleet is a project in its own right. Finding out you need one during the cutover window is the difference between a Saturday and a month.
TLS 1.0 and 1.1 still work in 10.0, with warnings, unless you are in FIPS mode, where they are off.
Forwarders are not the easy part any more
Splunk supports a direct upgrade to the 10.0 universal forwarder from 9.4.x and higher. Read that as the exclusion it is: a 9.3 forwarder cannot go straight to 10.0. If your fleet was standardized on 9.3 alongside the indexers, every one of those endpoints needs a hop through 9.4 or a clean reinstall.
The good news is that you do not have to do it on the same weekend. Forwarders on a lower version than the indexers keep sending, so the sane order is cluster manager and license manager, then search heads, then a rolling indexer upgrade, then the fleet on its own schedule. But “the fleet is fine” and “the fleet is a two-step migration across ten thousand endpoints” are different line items, and the second one is the true shape of this.
Python, and the add-ons that die quietly
10.0 makes Python 3.9 the default and removes 3.7 entirely. Scripted inputs, alert actions, modular inputs, and add-ons carrying their own Python all get run against the new interpreter.
The failure mode is what makes this expensive. A broken scripted input does not raise a banner in the UI. It stops producing events, and the dashboard that depended on it renders an empty panel that looks exactly like a quiet night. So the staging test is not “does Splunk start”, it is “do the searches that matter return the same data they returned yesterday”. Pull a representative slice of config and apps onto a 10.x instance and diff the results of your real detections against production.
The estate to inventory is your in-house scripts, the technology add-ons for sources nobody has touched in three years, and any premium app such as Enterprise Security or ITSI, which carry their own compatibility matrix against the core platform.
Order of operations
Check the CPU flags on every host first, because the answer can invalidate the schedule before you build one. Then audit the certificates for SHA-1 signatures and missing Basic Constraints, since reissuing takes calendar time you cannot compress. Confirm your KV Store server is at 4.2 or higher, which is the precondition for the automatic move to 7.0 during install, and back up every KV Store database before you touch anything, because that migration is the step with no rollback.
Snapshot $SPLUNK_HOME/etc in full. Enable maintenance mode on the cluster manager before rolling indexers, so the cluster stops trying to heal what is just you doing the upgrade. Verify each tier returns data before moving to the next.
Note that Hadoop Data Roll is gone in 10.0 with no supported rollback, and in-place upgrade on macOS is not supported at all. Neither touches most production Linux deployments, but both are the kind of thing that turns up on the day.
The part that is not really about Splunk
A forced upgrade is a natural moment to price the alternatives, and per-GB ingest is the reason that thought occurs. It is also a multi-quarter project: the SPL, the dashboards, and years of tuned detections do not port on a weekend.
If your renewal is close and the number stings, cost it out in parallel. But an unsupported SIEM is the wrong place to run that evaluation from, and the 9.x line is finished in December either way. Get to a supported 10.x on a calendar you control, then argue about the invoice.
Start with grep -o -E 'avx|sse4_2|aes' /proc/cpuinfo on every host. Thirty seconds each, and it is the only check whose answer can turn this from a scheduling exercise into a hardware purchase.