Obviously it's an upgrade and not a migration because words

_config.yml

@@ -27,7 +27,7 @@ color_scheme: opensearch
 # Define Jekyll collections
 collections:
   # Define a collection named "tests", its documents reside in the "_tests" directory
-  migrate:
+  upgrade-to:
     permalink: /:collection/:path/
     output: true
   opensearch:
@@ -61,8 +61,8 @@ collections:
 just_the_docs:
   # Define the collections used in the theme
   collections:
-    migrate:
+    upgrade-to:
-      name: Migrate to OpenSearch
+      name: Upgrade to OpenSearch
       # nav_exclude: true
       nav_fold: true
       # search_exclude: true

_migrate/index.md

@@ -1,13 +0,0 @@
----
-layout: default
-title: About migrating
-nav_order: 1
-redirect_from: /migrate/
----
-
-# About migrating
-
-The process of migrating from Elasticsearch OSS (including Open Distro for Elasticsearch) to OpenSearch varies depending on your current version of Elasticsearch OSS, install type, tolerance for downtime, and cost-sensitivity. Rather than concrete steps to cover every situation, we have general guidance for the process.
-
-To safeguard against data loss, we recommend that you take a [snapshot]({{site.url}}{{site.baseurl}}/opensearch/snapshot-restore/) of all indices prior to any migration.
-{: .tip }

_upgrade-to/docker-upgrade-to.md

@@ -1,12 +1,14 @@
 ---
 layout: default
-title: Docker migration
+title: Upgrade Docker clusters to OpenSearch
 nav_order: 25
+redirect_from:
+  - /migrate/docker-migrate/
 ---
 
-# Docker migration
+# Upgrade Docker clusters to OpenSearch
 
-If you use a container orchestration system like Kubernetes (or manage your containers manually) and want to avoid downtime, think of the process not as an upgrade of each node, but as a decommissioning and replacement of each node. One by one, add OpenSearch nodes to the cluster and remove Elasticsearch OSS nodes, allowing time for all indices to return to a green status prior to proceeding.
+If you use a container orchestration system like Kubernetes (or manage your containers manually) and want to avoid downtime, think of the process not as an upgrade of each node, but as a decommissioning and replacement of each node. One by one, add OpenSearch nodes to the cluster and remove Elasticsearch OSS nodes, pointing to existing data volumes as necessary and allowing time for all indices to return to a green status prior to proceeding.
 
 If you use Docker Compose, we highly recommend that you perform what amounts to a [cluster restart upgrade]({{site.url}}{{site.baseurl}}/migrate/upgrade-migrate/). Update your cluster configuration with new images, new settings, and new environment variables, and test it. Then stop and start the cluster. This process requires downtime, but takes very few steps and lets you continue to treat the cluster as a single entity that you can reliably deploy and redeploy.
 

_upgrade-to/index.md

@@ -0,0 +1,21 @@
+---
+layout: default
+title: About the process
+nav_order: 1
+redirect_from:
+  - /migrate/
+  - /upgrade-to/
+---
+
+# About the process
+
+The process of upgrading from Elasticsearch OSS (including Open Distro for Elasticsearch) to OpenSearch varies depending on your current version of Elasticsearch OSS, install type, tolerance for downtime, and cost-sensitivity. Rather than concrete steps to cover every situation, we have general guidance for the process.
+
+Three approaches exist:
+
+- Use a snapshot to [migrate your Elasticsearch OSS data]({{site.url}}{{site.baseurl}}/upgrade-to/snapshot-migrate/) to a new OpenSearch cluster.
+- Perform a [rolling upgrade or cluster restart upgrade]({{site.url}}{{site.baseurl}}/upgrade-to/upgrade-to/) on your existing nodes.
+- Replace existing Elasticsearch OSS nodes with new OpenSearch nodes. Node replacement is most popular when upgrading [Docker clusters]({{site.url}}{{site.baseurl}}/upgrade-to/docker-upgrade-to/).
+
+Regardless of your approach, to safeguard against data loss, we recommend that you take a [snapshot]({{site.url}}{{site.baseurl}}/opensearch/snapshot-restore/) of all indices prior to any migration.
+{: .tip }

_upgrade-to/snapshot-migrate.md

@@ -1,10 +1,12 @@
 ---
 layout: default
-title: Snapshot migration
+title: Use snapshots to migrate data
 nav_order: 5
+redirect_from:
+  - /migrate/snapshot-migrate/
 ---
 
-# Snapshot migration
+# Use snapshots to migrate data
 
 One popular approach is to take a [snapshot]({{site.url}}{{site.baseurl}}/opensearch/snapshot-restore/) of your Elasticsearch OSS 6.x or 7.x indices, [create an OpenSearch cluster]({{site.url}}{{site.baseurl}}/opensearch/install/), restore the snapshot on the new cluster, and point your clients to the new host.
 

_upgrade-to/upgrade-to.md

@@ -2,13 +2,15 @@
 layout: default
 title: Upgrade from Elasticsearch OSS to OpenSearch
 nav_order: 15
+redirect_from:
+  - /migrate/upgrade-migrate/
 ---
 
-# Upgrade from Elasticsearch OSS to OpenSearch (Linux)
+# Upgrade from Elasticsearch OSS to OpenSearch
 
-If you want to migrate an existing Elasticsearch OSS cluster to OpenSearch and find the [snapshot approach]({{site.url}}{{site.baseurl}}/migrate/snapshot-migrate/) unappealing, you can upgrade the cluster instead. The first step is to upgrade your Elasticsearch OSS cluster to version 6.x or 7.x.
+If you want to upgrade from an existing Elasticsearch OSS cluster to OpenSearch and find the [snapshot approach]({{site.url}}{{site.baseurl}}/migrate/snapshot-migrate/) unappealing, you can upgrade your existing nodes from Elasticsearch OSS to OpenSearch.
 
-Elasticsearch OSS supports two types of upgrades: rolling and cluster restart.
+If your existing cluster runs an older version of Elasticsearch OSS, the first step is to upgrade to version 6.x or 7.x. Elasticsearch OSS supports two types of upgrades: rolling and cluster restart.
 
 - Rolling upgrades let you shut down one node at a time for minimal disruption of service.
 
@@ -121,7 +123,7 @@ Elasticsearch OSS version | Rolling upgrade path | Cluster restart upgrade path
    sudo systemctl stop elasticsearch.service
    ```
 
-   For tarball installations, find the process ID and kill it.
+   For tarball installations, find the process ID (`ps aux`) and kill it (`kill <pid>`).
 
 1. Upgrade the node (rolling) or all nodes (cluster restart).