[Yandex Cloud documentation](../../index.md) > [Yandex Managed Service for OpenSearch](../index.md) > [Step-by-step guides](index.md) > Clusters > Managing cluster hosts > Migrating host groups to a different availability zone

# Migrating Managed Service for OpenSearch cluster host groups to a different availability zone


Managed Service for OpenSearch cluster [host groups](../concepts/host-roles.md) reside in Yandex Cloud [availability zones](../../overview/concepts/geo-scope.md). To move a host group from one availability zone to another:

{% list tabs group=instructions %}

- Management console {#console}

   1. In the [management console](https://console.yandex.cloud), navigate to the folder page.
   1. Navigate to **Managed Service for OpenSearch**.
   1. Locate the cluster you need in the list, click its name, and select the ![host-groups.svg](../../_assets/console-icons/copy-transparent.svg) **Node groups** tab.
   1. In the row with the host group, click ![image](../../_assets/console-icons/ellipsis.svg) and select **Edit**.
   1. In the **Host placement** field, select the target availability zone for the clusters and remove the source zone.
   1. Click **Save**.

{% endlist %}

Repeat the steps to move each host group.

For clusters with hosts residing in the `ru-central1-d` [availability zone](../../overview/concepts/geo-scope.md), local SSD storage is not available if using Intel Cascade Lake.

## Specifics of migration in Yandex Data Transfer {#data-transfer}

If your cluster is used as an [endpoint](../../data-transfer/concepts/index.md#endpoint) when transferring data using Data Transfer:

1. Make sure not all the cluster host groups are located in the `ru-central1-d` availability zone; otherwise, the transfer will not run the way it should. If you are migrating host groups to the `ru-central1-d` availability zone, place at least one group in the `ru-central1-a` or `ru-central1-b` zone. The transfer will select the appropriate zone automatically. If there is a single host group in your cluster, place it in the `ru-central1-a` or `ru-central1-b` zone.

1. If the [transfer type](../../data-transfer/concepts/transfer-lifecycle.md#transfer-types) is **Replication** or **Snapshot and increment**, restart the transfer after adding new host groups and deleting the old ones. This way, it will get data about the cluster's new topology. You do not need to restart **Snapshot** transfers, as information about the new topology is provided automatically upon their activation.

   To restart a transfer, choose one of the two methods:
   
   * [Deactivate](../../data-transfer/operations/transfer.md#deactivate) the transfer and wait for its status to change to **Stopped**. Next, [reactivate](../../data-transfer/operations/transfer.md#activate) the transfer and wait for its status to change to **Replicating**.
   * Update any [setting for the transfer](../../data-transfer/operations/transfer.md#update) or [endpoint](../../data-transfer/operations/endpoint/index.md#update).

For more information, see [Migrating a Data Transfer transfer and endpoints to a different availability zone](../../data-transfer/operations/endpoint/migration-to-an-availability-zone.md).