End of support for Elastic 8.x in 2027: an upgrade schedule
Maintenance of the 8.x series ends on 15 January 2027. We build an upgrade schedule backwards from that date and show how to choose the 9.x target version.
Elastic publishes its support dates well in advance, but in practice most companies start thinking about them only when an auditor or a supplier sends a reminder. If your cluster runs on 8.x, you have today (the end of March 2026) just under ten months before maintenance ends. That is plenty for a small cluster and little for an environment where old data has to be reindexed, integrations tested and a maintenance window fitted around the business calendar. Below we build a schedule backwards from the right date. We described the upgrade itself earlier in Upgrading Elastic from 8.x to 9.x: order and pitfalls.
What the support policy says
According to the Elastic support policy page the dates are as follows:
| Version | End of maintenance (EOM) | End of support (EOS) |
|---|---|---|
| 7.17.x | 15 April 2025 | 15 January 2026 |
| 8.x (8.0 to 8.19) | 15 January 2027 | 15 July 2027 |
| 9.x (series) | 15 October 2027 | no date on the page |
Maintenance means fixes, including security fixes. Support is further technical help for six months after maintenance ends. The policy also gives a general rule: each major release is maintained for the longer of two periods, 30 months from release or 18 months from the release of the next major version. Another rule applies to minor releases: maintenance covers the two most recent minor releases of the current major version and the final minor release of the previous major version. In the table 9.x has one date for the whole series, but in a contract and an operations plan read both rules. Versions 8.17 and 8.18 have separate exceptions: 8.17 was maintained until the release of 8.19, and 8.18 until the release of 9.2.
The practical conclusion is that 7.17 is already out of support, and an 8.x cluster will stop receiving security fixes on 15 January 2027. For companies subject to regulation (finance, healthcare, essential and important entities under NIS2), the lack of security fixes in the system that stores logs and incident data is an audit matter, not only an IT one.
Which 9.x version to choose
Today (March 2026) the newest release is 9.3, published on 3 February. When choosing the target we consider three things.
- The path. To reach 9.1 and later you must start from 8.19.x, so whatever the target, the first step is 8.19.
- Breaking changes on the way. The newer the target, the more notes you have to read, because the documentation asks you to review the changes for every release up to the target version. Besides the 9.0 changes (TLS, Enterprise Search, names in the deprecation logs) and 9.1 (AWS SDK v2), two later sets are worth knowing. In 9.2 the Simulate API returns a 400 error for invalid processors, norms are no longer enabled for
textfields in LogsDB and TSDB indices, andexclude_source_vectorsis enabled by default for new indices. In 9.3 keyword fields with normalised values use native synthetic_source, and cross-cluster functionality is disabled for_fleet/_fleet_searchand_fleet/_fleet_msearch. - The features you need. If the aim of the upgrade is to save space on logs, look at the
pattern_textfield (GA since 9.3), which we describe in the article on Elastic 9.3. If there is no specific need, choose the latest patch of a release that already has a few fixes behind it, rather than the first release of a new minor version.
A schedule counting back from 15 January 2027
For a typical production cluster with several terabytes of data we propose the following split. It is a draft to adapt, not a standard.
| Period | Task |
|---|---|
| April 2026 | Inventory: versions, 7.x indices, integrations, plugins, client libraries, TLS connections, use of Enterprise Search |
| May and June 2026 | Upgrade to the latest 8.19.x, Upgrade Assistant, reindexing or archiving 7.x indices |
| July and August 2026 | Test cluster from a snapshot copy, the whole path end to end, tests of alerts, dashboards, ML jobs and data collection |
| September 2026 | Decision on the target version, maintenance window plan, rollback plan |
| October 2026 | Upgrade of non-production environments, then production |
| November and December 2026 | Reserve for fixes and a change freeze over the holiday period |
Reindexing old data usually takes the longest. The Elastic documentation says that indices created in 7.x must be reindexed, deleted or archived before an upgrade to 9.x, and that in 9.x archiving lets you read 7.x snapshots without reindexing. If you plan to archive, decide early, because it affects your retention plan.
The first week of work
You do not need a maintenance window to start. A few hours of an administrator’s time is enough: list the versions of all nodes, Kibana, Fleet Server and agents, run the Upgrade Assistant on the current version, check the list of indices created before version 8.0, and establish who in the company uses features that disappear or change in 9.x. The result tells you whether you will fit the schedule, or whether it needs to be shortened or you should ask for outside help.
Elastic Cloud and clusters on your own infrastructure
If you use Elastic Cloud, the platform carries out the upgrade in the right order, but your part remains: 7.x indices, integrations, templates, client libraries and alert rules. On your own infrastructure you are also responsible for the order of components, operating systems, plugins and snapshot repositories. For clusters on AWS there is a change from 9.1: the repository-s3 and discovery-ec2 plugins use AWS SDK v2, so you need to set the region of the repositories and use IMDSv2.
What to avoid
- Waiting for the last quarter. December is a freeze period, and fixes in case of trouble will be needed when everyone is on leave.
- Skipping the intermediate 8.19 version.
- Upgrading production without a rehearsal on a copy restored from a snapshot.
- Leaving the cluster on 8.x “because it works”. It works until the day a security fix is needed that does not exist.
How we can help
We start with a review of the cluster: versions, the Upgrade Assistant result, the list of indices to reindex, integrations and client libraries. On that basis we give you a schedule and a quote. We carry out upgrades as part of Elastic deployment and maintenance.
