# Smooth migration of ES 2.3 cluster to another data center **URL:** \ **Category:** Elasticsearch\ **Tags:** migration\ **Created:** [June 16, 2021, 12:43am UTC](https://discuss.elastic.co/t/smooth-migration-of-es-2-3-cluster-to-another-data-center/276065 "2021-06-16T00:43:40Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![vfiset](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/vfiset/32/40138_2.png) [@vfiset](https://discuss.elastic.co/u/vfiset)\ **Post date:** [June 16, 2021, 12:43am UTC](https://discuss.elastic.co/t/smooth-migration-of-es-2-3-cluster-to-another-data-center/276065/1 "2021-06-16T00:43:40Z")
I have an ES 2.3 cluster of 6 nodes running in a data center holding ~60Gb of data. I wish to find the smoothest migration path with the least downtime possible to move the data over to a similar size cluster running on a public cloud provider. Is it possible to create nodes on the target data center and add them in the existing cluster then remove nodes on the old cluster one by one ? By reading the docs and blogs it seem like it would not work since they are not on the same subnet. Is there a workaroud ? I don't have a shared storage on all nodes on the current cluster and the AWS backup plugin seems bugged on that version. Is there any other path I should consider ? I am also open to a short downtime \< 1-2h if it simplifies thing a lot. Thanks ---
**Author:** ![warkolm](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/warkolm/32/39224_2.png) [@warkolm](https://discuss.elastic.co/u/warkolm)\ **Post date:** [June 16, 2021, 12:44am UTC](https://discuss.elastic.co/t/smooth-migration-of-es-2-3-cluster-to-another-data-center/276065/2 "2021-06-16T00:44:39Z")
Given you are on such an old version, the cleanest approach would be to do a remote reindex into a more current version (latest is 7.13). ---
**Author:** ![vfiset](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/vfiset/32/40138_2.png) [@vfiset](https://discuss.elastic.co/u/vfiset)\ **Post date:** [June 16, 2021, 12:46am UTC](https://discuss.elastic.co/t/smooth-migration-of-es-2-3-cluster-to-another-data-center/276065/3 "2021-06-16T00:46:47Z")
The thing is that developers of the app using this cluster don't have time to handle the code changes for an ES version bump. I am looking for a way to migrate and stay on the same version 😞 ---
**Author:** ![warkolm](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/warkolm/32/39224_2.png) [@warkolm](https://discuss.elastic.co/u/warkolm)\ **Post date:** [June 16, 2021, 12:50am UTC](https://discuss.elastic.co/t/smooth-migration-of-es-2-3-cluster-to-another-data-center/276065/4 "2021-06-16T00:50:12Z")
Ok, well 2.3 was released in 2017, so you're going to struggle no matter what. I don't even know who provides hosting for versions that old anymore. ---
**Author:** ![vfiset](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/vfiset/32/40138_2.png) [@vfiset](https://discuss.elastic.co/u/vfiset)\ **Post date:** [June 16, 2021, 12:55am UTC](https://discuss.elastic.co/t/smooth-migration-of-es-2-3-cluster-to-another-data-center/276065/5 "2021-06-16T00:55:51Z")
Nah it's not a managed ES service. It's a custom deployment on k8s based on a old version of the stable helm chart for ES. The setup is up and have been running in production for another instance of our app for more than a year now. That part does not stress me much. It's the migration of the data for the instance referred in the original post that make me go 🤯 I know this is far from an ideal setup but this what I need to deal with if I want to go forward with the rest... ---
**Author:** ![warkolm](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/warkolm/32/39224_2.png) [@warkolm](https://discuss.elastic.co/u/warkolm)\ **Post date:** [June 16, 2021, 12:58am UTC](https://discuss.elastic.co/t/smooth-migration-of-es-2-3-cluster-to-another-data-center/276065/6 "2021-06-16T00:58:09Z")
Without a snapshot and restore, you can try joining nodes to the cluster and then using allocation filtering to shift things, but you don't have a backup if things go pear shaped. ---
**Author:** ![TheDeveloper](https://avatars.discourse-cdn.com/v4/letter/t/439d5e/32.png) [@TheDeveloper](https://discuss.elastic.co/u/TheDeveloper)\ **Post date:** [June 21, 2021, 5:46am UTC](https://discuss.elastic.co/t/smooth-migration-of-es-2-3-cluster-to-another-data-center/276065/7 "2021-06-21T05:46:28Z")
You could stand up a new cluster and stream documents over using the Scan/Scroll API. I am doing a similar migration and that is the approach we are taking, although we are also upgrading to 7.x in the process. Amazon Elasticsearch still supports 2.3 so that could be an option (although check that all the features you need are supported): [Supported Elasticsearch operations - Amazon Elasticsearch Service](https://docs.aws.amazon.com/elasticsearch-service/latest/developerguide/aes-supported-es-operations.html#es_version_2_3) Ultimately though, at some point you're going to have to bite the bullet and upgrade. Otherwise you will be stuck on a super old version that nobody knows how to maintain. It is a perfectly reasonable case to make to the business that this is necessary work for ongoing stability of your system, even if it does require significant resource to achieve (it's taking us weeks to do, and it's hard). ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [July 19, 2021, 5:46am UTC](https://discuss.elastic.co/t/smooth-migration-of-es-2-3-cluster-to-another-data-center/276065/8 "2021-07-19T05:46:53Z")
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.