Upgrading Elastic from 8.x to 9.x: order and pitfalls

Elastic 9.0 has been available since 15 April 2025, and since 29 July we also have 9.1 and 8.19, the last version of the 8.x line. Many companies still run 8.x and are right not to rush, but a major version change has a few rules worth knowing before you plan a maintenance window. Below we describe how we approach it in self-managed clusters and what we pay attention to. On Elastic Cloud Hosted and Enterprise the platform performs the upgrade itself, in the right order.

The path: 8.19 first

The rule from Elastic’s documentation is simple. You reach 9.0.x from 8.18.x, because 8.18 and 9.0 were released together. To reach 9.1 and later you must first be on 8.19.x. In practice, whatever the target, you first upgrade to the latest 8.19 patch and only then to 9.x. It is worth doing even if you already run some 8.19 version, because the Upgrade Assistant (described below) is part of that version and fixes to it arrive in later patches.

There is one more rule that catches people out with patch releases: you can only upgrade to a version released after your current one. You cannot go from 9.0.5 to 9.1.0, because 9.1.0 came out before 9.0.5. You have to wait for 9.1.1 or later.

The order of components

The documentation gives this order:

1. Elasticsearch,
2. Kibana (at the same version as Elasticsearch),
3. Fleet Server and Elastic APM, if you use them,
4. Elastic Agent, Beats, Logstash and client libraries.

Elasticsearch supports rolling upgrades, node by node, so a cluster with replicas spread over several nodes stays available. Kibana needs downtime: all its instances must be stopped for the upgrade. Add to the maintenance plan a separate monitoring cluster (if you have one), which you upgrade before the production one, and remote clusters used in cross-cluster search, which the documentation says to upgrade first.

Elastic Agent, Beats and Logstash at version 8.19 work with all 9.x versions of Elasticsearch. 8.x client libraries use REST API compatibility mode by default. So you do not have to switch all agents in one window and can upgrade them in later stages, at a pace that suits the team.

Upgrade Assistant and indices from version 7.x

This is the most important preparation step, and the one you must not skip. The Upgrade Assistant is a page in Kibana that collects warnings about deprecated settings from three sources: the Elasticsearch deprecation info API, its deprecation logs and the Kibana deprecations API. We run it on the latest 8.19 patch.

For many clusters one issue is decisive. Indices created in version 7.x or earlier are not compatible with 9.x. Before the upgrade you have to reindex them, delete them or archive them (mark them read-only), and Elasticsearch nodes will not start if such indices remain. The Upgrade Assistant can reindex old indices or mark them as archived. There is a warning for applications too: after reindexing, index names may change, so check alerts, transforms and any code that refers to them. In 9.x you can also use the archive functionality, which gives read access to snapshots of 7.x indices without reindexing.

Breaking changes we would look at first

Before the upgrade, read the whole list of breaking changes for Elasticsearch 9.0 and Kibana. From that list we picked the points that can surprise you in a typical company environment:

• TLS protocols: TLSv1.1 was removed from the default settings, and with JDK 24 the TLS_RSA cipher suites are no longer supported. Older systems that connect to the cluster (old scripts, devices, client applications) may stop connecting, so check which protocols they use.
• LDAP and Active Directory authentication: configuring a bind DN without a password in an LDAP or AD realm stops the node from starting.
• Frozen indices: the ability to read frozen indices is gone, and so is the unfreeze endpoint. Before the upgrade, check whether any of your indices are frozen.
• Timeouts: Elasticsearch now returns status 429 instead of 5xx for some timeouts, which matters to clients that handle those codes differently.
• Names in deprecation logs: the keyword and the index template of the deprecation logs were renamed, so rules and dashboards that rely on them need a fix.
• Machine learning: on macOS x86_64 machine learning features are disabled. That is rare in production, but it affects labs and test machines.

Upgrading to 9.1 adds one change for AWS: the snapshot repository plugin repository-s3 and the discovery plugin discovery-ec2 moved to AWS SDK v2. The documentation advises testing the new version before upgrading production, because the SDKs are not fully compatible.

LogsDB will not switch on by itself for old data streams

In Elasticsearch 9.0, new log data streams whose names match the logs-*-* pattern get the LogsDB index mode, which makes logs take up less space (in Elastic’s benchmarks up to 60 percent less, with a small drop in indexing performance; the result depends on the data). After an upgrade from 8.x, existing data streams, including those created by integrations, are not switched automatically. According to the documentation, new logs-*-* data streams get LogsDB in a cluster upgraded from 8.x only if the cluster had no existing data streams with such names at the time of the upgrade, so it is worth checking after the upgrade. Enabling it is a change in the index template (for integrations, in the @custom component template). Saving space on logs is a real part of the return on an upgrade, so we add this step to the plan.

What our plan looks like

1. Inventory: versions, 7.x indices, integrations, plugins, client libraries, TLS connections.
2. A cluster snapshot. Once the upgrade starts you cannot go back to the previous version of a node, and recovery is possible only from a snapshot taken beforehand.
3. Upgrade to the latest 8.19 patch, run the Upgrade Assistant, fix critical issues.
4. A rehearsal on a test environment that mirrors production: templates, ILM, alerts, dashboards, authentication, performance.
5. Production upgrade in the order from the documentation, followed by checks of alerts, machine learning jobs and data collection.
6. Only then optional changes, such as LogsDB on old data streams or the features from 9.1.

When not to rush

If the cluster runs stably on 8.19, the version is still supported and you do not need anything from 9.x, there is no reason to upgrade in a hurry. It is sensible to set a date and prepare the cluster (Upgrade Assistant, 7.x indices) rather than wait until the version approaches the end of support. What you gain afterwards is described in our article on LOOKUP JOIN in ES|QL.

We carry out upgrades and cluster reviews as part of our Elastic deployment and maintenance.