BlogElasticsearch

Elasticsearch 7 End of Life: EOL Dates for 7.17, 8.x and 9.x

Scott Sternloff

By Scott Sternloff, Senior Enterprise Architect

LinkedIn · Updated · 7 min read

Elasticsearch 7 End of Life: EOL Dates for 7.17, 8.x and 9.x
On this page

Elasticsearch 7.17, the last 7.x line, passed its end of maintenance on 15 April 2025 and its end of support on 15 January 2026, and anything older than 7.17 is unsupported. Elasticsearch 8.x is maintained until 15 January 2027 and supported until 15 July 2027. Elasticsearch 9.x is maintained until 15 October 2027 or later. Elastic ships security fixes only for versions inside maintenance, so a 7.x cluster no longer receives them.

The dates below come from Elastic's Product and Version End of Life Policy, checked on 12 October 2026. At that date the newest releases are 9.5.5 and 8.19.23, and the same dates apply to Kibana, Logstash, Elastic Agent and Beats in the same line.

Elastic's end of life policy, in its own words

Elastic maintains each major release for the longer of 30 months from general availability or 18 months from the general availability of the next major. Within that window it maintains the two most recent minors of the current major and the final minor of the previous one. Support then runs for six months after maintenance ends. The distinction matters: the policy says Elastic is not obligated to fix anything in a release outside its maintenance term, even while it is still answering support tickets, and may tell you to upgrade.

Elasticsearch end of life dates by version

Release seriesEnd of maintenanceEnd of supportStatus on 12 October 2026
9.x15 October 2027, or 18 months after 10.0 if laterSix months after end of maintenanceSupported (9.5.5 is current)
8.x15 January 202715 July 2027Maintained, 8.19 only
7.1715 April 202515 January 2026End of life (7.17.29 was the last release)
Older than 7.17, including 7.10.2EndedEndedUnsupported

Source: Elastic Product and Version End of Life Policy. Elastic's footnote ends 8.17 maintenance when 8.19 shipped and 8.18 maintenance when 9.2 shipped. Both have shipped, so inside 8.x only 8.19 is still maintained. If you are on 8.17 or 8.18, you are already outside maintenance while the 8.x calendar still looks safe.

Licensing history: why many clusters stayed on 7.10.2

Elasticsearch was Apache 2.0 licensed up to 7.10.2. With 7.11 in February 2021 Elastic moved the source to SSPL and the Elastic License, and its licensing FAQ says it no longer produces an Apache 2.0 distribution. In September 2024 it added the OSI-approved AGPLv3 as a third source-code option, a change the FAQ expected before 8.16 became generally available; the default distribution stays under the Elastic License 2.0. OpenSearch is the fork: its FAQ describes OpenSearch as derived from Elasticsearch 7.10.2, the last Apache 2.0 release, and released entirely under Apache 2.0. For a side-by-side, see OpenSearch vs Elasticsearch.

Why leaving Elasticsearch 7 is harder than a normal upgrade

Elastic's 7.17 upgrade guide requires two major upgrades: 7.17 to 8.19, then 8.19 to 9.x, because 9.1 and later can only be reached from 8.19. Beats, Logstash and Elastic Agent must be on the current line before each step, and client libraries move after it. Four details cause most of the delay:

  • Old indices. An 8.0 node will not start with indices created before 7.0, and indices created in 7.x or earlier must be reindexed, deleted or archived as read-only before 9.x. The Upgrade Assistant helps, but reindexing terabytes is a project.
  • Mapping types are gone. 8.0 removed the REST endpoints that contain a mapping type, which breaks older clients and scripts.
  • Security. On 7.x, security features are off by default for Basic licences. An 8.x node configures TLS and a generated elastic password on first start, so anything that assumed plain HTTP without credentials needs rework.
  • Two jumps, two test cycles. Each major needs its own rehearsal, and ECK and ECE have version requirements of their own.
# which indices were created on which version (6xxxxxx means a 6.x index)
curl -s 'localhost:9200/_all/_settings/index.version.created?pretty'
# the deprecation report the Upgrade Assistant is built on
curl -s 'localhost:9200/_migration/deprecations?pretty'
# node versions
curl -s 'localhost:9200/_cat/nodes?h=name,version'

For simple search workloads without Kibana dashboards, machine learning or alerting, Elastic's guide also allows building a new 9.x cluster and migrating the data instead. Our write-up of what breaks in a multi-version Elasticsearch upgrade covers the stalls we see.

What running an unsupported Elasticsearch version risks

  • Security fixes ship elsewhere. In December 2025 Elastic published ESA-2025-27 (CVE-2025-37731, PKI realm user impersonation, CVSS 6.8) and ESA-2025-33 (CVE-2025-68384, a low-privileged user crashing a node with oversized user settings, CVSS 6.5). Both list all 7.x versions as affected, and both are fixed only in 8.19 and 9.x. They are medium severity; the point is where fixes are delivered.
  • Security may be off. It is off by default on 7.x Basic licences, so a 7.x cluster nobody configured has no authentication and no patches.
  • Elastic support has ended. For 7.17 that date was 15 January 2026.
  • Audits flag it, and every release you fall behind lengthens the upgrade path.

