Elasticsearch 7.17 Upgrade Options: Elasticsearch 8.19, 9.x or OpenSearch

The short answer

Elastic's end-of-life table puts the end of maintenance for 7.17 at 15 April 2025 and the end of support at 15 January 2026. There are two ways out:

• Stay with Elastic. Upgrade 7.17 to 8.19 with the Upgrade Assistant and a rolling upgrade. 8.x support ends on 15 July 2027, so plan the next hop from 8.19 to 9.x as part of the same programme. Elastic lists the end of maintenance for 9.x as 15 October 2027, with end of support set 18 months after the release of 10.0.
• Move to OpenSearch. OpenSearch forked from Elasticsearch 7.10.2 and is licensed under Apache 2.0. From 7.17 the move is a migration to a new cluster, not an in-place upgrade, and the OpenSearch Migration Assistant is the tool built for it.

Licence terms and existing Elastic subscriptions usually decide between them, and they are covered below. The technical work is comparable: both routes require reindexing old indices, updating every client and testing security.

Route 1: Elasticsearch 8.19, then 9.x

Elastic's guide is explicit: to reach 8.19 from 7.16 or earlier you must first upgrade to 7.17, and to reach 9.x from 7.17 you go through 8.19. Each major upgrade is prepared and executed on its own.

1. Bring the rest of the stack to 7.17. All ingest components and client libraries must be on 7.17.x before the cluster moves to 8.19.
2. Take a snapshot and confirm you can restore it.
3. Run the Upgrade Assistant in Kibana 7.17, or query GET _migration/deprecations. Resolve every critical issue. The main one is indices created before 7.0, which 8.x cannot open; the assistant reindexes them, or you delete them.
4. Set xpack.security.enabled explicitly in elasticsearch.yml (see below).
5. Do the rolling upgrade. One node at a time: disable replica shard allocation, stop the node, install 8.19, start it, re-enable allocation and wait for the cluster to recover before the next node.
6. Upgrade the rest in order: Elasticsearch first, then Kibana, then Fleet Server, APM, Logstash and Beats.
7. For 9.x, repeat on 8.19: upgrade ingest components and clients to 8.19.x, then use the 8.19 Upgrade Assistant to reindex or mark read-only any indices and data streams created before 8.0. Enterprise Search was discontinued in 9.0 and has to be removed before that upgrade.

Breaking changes in 8.0

From Elastic's migration guide for 8.0, the changes that most often break a 7.17 deployment:

Security on an upgraded cluster

On a brand-new 8.x node, Elasticsearch generates TLS certificates, writes the TLS settings and creates an elastic password at first start. The documentation says this auto-configuration is skipped when the node detects it is already part of a cluster, which is the case in a rolling upgrade. So an upgraded cluster gets security switched on without the generated certificates. If your 7.17 cluster ran without security, configure it on 7.17 first and test it there, rather than discovering the change halfway through the roll.

Clients

Elasticsearch 8 offers REST API compatibility for 7.x clients. A client sends Accept: application/vnd.elasticsearch+json;compatible-with=7, or you set ELASTIC_CLIENT_APIVERSIONING=true, and the server tries to honour 7.x request and response formats. It covers one major version only, and the deprecation log entries in the compatible_api category show what still needs changing. Use it to decouple the server upgrade from the client upgrade, then move every application to the 8.x clients and the Java API Client before the 9.x step.

Route 2: OpenSearch

Why a rolling upgrade does not work from 7.17

OpenSearch's index compatibility table lists Lucene 8.11.1 for Elasticsearch 7.17 and Lucene 8.10.1 for OpenSearch 1.2 and 1.3. A 7.17 index is written in a newer Lucene format than any OpenSearch 1.x release can read, so there is no in-place path. The OpenSearch documentation also states that snapshots are only forward compatible by one major version. Treat the move as a migration to a new cluster.

How to migrate

