reindex to upgrade method refined #3491
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
🔍 Preview links for changed docs |
|
@eedugon please reach out to product about this directly. I'd start with #es-core-infra because they own feature states |
shainaraskas
approved these changes
Oct 17, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR refines and scopes a bit the method that we have shared for ages as an alternative to an actual major upgrade: reindex to upgrade.
The method consists of creating a new cluster in the desired major version, and just reindex the data from the old cluster running a much older version.
I believe (and I could be wrong) that this method won't work today for system indices, Kibana data and probably a lot of other features of our stack.
I have proposed to consider this method only for use cases that do not rely heavily on stack features, or when the user just wants to migrate their own application data to the new version.
This PR relates to #3398
@ppf2 , @shainaraskas , I'd like to get your thoughts on that. I discovered this when I was preparing the 7.17 -> 9.x upgrade guide, because we have always suggested in our docs the "reindex to upgrade" as an alternative to a real major upgrade, and when thinking about it I believe it's clearly not that simple and it's not going to work for users that rely heavily on our new Stack Solutions. Those use cases should follow a normal upgrade path and not consider a reindex to upgrade as an alternative approach if they want to keep all their kibana and features data.
cc: @georgewallace , it would also be good if a PM or someone from dev team validates this.