Upgrading Elasticsearch 8.19 to 9.x: The 8.19 Stop, 7.x Indices, Breaking Changes, Clients, Rolling Order and Rollback

The short answer

Elastic's end-of-life table ends maintenance for Elasticsearch 8.x on 15 January 2027 and support on 15 July 2027. Maintenance is the part that matters for security: Elastic defines it as releases that fix bugs, improve performance or patch security vulnerabilities. After 15 January 2027, Elastic can still help a supported customer but is not obliged to ship 8.x fixes. The Elasticsearch 8 end-of-life page has the details.

The upgrade guide sets three hard rules for the move to 9.x:

• Start from 8.19. A major upgrade from 8.x must start from 8.19.x, by rolling upgrade or full cluster restart. The one exception is 8.18 to 9.0, but 9.0 is out of maintenance and any 9.1 or later target needs 8.19.
• Deal with 7.x indices first. Indices created in 7.x or earlier must be reindexed, deleted or marked read-only before the upgrade. Nodes fail to start if incompatible indices are present.
• No downgrade. Once the upgrade starts, you cannot downgrade any node. The way back is a snapshot restored into a cluster running the old version.

Release lines and dates

Elastic maintains the two most recent minors of the current major and the final minor of the previous one, which is why 8.19 is the only 8.x line still getting releases. For 9.x, maintenance runs to the later of 15 October 2027 and 18 months after 10.0 ships. The Elasticsearch end-of-life tracker has every line.

Step 1: get to the latest 8.19

If the cluster is on 8.18 or earlier, roll it to the latest 8.19 patch release first. That step is a minor upgrade inside 8.x, and the 8.19 Upgrade Assistant is the tool that prepares the 9.x step. Elastic says 8.19 Elastic Agent, Beats and Logstash work with every 9.x version of Elasticsearch, so bring the ingest tier to 8.19 too. That lets you move it after the cluster rather than in the same window.

Step 2: the Upgrade Assistant and 7.x indices

Elastic's guidance is not to skip the Upgrade Assistant, in Kibana under Stack Management, or GET _migration/deprecations without Kibana. Resolve every critical issue. The one that takes longest on most clusters is indices created in 7.x or earlier. For each, pick one of three routes:

A few index types have their own notes. Machine learning anomaly result indices (.ml-anomalies-*) created in 7.x must be reindexed, made read-only or deleted. Transform destination indices must be reset, reindexed or deleted. Data streams followed through cross-cluster replication cannot be reindexed in place, because older backing indices are no longer replicated, and the guide gives two separate paths for them. In 9.x, archive indices can also give read-only access to 7.x and older data from snapshots without reindexing, with limited query support.

Our recommendation: start with an inventory of index creation versions across every cluster, including remote clusters for cross-cluster search, and put the reindex time in the plan before the upgrade date. On large clusters the reindex is the critical path.

Step 3: the breaking changes in 9.0

Elastic's breaking changes list for 9.0.0 is long. These are the entries most likely to affect a self-managed 8.19 cluster:

Later 9.x minors add their own entries. 9.1.0 moved the discovery-ec2 and repository-s3 plugins to AWS SDK v2, which changes configuration for both; the notes say SDK v2 does not support the EC2 IMDSv1 protocol. 9.4.0 stopped the ILM downsample action force merging by default and disabled sequence numbers for time series indices. Read every entry between 9.0 and your target minor, not only 9.0.

Java

Elastic strongly recommends the bundled JVM. If you bring your own through ES_JAVA_HOME, the minimum moves: the build files set a minimum runtime of Java 17 for 8.19 and Java 21 for 9.x. 9.0.0 bundles JDK 24 and 9.5.4 bundles JDK 26. A cluster that pins an external Java 17 has to move it, and plugins and custom scripts that run inside the node have to work on the newer JVM. The 9.0 notes also drop TLS_RSA cipher support on JDK 24, so check older TLS clients.

Clients and REST compatibility

Elastic says 8.x clients work with 9.x through REST API compatibility. A request sends Accept: application/vnd.elasticsearch+json;compatible-with=8, or the official clients add it everywhere when ELASTIC_CLIENT_APIVERSIONING=true. Compatibility covers one major version only, and Elastic calls it a bridge rather than a long-term strategy. Each request it rescues writes an entry with the compatible_api category to the deprecation log, which gives you the list of calls still to fix.

Our recommendation: turn compatibility headers on for every client before the cluster upgrade, upgrade the cluster, then move applications to the 9.x clients over the following weeks, using the deprecation log to track what is left. Any client still talking 7.x formats through the 8.x compatibility layer has to be fixed before the upgrade, because 9.x does not accept them.

Step 4: the rolling upgrade

