# Upgrade from 8 to 9 resolve issues in bulk

**URL:** <https://discuss.elastic.co/t/upgrade-from-8-to-9-resolve-issues-in-bulk/384146>\
**Category:** Elasticsearch\
**Created:** [December 17, 2025, 1:16pm UTC](https://discuss.elastic.co/t/upgrade-from-8-to-9-resolve-issues-in-bulk/384146 "2025-12-17T13:16:35Z")\
**Posts on this page:** 9\
**Page:** 1

<div class="post-metadata">

**Author:** ![Peterro](https://avatars.discourse-cdn.com/v4/letter/p/51bf81/32.png) [@Peterro](https://discuss.elastic.co/u/Peterro)\
**Post date:** [December 17, 2025, 1:16pm UTC](https://discuss.elastic.co/t/upgrade-from-8-to-9-resolve-issues-in-bulk/384146/1 "2025-12-17T13:16:35Z")

</div>

On the path to version 9 from version 7 I am currently on 8.19. Upgrade assistant shows a lot of deprecation issues that needs to be solved first. Mostly older indexes with compatibility version \< 8.0. It is possible to click it one by one to replace index and create alias, but is it possible to do suggested actions in bulk? Or could someone provide an api example how to do that without downtime? Much appreciated! 🙂

---

<div class="post-metadata">

**Author:** ![Christian\_Dahlqvist](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/christian_dahlqvist/32/4617_2.png) [@Christian\_Dahlqvist](https://discuss.elastic.co/u/Christian_Dahlqvist)\
**Post date:** [December 17, 2025, 2:34pm UTC](https://discuss.elastic.co/t/upgrade-from-8-to-9-resolve-issues-in-bulk/384146/3 "2025-12-17T14:34:29Z")

</div>

What is your use case? Are yoiu using time-based indices that generally go read-only as they get old or are you continously updating and/or deleting from your indices?

I believe the upgrade process, whether you let Kibana run this or automate it yourself via the official APIs, involve reindexing data into new indices and then removing the old index before creating an alias. As reindexing works based on a snapshot of the data in the index when it starts, this process can as far as I know not be done without downtime unless some potential data loss (if index is not read-only) is acceptable.

---

<div class="post-metadata">

**Author:** ![Peterro](https://avatars.discourse-cdn.com/v4/letter/p/51bf81/32.png) [@Peterro](https://discuss.elastic.co/u/Peterro)\
**Post date:** [December 17, 2025, 9:24pm UTC](https://discuss.elastic.co/t/upgrade-from-8-to-9-resolve-issues-in-bulk/384146/4 "2025-12-17T21:24:50Z")

</div>

I dont have much experience with elastic and got a one time task to upgrade existing instances. Indices are constantly used although I think can get away with reindexing during the night. Clicking in upgrade assistant seems easy to do, but time consuming. Is there like an api endpoint to execute this action, as I am afraid that I will mess something up when preparing script to create new indices, waiting for tasks, reindexing, deleting etc.

---

<div class="post-metadata">

**Author:** ![RainTown](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/raintown/32/140206_2.png) [@RainTown](https://discuss.elastic.co/u/RainTown)\
**Post date:** [December 17, 2025, 10:28pm UTC](https://discuss.elastic.co/t/upgrade-from-8-to-9-resolve-issues-in-bulk/384146/5 "2025-12-17T22:28:21Z")

</div>

Welcome to the forum ...

> [@Peterro](#):
>
> I dont have much experience with elastic

... but. tbh, thats a bit of problem. N.x to N.y is _usually_ pretty straightforward. But N.x to (N+1).y is a major version upgrade, what to do if the process goes wrong, without having "much experience"? And you are on N.x to (N+2).y, which is even harder.

The "system indices" are handled with the Kibana tool, though you need to "press the button".

For your own indices, it reindexes only what was in the index when the reindexing task started. Yes, there is an [API](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-reindex) to do that re-indexing, so you could script most of it. There's a API way to identify all the indices that are the 7.x version, the kibana UI tells you too obviously. And you need be careful with re-indexing, if you were to be careless you might re-index into a used index-pattern and ... confusion.

How long it all takes depends on your load / hardware / count / size of the indices. And if there is data flowing, you probably need stop it temporarily.

Before doing anything, you should make a full [snapshot](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-snapshot-create), which is also what the Upgrade Advisor tells you.

---

<div class="post-metadata">

**Author:** ![Peterro](https://avatars.discourse-cdn.com/v4/letter/p/51bf81/32.png) [@Peterro](https://discuss.elastic.co/u/Peterro)\
**Post date:** [December 17, 2025, 10:33pm UTC](https://discuss.elastic.co/t/upgrade-from-8-to-9-resolve-issues-in-bulk/384146/6 "2025-12-17T22:33:16Z")

</div>

Thank you for your comments. When I reindex a large index, can I run reindexing again to copy only changes since last reindexing? Will that be faster than initial one?

---

<div class="post-metadata">

**Author:** ![RainTown](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/raintown/32/140206_2.png) [@RainTown](https://discuss.elastic.co/u/RainTown)\
**Post date:** [December 18, 2025, 12:53am UTC](https://discuss.elastic.co/t/upgrade-from-8-to-9-resolve-issues-in-bulk/384146/7 "2025-12-18T00:53:34Z")

</div>

well, it sort of depends.

Do you update existing documents, or delete documents, in the to-be-reindexed indices?

If every doc is just inserted / indexed once, and never modified or deleted, then it's easier. As you can do incremental \_reindex via a flag field.

Also if the data always arrives in purely sequential time order, and you have a field to track that, you can do similar. e.g. often there is a field updated\_at or ingest\_timestamp or similar.

---

<div class="post-metadata">

**Author:** ![Peterro](https://avatars.discourse-cdn.com/v4/letter/p/51bf81/32.png) [@Peterro](https://discuss.elastic.co/u/Peterro)\
**Post date:** [December 18, 2025, 9:58am UTC](https://discuss.elastic.co/t/upgrade-from-8-to-9-resolve-issues-in-bulk/384146/8 "2025-12-18T09:58:02Z")

</div>

This may vary as there are few instances used for different purposes. One is destination for fluentd logs.

If I reindex do I have to worry about policies too or it will work by alias?

Thanks for all the help 🫠

---

<div class="post-metadata">

**Author:** ![RainTown](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/raintown/32/140206_2.png) [@RainTown](https://discuss.elastic.co/u/RainTown)\
**Post date:** [December 18, 2025, 10:13am UTC](https://discuss.elastic.co/t/upgrade-from-8-to-9-resolve-issues-in-bulk/384146/9 "2025-12-18T10:13:57Z")

</div>

I doubt any log use case will overwrite or delete existing individual documents, generally it's just streaming logs into effectively a log bucket.

> [@Peterro](#):
>
> If I reindex do I have to worry about policies too or it will work by alias?

Er, it depends. On the specific policies and alias. You _might_ have a setup where it does not matter, but you might have a setup where it does. You absolutely surely need to check.

The level of difficulty here is really just on how long re-indexing would take. If it's "minutes", just stop the flow. You dont need to re-index then instantly upgrade to 9.x, you can also chip away at the issue one index-pattern at a time.

Also, if you have time based indices, e.g. daily logs in index called myapp-2025-12-17, and they live of say a month, just wait a month. You are on 8.x already, al _new_ indices are already good and dont need reindexing. If you can rollover, then rollover.

---

<div class="post-metadata">

**Author:** ![Peterro](https://avatars.discourse-cdn.com/v4/letter/p/51bf81/32.png) [@Peterro](https://discuss.elastic.co/u/Peterro)\
**Post date:** [December 18, 2025, 10:17am UTC](https://discuss.elastic.co/t/upgrade-from-8-to-9-resolve-issues-in-bulk/384146/10 "2025-12-18T10:17:48Z")

</div>

That wonderful to hear! Just wait and problem will solve itself 🙂 thanks
