# Upgrade adding new nodes of newer version instead of rolling upgrade **URL:** \ **Category:** Elasticsearch\ **Tags:** rollups\ **Created:** [October 5, 2026, 12:23pm UTC](https://discuss.elastic.co/t/upgrade-adding-new-nodes-of-newer-version-instead-of-rolling-upgrade/390839 "2026-10-05T12:23:46Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![carlosmg1](https://avatars.discourse-cdn.com/v4/letter/c/e19adc/32.png) [@carlosmg1](https://discuss.elastic.co/u/carlosmg1)\ **Post date:** [October 5, 2026, 12:23pm UTC](https://discuss.elastic.co/t/upgrade-adding-new-nodes-of-newer-version-instead-of-rolling-upgrade/390839/1 "2026-10-05T12:23:46Z")
Hi, We've done plenty of upgrades of newer version in a cluster with around 40 nodes, upgrading 8.x version. For an upgrade from the 8.x to the 9.x we're analyzing how viable is to add new nodes during the upgrade of 9.x and shutting down old 8.x nodes, instead of doing an upgrade of each individual node at the time. While the documentation states there can't be different version of ES in the same cluster, I understand this is valid during upgrades, the issue is if we're missing any key detail of how to proceed giving that scenery, can you assist? The idea is to add multiple new nodes 9.x at the same time (first all cold, then hot nodes) and after are integrated by type, stop and remove the 8.x nodes, but we don't know before trying to accomplish this how many nodes we should add first, when to remove the old ones (when the cluster is green and the shards are allocated in the new 9.x nodes?) Regards ---
**Author:** ![leandrojmp](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/leandrojmp/32/107231_2.png) [@leandrojmp](https://discuss.elastic.co/u/leandrojmp)\ **Post date:** [October 5, 2026, 1:07pm UTC](https://discuss.elastic.co/t/upgrade-adding-new-nodes-of-newer-version-instead-of-rolling-upgrade/390839/2 "2026-10-05T13:07:10Z")
This can be done, but what is the reason around this approach instead of just upgrade the nodes? To be done in a more safe way you would need to empty each node you want to remove before adding a new one and this will take more time than just upgrading it. ---
**Author:** ![carlosmg1](https://avatars.discourse-cdn.com/v4/letter/c/e19adc/32.png) [@carlosmg1](https://discuss.elastic.co/u/carlosmg1)\ **Post date:** [October 5, 2026, 1:18pm UTC](https://discuss.elastic.co/t/upgrade-adding-new-nodes-of-newer-version-instead-of-rolling-upgrade/390839/3 "2026-10-05T13:18:57Z")
the issue is nodes needs to be changed too (hw specifications and also OS version), so seems cleaner to add the new node as we want it (hw, OS, elastic version) than to create a new node in 8.x to add it and then migrate to 9 regardless. I guess I can share more details of the process, but yes, we know it will take quite a bit of time. When you mean empty the node before remove it... you mean exclude it from the cluster first? so the shards will be created in other nodes available before completely remove it? or you mean migrating the shards in the cluster itself before remove it? ---
**Author:** ![leandrojmp](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/leandrojmp/32/107231_2.png) [@leandrojmp](https://discuss.elastic.co/u/leandrojmp)\ **Post date:** [October 5, 2026, 1:58pm UTC](https://discuss.elastic.co/t/upgrade-adding-new-nodes-of-newer-version-instead-of-rolling-upgrade/390839/4 "2026-10-05T13:58:40Z")
> [@carlosmg1](#): > > the issue is nodes needs to be changed too (hw specifications and also OS version), so seems cleaner to add the new node as we want it (hw, OS, elastic version) than to create a new node in 8.x to add it and then migrate to 9 regardless. Yeah, but it would be safer to add the new nodes on the current version and only upgrade after you replaced all of them. Keep in mind that if a new index is created on a node on version 9 during this process, no shards will be allocated on nodes on version 8. > [@carlosmg1](#): > > When you mean empty the node before remove it... you mean exclude it from the cluster first? Exclude it from allocation, so the shards would be moved out from the node leaving it empty, this is the recommended approach when you want to decommission a node. The documentation is [here](https://www.elastic.co/docs/deploy-manage/maintenance/add-and-remove-elasticsearch-nodes#remove-a-node-from-an-es-cluster). So you could do this node by node following the upgrade order described [here](https://www.elastic.co/docs/deploy-manage/upgrade/deployment-or-cluster/elasticsearch#upgrade-order). ---
**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:** [October 5, 2026, 2:51pm UTC](https://discuss.elastic.co/t/upgrade-adding-new-nodes-of-newer-version-instead-of-rolling-upgrade/390839/5 "2026-10-05T14:51:10Z")
My question isn’t “could this work” - yes, would probably work. But rather why? This isn’t the documented way to do upgrades, so you have to effectively warranty it yourself. Are you that confident you can address any issues you hit? Personally, I’d take the maybe boring but tested, documented and very frequently used upgrade path. Including first upgrading to 8.latest and checking the Migration Assistant. Where / when are you doing that in your process? By the way, what specific 8.x and 9.x versions are you considering here? ---
**Author:** ![elasticforme](https://avatars.discourse-cdn.com/v4/letter/e/f05b48/32.png) [@elasticforme](https://discuss.elastic.co/u/elasticforme)\ **Post date:** [October 5, 2026, 6:23pm UTC](https://discuss.elastic.co/t/upgrade-adding-new-nodes-of-newer-version-instead-of-rolling-upgrade/390839/6 "2026-10-05T18:23:45Z")
I just did this month back. added new hardware (different OS as well) node first make whole cluster bloated. remove all old node. and because many shard was already was in new node removal went faster as well. then upgrade software. ---
**Author:** ![carlosmg1](https://avatars.discourse-cdn.com/v4/letter/c/e19adc/32.png) [@carlosmg1](https://discuss.elastic.co/u/carlosmg1)\ **Post date:** [October 6, 2026, 11:04am UTC](https://discuss.elastic.co/t/upgrade-adding-new-nodes-of-newer-version-instead-of-rolling-upgrade/390839/7 "2026-10-06T11:04:28Z")
THanks for all the responses. Yes after this conversations we're more inclined to change all the nodes from the new HW/OS ones, and then do the upgrade after following the guide as it's more sound and less prone to errors. We're planning right now to move from 8.19.19 (current) to the last version currently available: **[9.5.4](https://www.elastic.co/docs/release-notes/elasticsearch#elasticsearch-9.5.4-release-notes) (but not sure if in the meanwhile there will be a different releases and move to that one instead)**