The incidents that show up on older Elasticsearch clusters

  • Disk fills and indices go read-only. At the flood-stage watermark, 95% by default, Elasticsearch blocks writes to every index with a shard on the full node. The block lifts automatically once usage drops below the high watermark, but writes were rejected in the meantime.
  • Heap pressure. Elastic recommends acting when a node's JVM memory usage consistently exceeds 85%, because high usage can trigger circuit breaker errors. See heap pressure support.
  • A cluster stuck yellow. A node leaves and replica shards stay unassigned; if a primary had no replica, the cluster goes red. See yellow state remediation.
  • An upgrade that stalls on old indices, usually discovered after the maintenance window has been booked.

None of these is caused by end of life. What end of life changes is that a server fix, if one is needed, will only ever ship in a version you are not running.

Your options for Elasticsearch past end of life

  • Keep the version you run, and keep it patched. OSSeva, AceMQ's extended support platform, provides patched builds of self-managed Elasticsearch 7.10.2 and 7.17 after Elastic stops fixing them, and backports to 8.19 once Elastic ends 8.x maintenance on 15 January 2027. Staying on 7.10.2 also keeps you on the last Apache 2.0 release. Artifacts ship as packages and container images with signatures and SBOMs, so deployment does not change.
  • Upgrade through 8.19 to 9.x, or build a new 9.x cluster and migrate data. Start the index audit first; it decides the schedule.
  • Move to OpenSearch. Apache 2.0 and forked from 7.10.2, but OpenSearch's FAQ says it uses indices from Elasticsearch 6.0 to 7.10 and that later indices must be reindexed first. See OpenSearch support options.
  • Use a managed service and its calendar. Elastic Cloud follows Elastic's terms. Amazon OpenSearch Service, whose last Elasticsearch engine version is 7.10, lists standard support for 7.10 until 7 November 2027 and Extended Support, at a surcharge, until 7 November 2030.
  • Put an operations team behind it. AceMQ provides 24/7 Elasticsearch support on any version, past end of life included, with a senior engineer on a live call within 15 minutes at P1, and plans the upgrade with you. For how vendor and independent cover compare, see Elasticsearch support options.

Start with an inventory: record version.number from GET / on every cluster, the oldest index.version.created, and the version of every Beats, Logstash and client library that talks to it. For the other technologies AceMQ and OSSeva cover past end of life, see end-of-life software support.

Running Elasticsearch 7.x or approaching the 8.x dates? AceMQ keeps clusters patched and covered past Elastic's end of life while you plan the upgrade. See Elasticsearch extended support, or send us your version and node count for a written quote.

Sources

Frequently Asked Questions

When did Elasticsearch 7 reach end of life?

Elasticsearch 7.17, the last 7.x line, reached end of maintenance on 15 April 2025 and end of support on 15 January 2026, according to Elastic's end of life policy. Elastic lists nothing older than 7.17, so earlier 7.x versions, including 7.10.2, are unsupported.

When does Elasticsearch 8 reach end of life?

The 8.x series reaches end of maintenance on 15 January 2027 and end of support on 15 July 2027. 8.19 is the final 8.x minor release and the only 8.x minor still maintained.

Can I get security patches for Elasticsearch 7.10.2 or 7.17 after end of life?

Not from Elastic. For self-managed clusters, OSSeva, AceMQ's extended support platform, provides patched builds of Elasticsearch 7.10.2 and 7.17 and plans to backport fixes to 8.19 after Elastic ends 8.x maintenance on 15 January 2027.

Can I upgrade from Elasticsearch 7.17 straight to 9.x?

No. Elastic's guide requires two major upgrades, 7.17 to 8.19 and then 8.19 to 9.x, with indices created in 7.x or earlier reindexed, deleted or archived as read-only before the 9.x step. For simple use cases you can instead build a new 9.x cluster and migrate the data.

Is Elasticsearch still open source?

Elasticsearch was Apache 2.0 licensed up to 7.10.2. From 7.11 it was dual licensed under SSPL and the Elastic License, and in September 2024 Elastic added the OSI-approved AGPLv3 as a third source-code option. Elastic's default distribution is released under the Elastic License 2.0.

Should I move from Elasticsearch to OpenSearch?

If the licence is why you stayed on 7.10.2, OpenSearch is Apache 2.0 and was forked from that release. If you use features added in Elastic's later releases, 8.19 or 9.x is the path. OpenSearch's own FAQ says it can use indices from Elasticsearch 6.0 to 7.10, so a 7.17 cluster needs a reindex.

Scott Sternloff

Author

Scott SternloffSenior Enterprise Architect

Senior Enterprise Architect at AceMQ. Writes the technical coverage here: RabbitMQ, Kafka and Redis architecture, clustering and migrations.

Talk to an engineer

Need a hand with Elasticsearch?

Senior engineers who run it in production. Get a quote or a free consultation, no sales pitch.

Free Consultation

Get Expert Eyes on Your Elasticsearch Environment

Whether you're troubleshooting a production incident, planning a migration, or want a second opinion on your architecture — our team is ready. No pitch, just answers.

Email Us