OpenSearch documents four methods: rolling upgrade, snapshot and restore, remote reindex and Migration Assistant. For a 7.17 source, the practical choices are:

• Migration Assistant. Its support matrix lists Elasticsearch 5.x to 7.x as sources for OpenSearch 1.x, 2.x and 3.x targets. It migrates metadata, backfills documents by reading shard data from a snapshot in object storage (reindex-from-snapshot), and can capture and replay live writes through a proxy for a near-zero-downtime cutover. It runs on Kubernetes and needs its own infrastructure.
• Remote reindex. The new OpenSearch cluster pulls documents from 7.17 over HTTP. It needs no extra platform, but it is slower and loads the source cluster.

Target OpenSearch 2.x or 3.x. OpenSearch 1.x reached end of life on 6 May 2025 and cannot read 7.17 indices anyway.

What changes for applications

• Clients. From 7.14, several of Elastic's official clients run a product check before the first request and refuse to talk to a server that is not Elasticsearch. Applications have to move to the OpenSearch clients.
• Security. X-Pack security configuration does not carry over. Users, roles and role mappings are rebuilt in the OpenSearch Security plugin.
• Dashboards and Elastic features. Kibana becomes OpenSearch Dashboards. Saved objects, alerting rules, machine learning jobs and other Elastic-specific features have OpenSearch counterparts that work differently, and each one has to be recreated and tested.
• Ingest. Check Logstash and Beats versions against the OpenSearch tools compatibility matrices.

Licences

If you are on 7.17 you already run under SSPL or the Elastic License, so staying with Elastic changes nothing about your licence position, and AGPL becomes available on 8.16 and later. The licence question matters most for teams that ship Elasticsearch inside a product or offer it as a service. Ask your legal team which of the three licences, if any, fits that use before choosing Route 1. Paid features in the Elastic distribution depend on your subscription level, so check that every feature you use is covered at the level you hold.

Test plan

• Restore a production snapshot into staging and run the full route there, timing each phase.
• Replay a sample of real queries against old and new clusters and compare hit counts and top results. Scoring and analyzer behaviour can shift between major versions, and between Elasticsearch and OpenSearch.
• Test every client against the new cluster with security enabled, including batch jobs and anything that still uses the transport client or typed endpoints.
• Test ingest pipelines and date-heavy mappings with real documents, since date format parsing changed in 8.0.
• Check snapshot and restore on the new cluster before you depend on it.
• Load test indexing and query throughput at peak rates. JVM and heap behaviour differ across releases.
• Rehearse cutover and rollback, including how clients are repointed.

Rollback

A rolling upgrade from 7.17 to 8.19 has no node-by-node undo. Indices written by 8.x cannot be read by 7.17, so the way back is the snapshot you took before the upgrade, restored into a 7.17 cluster, plus whatever writes happened since. Keep that snapshot and the 7.17 packages until the new cluster has run through a full business cycle.

The OpenSearch route is easier to reverse because the source cluster is never changed. Rollback means pointing clients back at 7.17. If you use Migration Assistant's capture and replay, keep the source receiving writes until you are confident in the target.

If 7.17 has to keep running

Reindexing petabytes, rewriting clients and rebuilding security takes longer than most teams expect, and some products embed Elasticsearch so deeply that only the vendor can move them. OSSeva ships patched Elasticsearch 7.10.2 and 7.17 builds with security fixes backported to Elasticsearch and its bundled libraries, plus bundled JDK updates, as signed packages and container images with SBOMs. Assure adds a security and network exposure review, a reindex and client plan for 8.x or OpenSearch, and VEX attestation for scanner findings. Operate adds 24/7 cluster monitoring, a 15-minute P1 response and executed migrations to 8.x or OpenSearch. See Elasticsearch support and Elasticsearch 7 extended support.

Related

• Elasticsearch end-of-life dates
• OpenSearch end-of-life dates
• Elasticsearch 7.17 end of life
• Elasticsearch 7.10 end of life