Elasticsearch 8.x end of maintenance (15 Jan 2027)
Dates, staging path to 9.x, OpenSearch decision matrix and Australian residency.
Read guide →Hot topic · Verified against elastic.co
Elasticsearch 8.x stops receiving patches on 15 January 2027
If you are on 7.17 or earlier, you are already running an unsupported search and logging platform. Support ended 15 January 2026. If you are on 8.x, maintenance ends 15 January 2027 and support follows on 15 July 2027. Elastic Enterprise Search has been retired outright, with no further major releases.
Dates cited from elastic.coZero detection rules lost on our last cutoverSydney & Melbourne residency available
Verified dates
Every Elastic Stack version, and where it stands today
| Version | End of maintenance | End of support | What it means |
|---|---|---|---|
| 7.16 and earlier | Passed | Passed | Unsupported. No patched upgrade path for new CVEs. |
| 7.17.x | 15 Apr 2025 | 15 Jan 2026 | Unsupported since January 2026. |
| 8.x | 15 Jan 2027 | 15 Jul 2027 | Maintenance ends in months, not years. Plan now. |
| Elastic Enterprise Search 8.x | 15 Jan 2027 | 15 Jul 2027 | Retired. Retirement notice issued 15 Apr 2025, no further major releases. App Search and Workplace Search have no upgrade path. |
| 9.x | 15 Oct 2027 | Six months after maintenance | Current major release. |
Source: Elastic Product End of Life Policy. Verified 7 August 2026. End of maintenance is the date that matters for planning. After it there are no further bug fixes or security patches, even though support continues for a further six months.
Interactive
Classify your estate in 60 seconds
Deep guides
Read the evidence before you book the audit.
Enterprise Search has no 9.x path
App Search and Workplace Search dependency map and re-platform options.
Read guide →Adobe Commerce search cutover
Version matrix, reindex validation and cutover without blank results.
Read guide →Keeping logs in Australia (APP 8)
Sydney/Melbourne architecture, residency vs sovereignty, offshore access controls.
Read guide →Australian delivery
Data can stay in Sydney or Melbourne: without pretending we are locally incorporated.
AiRAT is headquartered in Jaipur, India. For Australian estates we enforce residency through architecture: ap-southeast-2 and ap-southeast-4 for primary storage, snapshots, replay and DR, with controlled offshore engineering access.
- AEST/AEDT business-hours overlap
- ap-southeast-2 (Sydney) and ap-southeast-4 (Melbourne)
- APP 8 cross-border disclosure reviewed in migration design, not confused with a blanket localisation rule
Am I affected?
Three questions decide how urgent this is for you.
Which version are you on?
Run GET / against your cluster, or check the footer of Kibana.
Anything starting 7. or lower is already unsupported. Anything starting 8. has a dated deadline.
Are you self-hosted or on Elastic Cloud?
Self-hosted means you own the upgrade. Cloud means Elastic will eventually force it.
Self-hosted clusters on end-of-life versions are the higher risk: no automatic upgrade, and no patched release when the next CVE lands.
Do you use App Search or Workplace Search?
Check for an App Search engine or Workplace Search content source in Kibana.
These are part of Elastic Enterprise Search, which is retired. There is no newer version to upgrade into. This one requires a re-platform, not an upgrade.
Pick your situation
The same end-of-life date means three very different problems.
Search is broken, or about to be
Magento and Adobe Commerce carry Elasticsearch as a hard dependency, and the supported version matrix moves with each release. Stores running an end-of-life cluster hit indexing failures, blank result pages, and a version matrix that blocks the next platform upgrade. If you use App Search for site search, the product is retired.
- Version matrix mapped against your Commerce release
- Cutover with search live throughout
- OpenSearch or Elastic 9.x, whichever your licence and budget favour
An unsupported cluster carrying production logs
An end-of-life cluster means the next Elasticsearch CVE arrives with no patched upgrade path. Add the 2021 SSPL licence change and re-platforming downstream may be contractually blocked as well as technically hard. Index-format gaps compound it: 8.x cannot read 6.x-era indices directly.
- Dual-write migration window, no read-path downtime
- SSPL exposure resolved where licensing is the blocker
- Index format and mapping gaps handled explicitly
The ingest bill grows faster than the coverage
Per-GB pricing punishes telemetry sprawl, and most of that volume is never queried. An end-of-life platform is the moment to fix ingest, because migrating your full noisy volume onto a new platform costs more and risks more than migrating a right-sized stream.
- Ingest audited against actual detection-rule usage
- Noise cut before the platform changes
- Every detection rule replayed before cutover
Proof
We have done both halves of this: the version wall and the bill.
Migrating off end-of-life Elasticsearch without losing detection coverage
- Zero detection rules lost across cutover
- SSPL → Apache 2.0 licensing risk eliminated
- 6-week dual-write migration window
A Tier-1 bank on self-hosted Elasticsearch 6.x, blocked by the SSPL change from re-platforming downstream, facing the wall that 8.x cannot read 6.x-era indices. Seven independently-running log services unified onto OpenSearch.
Read the case study →Cutting a Splunk bill by half without losing a single detection
- 58% ingest reduction before any platform change
- SIEM spend cut by more than half
- Zero detection coverage lost
Ingest audited against real query and detection-rule usage, noise filtered upstream at the collector layer, and only then a migration, of a smaller, higher-signal stream.
Read the case study →Scoped engagement
Start with a version audit, not a migration proposal.
A fixed-scope review that tells you what you are running, what breaks, and what the migration would actually involve. You get the findings whether or not you engage us for the work.
- Current version, index format, and licence position documented
- Compatibility matrix against your application or detection stack
- Named risks with dates attached, not a generic risk register
- Migration options costed: OpenSearch, Elastic 9.x, or managed service
- A cutover sequence with the rollback path written down
For Australian estates we can keep data in ap-southeast-2 (Sydney) or ap-southeast-4 (Melbourne) throughout, your logs never leave the country.
Common questions
When did Elasticsearch 7.17 reach end of support?
Elasticsearch, Kibana, Logstash, Beats and APM Server 7.17.x reached End of Maintenance on 15 April 2025 and End of Support on 15 January 2026. Any version earlier than 7.17 is also unsupported. Source: Elastic's Product End of Life Policy at elastic.co/support/eol.
When does Elasticsearch 8.x reach end of life?
Elastic Stack 8.x reaches End of Maintenance on 15 January 2027 and End of Support on 15 July 2027. Maintenance ending means no further bug fixes, performance improvements or security patches for the 8.x series, so the practical planning date is January 2027, not July.
What happened to Elastic Enterprise Search, App Search and Workplace Search?
Elastic Enterprise Search 8.x has been retired. Elastic issued the Software Product Retirement Notice on 15 April 2025, meaning no further major releases will be produced. End of Maintenance is 15 January 2027 and End of Support is 15 July 2027. Because there is no successor version, App Search and Workplace Search users need to move to an alternative such as OpenSearch or native Elasticsearch queries. This is a re-platform, not an upgrade.
Should we move to OpenSearch or upgrade to Elastic 9.x?
It depends on which problem is binding. If licensing is the blocker, for example you need to embed or resell search under a permissive licence, OpenSearch's Apache 2.0 licence resolves it and Elastic's SSPL does not. If you rely on Elastic-specific commercial features, upgrading to 9.x is usually less work. If per-GB or per-node cost is the driver, the answer often depends more on right-sizing ingest than on which platform you land on.
Can you migrate without downtime on search?
Yes, using a dual-write window: both clusters receive writes while reads stay on the old cluster, indices are backfilled and verified, then reads cut over and the old cluster is retired. On our Tier-1 bank migration this ran for six weeks and every detection rule was replayed against the new cluster before cutover, with zero rules lost.
Why can't we just upgrade in place from 6.x or 7.x to the latest version?
Elasticsearch supports upgrading across one major version at a time, and index formats do not carry forward indefinitely; 8.x cannot read 6.x-era indices directly. That means older estates need either a stepped upgrade path or a reindex, which is why an end-of-life jump is usually a migration project rather than a package update.
Can Australian data stay in Australia during the migration?
Yes. AWS operates Asia Pacific (Sydney) as ap-southeast-2 and Asia Pacific (Melbourne) as ap-southeast-4, and both OpenSearch and self-managed Elasticsearch can be deployed entirely within them. We design the migration so data does not leave the jurisdiction, which matters where APP 8 cross-border disclosure obligations apply.