# Upgrade to 9x preparation: migrate watches

**URL:** https://discuss.elastic.co/t/upgrade-to-9x-preparation-migrate-watches/384793
**Category:** Elasticsearch
**Created:** [January 29, 2026, 12:24pm UTC](https://discuss.elastic.co/t/upgrade-to-9x-preparation-migrate-watches/384793 "2026-01-29T12:24:11Z")
**Posts on this page:** 2
**Page:** 1

<div class="post-metadata">

### Author: ![CD9820](https://avatars.discourse-cdn.com/v4/letter/c/e9c0ed/32.png) [@CD9820](https://discuss.elastic.co/u/CD9820)
#### Post date: [January 29, 2026, 12:24pm UTC](https://discuss.elastic.co/t/upgrade-to-9x-preparation-migrate-watches/384793/1 "2026-01-29T12:24:11Z")

</div>

Hello

I am going through the upgrade assistant on my QA cluster in preparation for the upgrade from 8.19.4 to 9.2.x  
The assistant marks the following index as critical block for the upgrade:

.reindexed-v7-watches-6

The index effectively contains all my watches config. There is an alias ".watches" that is linked to this index.  
The assistant does not provide an option to reindex this index. I tried to manually reindex it to ".watches" but this does not work (system managed index issue).  
Then I tried to reindex the index to a "normal" new index. Redirecting the .watches alias does not work either (.watches is a reserved system name).  
I eventually backupped the json content and deleted the .reindexed-v7-watches-6 and recreated all my watches based on the backupped json content.  
This is ok for a few watches. My production environment contains 97 watches, also in the .reindexed-v7-watches-6 index. Is there a way to migrate the watches in bulk to a correct .watches index? Manually recreating 97 watches is a bit much.

Best regards  
Christophe

---

<div class="post-metadata">

### Author: ![Keith\_Massey](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/keith_massey/32/83666_2.png) [@Keith\_Massey](https://discuss.elastic.co/u/Keith_Massey)
#### Post date: [January 29, 2026, 3:10pm UTC](https://discuss.elastic.co/t/upgrade-to-9x-preparation-migrate-watches/384793/2 "2026-01-29T15:10:21Z")

</div>

We’re not sure how this situation happens yet, but we’ve seen this at least once before. That customer manually reindexed `.reindexed-v7-watches-6` into a new index index named `.watches-reindexed-for-9` and set the `.watches` alias to the new index. Then they deleted the `.reindexed-v7-watches-6` index.