Elastic's rolling upgrade order for self-managed clusters:

1. Data nodes, tier by tier: frozen, cold, warm, hot, then any data nodes outside a tier.
2. Other nodes that are neither master-eligible nor data nodes: machine learning, ingest, coordinating, transform and remote cluster client nodes.
3. Master-eligible and voting-only nodes last.

On each node: optionally set cluster.routing.allocation.enable to primaries, stop indexing and flush, and put machine learning into upgrade mode. Then stop the node, install the new version, merge configuration changes, upgrade every plugin, start the node and check it joins. Reset allocation, wait for green and move to the next node.

Two warnings from the guide. A mixed-version cluster is supported only for the duration of the upgrade, because shards cannot replicate from upgraded nodes to older ones; you will see replica allocation refused with a message saying the node is older than the primary. And do not start a rolling upgrade unless you can finish it on every node. If you cannot keep that promise, a full cluster restart with planned downtime is the alternative.

Before the first node moves: take a snapshot, upgrade any separate monitoring cluster first, and upgrade remote clusters before the cluster that searches them.

Kibana and the rest of the stack

The order is Elasticsearch, then Kibana, then Fleet Server and APM, then Beats, Elastic Agent, Logstash and client libraries. Elastic says Kibana must be kept aligned with the Elasticsearch version, so schedule its upgrade straight after the last Elasticsearch node, in the same window. The installation guide says to use the same version across the whole stack.

Snapshots and restore

Snapshots taken on 8.0 to 8.19 restore on 9.x. Indices from 7.x snapshots can be restored on 9.x only as archive indices or searchable snapshots. Nothing restores to an older version: a snapshot taken on 9.x cannot be restored on 8.19. Take a snapshot on 8.19 immediately before the upgrade, and check that it restores into a test cluster on 8.19.

Test plan

• Restore a production snapshot into a staging cluster on 8.19 and run the whole upgrade there.
• Run representative queries before and after and compare hit counts and top results, especially for analysers listed in the 9.0 changes.
• Exercise every client with compatibility headers on, then with the 9.x client.
• Check ingest pipelines, ILM policies, transforms, watches and machine learning jobs.
• Confirm LDAP, Active Directory, SAML or PKI authentication and TLS from every client type.
• Check dashboards and alerts that key on HTTP status codes, now that timeouts return 429.
• Restart a node under load during the staging roll and confirm the cluster returns to green.

Rollback

Elastic is clear that you cannot downgrade a node once the upgrade has started. During the roll, the safe course is to finish it. After the roll, going back means building or keeping an 8.19 cluster and restoring the pre-upgrade snapshot, which loses every write since. If you need a faster way back, our recommendation is a blue-green upgrade: restore the 8.19 snapshot into a new cluster, upgrade that one, and dual-write or replay ingestion until you cut over, keeping the old cluster as the fallback.

If you cannot upgrade yet

Large reindex jobs, a client that cannot be retested, or an appliance that embeds Elasticsearch can push the 9.x move past 15 January 2027. Elastic's maintenance ends then; OSSeva backports security fixes to self-managed 8.19 after that date, on the Patch, Assure and Operate tiers. Patch covers backported security fixes for Elasticsearch and its bundled libraries, bundled JDK updates, packages and container images, signed artifacts with SBOMs, and advisory notifications. Assure adds a security and network exposure review, a reindex and client plan and a SOC 2 and PCI DSS evidence pack. Operate adds 24/7 cluster health monitoring, a 15-minute P1 response and engineers who run the 9.x upgrade or a migration to OpenSearch. See Elasticsearch support, the OpenSearch end-of-life dates, Elasticsearch vulnerabilities by version and, for clusters still on 7.x, Elasticsearch 7.17 upgrade options.

Common questions

Can I upgrade Elasticsearch 8.17 or 8.18 straight to 9.x?

Only 8.18 to 9.0 is allowed, and 9.0 is no longer maintained. For 9.1 or later, upgrade to the latest 8.19 first.

Do I have to reindex every 7.x index?

No. Indices created in 7.x can be reindexed, deleted or marked read-only. Read-only 7.x indices stay usable in 9.x.

Will my 8.x clients work against 9.x?

Yes, through REST API compatibility, which the official clients turn on with ELASTIC_CLIENT_APIVERSIONING=true. It covers one major version and is meant as a bridge.

When does Elasticsearch 8 stop getting fixes?

Elastic ends maintenance on 15 January 2027 and support on 15 July 2027.

Can I downgrade from 9.x to 8.19?

No. Once the upgrade starts you cannot downgrade nodes, and 9.x snapshots do not restore on 8.x. Keep a pre-upgrade snapshot and an 8.19 environment to restore it into.