// tag::cloud[]
In order to get the shards assigned we need to call the
<<ilm-migrate-to-data-tiers, migrate to data tiers routing>> API which will
resolve the conflicting routing configurations towards using the standardized
<<data-tiers, data tiers>>. This will also future-proof the system by migrating
the index templates and ILM policies if needed.

**Use {kib}**

//tag::kibana-api-ex[]
. Log in to the {ess-console}[{ecloud} console].
+

. On the **Elasticsearch Service** panel, click the name of your deployment.
+

NOTE: If the name of your deployment is disabled your {kib} instances might be
unhealthy, in which case please contact https://support.elastic.co[Elastic Support].
If your deployment doesn't include {kib}, all you need to do is
{cloud}/ec-access-kibana.html[enable it first].

. Open your deployment's side navigation menu (placed under the Elastic logo in the upper left corner)
and go to **Dev Tools > Console**.
+
[role="screenshot"]
image::images/kibana-console.png[{kib} Console,align="center"]

. First, let's <<ilm-stop,stop>> {ilm}
+
[source,console]
----
POST /_ilm/stop
----
//TEST[skip:stopping ILM requires waiting]
+
The response will look like this:
+
[source,console-result]
------------------------------------------------------------------------------
{
  "acknowledged": true
}
------------------------------------------------------------------------------
// TESTRESPONSE[skip:the result is for illustrating purposes only]

. Wait for {ilm} to stop. Check the status until it returns `STOPPED` as follows:
+
[source,console]
----
GET /_ilm/status
----
+
When {ilm} has successfully stopped the response will look like this:
+
[source,console-result]
------------------------------------------------------------------------------
{
  "operation_mode": "STOPPED"
}
------------------------------------------------------------------------------
// TESTRESPONSE[skip:not waiting for ILM to stop]

. <<ilm-migrate-to-data-tiers, Migrate to data tiers>>
+
[source,console]
----
POST /_ilm/migrate_to_data_tiers
----
//TEST[skip:this can flake as we're not waiting for ILM to stop]
+
The response will look like this:
+
[source,console-result]
------------------------------------------------------------------------------
{
  "dry_run": false,
  "migrated_ilm_policies":["policy_with_allocate_action"], <1>
  "migrated_indices":["warm-index-to-migrate-000001"], <2>
  "migrated_legacy_templates":["a-legacy-template"], <3>
  "migrated_composable_templates":["a-composable-template"], <4>
  "migrated_component_templates":["a-component-template"] <5>
}
------------------------------------------------------------------------------
// TESTRESPONSE[skip:the result is for illustrating purposes only as we're not waiting for ILM to stop]
+
<1> The ILM policies that were updated.
<2> The indices that were migrated to <<tier-preference-allocation-filter,tier preference>> routing.
<3> The legacy index templates that were updated to not contain custom routing settings for the
provided data attribute.
<4> The composable index templates that were updated to not contain custom routing settings for the
provided data attribute.
<5> The component templates that were updated to not contain custom routing settings for the
provided data attribute.

. <<ilm-start,Restart>> {ilm}
+
[source,console]
----
POST /_ilm/start
----
+
The response will look like this:
+
[source,console-result]
------------------------------------------------------------------------------
{
  "acknowledged": true
}
------------------------------------------------------------------------------
// TESTRESPONSE[skip:didn't wait to stop it]

//end::kibana-api-ex[]
// end::cloud[]

// tag::self-managed[]
In order to get the shards assigned we need to make sure the deployment is
using the <<data-tiers,data tiers>> node roles and then call the
<<ilm-migrate-to-data-tiers, migrate to data tiers routing>> API which will
resolve the conflicting routing configurations towards using the standardized
<<data-tiers, data tiers>>. This will also future-proof the system by migrating
the index templates and ILM policies if needed.


. In case your deployment is not yet using <<data-tiers, data tiers>> <<assign-data-tier, assign data nodes>>
to the appropriate data tier.
Configure the appropriate roles for each data node to assign it to one or more
data tiers: `data_hot`, `data_content`, `data_warm`, `data_cold`, or `data_frozen`.
For example, the following setting configures a node to be a data-only
node in the hot and content tiers.
+
[source,yaml]
----
node.roles [ data_hot, data_content ]
----

. <<ilm-stop,Stop>> {ilm}
+
[source,console]
----
POST /_ilm/stop
----
//TEST[skip:stopping ILM requires waiting]

+
The response will look like this:
+
[source,console-result]
------------------------------------------------------------------------------
{
  "acknowledged": true
}
------------------------------------------------------------------------------
// TESTRESPONSE[skip:the result is for illustrating purposes only]

. Wait for {ilm} to stop. Check the status until it returns `STOPPED` as follows:
+
[source,console]
----
GET /_ilm/status
----
+
When {ilm} has successfully stopped the response will look like this:
+
[source,console-result]
------------------------------------------------------------------------------
{
  "operation_mode": "STOPPED"
}
------------------------------------------------------------------------------
// TESTRESPONSE[skip:not waiting for ILM to stop]

. <<ilm-migrate-to-data-tiers, Migrate to data tiers>>
+
[source,console]
----
POST /_ilm/migrate_to_data_tiers
----
//TEST[skip:this can flake as we're not waiting for ILM to stop]

+
The response will look like this:
+
[source,console-result]
------------------------------------------------------------------------------
{
  "dry_run": false,
  "migrated_ilm_policies":["policy_with_allocate_action"], <1>
  "migrated_indices":["warm-index-to-migrate-000001"], <2>
  "migrated_legacy_templates":["a-legacy-template"], <3>
  "migrated_composable_templates":["a-composable-template"], <4>
  "migrated_component_templates":["a-component-template"] <5>
}
------------------------------------------------------------------------------
// TESTRESPONSE[skip:the result is for illustrating purposes only as we're not waiting for ILM to stop]
+
<1> The ILM policies that were updated.
<2> The indices that were migrated to <<tier-preference-allocation-filter,tier preference>> routing.
<3> The legacy index templates that were updated to not contain custom routing settings for the
provided data attribute.
<4> The composable index templates that were updated to not contain custom routing settings for the
provided data attribute.
<5> The component templates that were updated to not contain custom routing settings for the
provided data attribute.

. <<ilm-start,Restart>> {ilm}
+
[source,console]
----
POST /_ilm/start
----
+
The response will look like this:
+
[source,console-result]
------------------------------------------------------------------------------
{
  "acknowledged": true
}
------------------------------------------------------------------------------
// TESTRESPONSE[skip:didn't wait to stop it]

// end::self-managed[]