# Transferring a writable index from one cluster to another

**URL:** <https://discuss.elastic.co/t/transferring-a-writable-index-from-one-cluster-to-another/337934>\
**Category:** Elasticsearch\
**Created:** [July 8, 2023, 9:49am UTC](https://discuss.elastic.co/t/transferring-a-writable-index-from-one-cluster-to-another/337934 "2023-07-08T09:49:27Z")\
**Posts on this page:** 1\
**Showing post:** 14

<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:** [July 11, 2023, 7:09am UTC](https://discuss.elastic.co/t/transferring-a-writable-index-from-one-cluster-to-another/337934/14 "2023-07-11T07:09:22Z")

</div>

> [@Aditya\_Teltia](#):
>
> Now based on these can you think of some good approach for the same.

As I said earlier I do not think it is possible to move an index that is receiving updates/deletes from one cluster to another without data loss, inconsistencies and/or unavailability, at least using snapshot and restore.

The only way I can see to achieve this with a minimum amount of downtime is to use [cross-cluster replication](https://www.elastic.co/guide/en/elasticsearch/reference/8.8/xpack-ccr.html) (CCR), which is a commercial feature.

With CCR you would create a follower index in the destination cluster and then wait until it has caught up with writes/updates/deletes on the main source index. At that point you can temporarily stop indexing, stop replication and make the follower index writable. You can the start indexing into the new index and delete the one in the source cluster. As the index already is up to date this would ensure consistency with likely only a small amount of downtime.

---

_[View the full topic](https://discuss.elastic.co/t/transferring-a-writable-index-from-one-cluster-to-another/337934)._