Merging feedback and updating a few links

Author: jmikell821

deploy-manage/upgrade.md

@@ -1,8 +1,10 @@
 # Upgrade
 
-Upgrading to the latest version provides you access to Elastic latest features, enhancements, performance improvements, and bug fixes, many of which enable you to save your organization money, respond faster to potential threats, and improve the tools you use to investigate and analyze your data. As new versions are released, older versions reach their end of life at a regular cadence, so it’s important to ensure that your deployment is fully maintained and supported. For more information, refer to Elastic’s [Product End of Life Dates](https://www.elastic.co/support/eol).
+Upgrading to the latest version provides access to the newest Elastic features, enhancements, performance improvements, and bug fixes. These updates reduce costs, speed up threat response, and improve investigative and analytical data tools. 
+
+When Elastic releases new versions, older versions reach their end of life on a set schedule. To keep your deployment supported, stay up to date. For more information, refer to [Product End of Life Dates](https://www.elastic.co/support/eol).
 
 :::{note}
-Upgrading from a release candidate build, such as 9.0.0-rc1 or 9.0.0-rc2, is not supported. Pre-releases should only be used for testing in a temporary environment.
+Upgrading from a release candidate build, such as 9.0.0-rc1, is unsupported. Use pre-releases only for testing in a temporary environment.
 :::
 

deploy-manage/upgrade/deployment-or-cluster.md

@@ -8,7 +8,7 @@ applies_to:
 
 An {{es}} cluster can be upgraded one node at a time so upgrading does not interrupt service. Running multiple versions of {{es}} in the same cluster beyond the duration of an upgrade is not supported, as shards cannot be replicated from upgraded nodes to nodes running the older version.
 
-Before you start, [take the upgrade preparation steps](../../../deploy-manage/upgrade/prepare-to-upgrade.md). When performing a [rolling upgrade](../../../deploy-manage/upgrade/deployment-or-cluster.md#rolling-upgrades):
+Before you start, [take the upgrade preparation steps](../../../deploy-manage/upgrade/prepare-to-upgrade.md). When performing a [rolling upgrade](#rolling-upgrades):
 
 1. Upgrade the data nodes first, tier-by-tier, starting with the frozen tier, then the cold tier, then the warm tier, then the hot tier, and finally any other data nodes which are not in a tier. Complete the upgrade for all nodes in each data tier before moving to the next. This ensures {{ilm-init}} can continue to move data through the tiers during the upgrade. You can get the list of nodes in a specific tier with a `GET /_nodes` request, for example: `GET /_nodes/data_frozen:true/_none`.
 2. Upgrade all remaining nodes that are neither master-eligible nor data nodes. This includes dedicated ML nodes, dedicated ingest nodes, and dedicated coordinating nodes.

deploy-manage/upgrade/deployment-or-cluster/elasticsearch.md

@@ -1,9 +1,15 @@
+---
+navigation_title: "Roll back to a previous version"
+mapped_urls:
+  - https://www.elastic.co/guide/en/kibana/current/upgrade-migrations-rolling-back.html
+---
+
 # Roll back to a previous version of {{kib}} [upgrade-migrations-rolling-back]
 
-If you’ve followed [preparing for migration](/deploy-manage/upgrade/deployment-or-cluster/kibana.md#preventing-migration-failures) and [resolving migration failures](../../../troubleshoot/kibana/migration-failures.md), and {{kib}} is still unable to successfully upgrade, rollback {{kib}} until you’re able to identify and fix the root cause.
+If you’ve followed [preparing for migration](/deploy-manage/upgrade/deployment-or-cluster/kibana.md#preventing-migration-failures) and [resolving migration failures](../../../troubleshoot/kibana/migration-failures.md), and {{kib}} is still unable to successfully upgrade, roll back {{kib}} until you identify and fix the root cause.
 
 ::::{warning} 
-Before you roll back {{kib}}, ensure that the version you want to roll back to is compatible with your {{es}} cluster. If the version you want to roll back to is not compatible, you must also rollback {{es}}. Any changes made after an upgrade are lost when you roll back to a previous version.
+Before you roll back {{kib}}, ensure that the version you want to roll back to is compatible with your {{es}} cluster. If the version you want to roll back to is not compatible, you must also roll back {{es}}. Any changes made after an upgrade are lost when you roll back to a previous version.
 ::::
 
 
@@ -14,7 +20,7 @@ To roll back after a failed upgrade migration, you must also roll back the {{kib
 
 1. Before proceeding, [take a snapshot](../../tools/snapshot-and-restore/create-snapshots.md) that contains the `kibana` feature state. By default, snapshots include the `kibana` feature state.
 2. To make sure no {{kib}} instances are performing an upgrade migration, shut down all {{kib}} instances.
-3. [Restore](../../tools/snapshot-and-restore/restore-snapshot.md) the `kibana` feature state from a snapshot taken before the failed {{kib}} upgrade. The following {{es}} request will only restore the {{kib}} feature state
+3. [Restore](../../tools/snapshot-and-restore/restore-snapshot.md) the `kibana` feature state from a snapshot taken before the failed {{kib}} upgrade. The following {{es}} request will only restore the {{kib}} feature state:
 
     ```console
     POST _snapshot/my_repository/my_snapshot_2099.05.06/_restore
@@ -24,7 +30,7 @@ To roll back after a failed upgrade migration, you must also roll back the {{kib
     }
     ```
 
-    1. Exclude all indices and data streams from the restore operation to ensure that only the {{kib}} system indices included in the {{kib}} feature state will be restored.
+    1. Exclude all indices and data streams from the restore operation to ensure that only the {{kib}} system indices included in the {{kib}} feature state are restored.
 
-4. Start all {{kib}} instances on the older version you want to rollback to.
+4. Start all {{kib}} instances on the older version you want to roll back to.
 

deploy-manage/upgrade/deployment-or-cluster/kibana-roll-back.md

@@ -20,13 +20,13 @@ For more information, refer to [Migrate saved objects](../internal-upgrade-proce
 
 When upgrading several {{kib}} instances connected to the same {{es}} cluster, ensure that all outdated instances are shut down before starting the upgrade.
 
-Rolling upgrades are unsupported in {{kib}}. However, when outdated instances are shut down, you can start all upgraded instances in parallel, which allows all instances to participate in the upgrade migration in parallel.
+Rolling upgrades are unsupported in {{kib}}. However, when outdated instances are shut down, you can start all upgraded instances in parallel, which allows all instances to participate in the upgrade in parallel.
 
-For large deployments with more than 10 {{kib}} instances, and more than 10,000 saved objects, you can reduce the upgrade downtime by bringing up a single {{kib}} instance and waiting for it to complete the upgrade migration before bringing up the remaining instances.
+For large deployments with more than 10 {{kib}} instances, and more than 10,000 saved objects, you can reduce the upgrade downtime by bringing up a single {{kib}} instance and waiting for it to complete the upgrade before bringing up the remaining instances.
 
-## Preparing for migration [preventing-migration-failures]
+## Preparing for upgrading [preventing-migration-failures]
 
-Before you start, ensure you [take the upgrade preparation steps](../prepare-to-upgrade.md). Then, take these extra steps to ensure you are ready for migration.
+Before you start, ensure you [take the upgrade preparation steps](../prepare-to-upgrade.md). Then, take these extra steps to ensure you are ready to upgrade.
 
 
 ### Ensure your {{es}} cluster is healthy [_ensure_your_es_cluster_is_healthy]
@@ -44,7 +44,7 @@ A healthy cluster has:
 
 ### Ensure that all {{kib}} instances are the same [_ensure_that_all_kib_instances_are_the_same]
 
-When you perform an upgrade migration of different {{kib}} versions, the migration can fail. Ensure that all {{kib}} instances are running the same version, configuration, and plugins.
+When you perform an upgrade of different {{kib}} versions, the upgrade can fail. Ensure that all {{kib}} instances are running the same version, configuration, and plugins.
 
 ## Perform the upgrade [perform-kibana-upgrade]
 

deploy-manage/upgrade/deployment-or-cluster/kibana.md

@@ -1,6 +1,6 @@
 # Upgrade Elastic on self-managed infrastructure
 
-If you've installed the {{stack}} on your own self-managed infrastructure, once you're [prepare to upgrade](/deploy-manage/upgrade/deployment-or-cluster.md#prepare-to-upgrade), you'll need to upgrade each of your Elastic components individually. 
+If you've installed the {{stack}} on your own self-managed infrastructure, once you're [prepared to upgrade](/deploy-manage/upgrade/deployment-or-cluster.md#prepare-to-upgrade), you'll need to upgrade each of your Elastic components individually. 
 
 It's important that you upgrade your components in this order: 
 * [{{es}}](/deploy-manage/upgrade/deployment-or-cluster/elasticsearch.md)
@@ -9,6 +9,6 @@ It's important that you upgrade your components in this order:
 * [Ingest components](/deploy-manage/upgrade/ingest-components.md)
 
 :::{important}
-If you are using {{ls}} and the `logstash-filter-elastic_integration plugin` to extend Elastic integrations, upgrade Logstash (or the `logstash-filter-elastic_integration` plugin specifically) *before* you upgrade Kibana.
+If you're using {{ls}} and the `logstash-filter-elastic_integration plugin` to extend Elastic integrations, upgrade {{ls}} (or the `logstash-filter-elastic_integration` plugin specifically) *before* you upgrade {{kib}}.
 
-The Elasticsearch-Logstash-Kibana installation order for this specific plugin ensures the best experience with Elastic Agent-managed pipelines, and embeds functionality from a version of {{es}} Ingest Node that is compatible with the plugin version (`major.minor`).
+The {{es}} → {{ls}} → {{kib}} installation order for this specific plugin ensures the best experience with {{agent}}-managed pipelines, and embeds functionality from a version of {{es}} Ingest Node that is compatible with the plugin version (`major.minor`).

deploy-manage/upgrade/deployment-or-cluster/self-managed.md

@@ -6,7 +6,7 @@ navigation_title: "Upgrade on {{ech}}"
 
 Once you are [prepared to upgrade](../../../deploy-manage/upgrade/deployment-or-cluster.md), a single click in the {{ecloud}} console can upgrade a deployment to a newer version, add more processing capacity, change plugins, and enable or disable high availability, all at the same time. During the upgrade process, {{es}}, {{kib}}, and all of your deployment components are upgraded simultaneously.
 
-Minor version upgrades, upgrades from 8.18 to 9.x, and cluster configuration changes can be performed with no downtime. {{ecloud}} only supports upgrades to released versions. Release candidate builds and master snapshots are not supported.
+Minor version upgrades, upgrades from 8.18 to 9.0, and cluster configuration changes can be performed with no downtime. {{ecloud}} only supports upgrades to released versions. Release candidate builds and master snapshots are not supported.
 
 ::::{important} 
 Although it’s simple to upgrade an {{ecloud}} deployment, the new version might include breaking changes that affect your application. Ensure you review breaking changes and deprecation logs, make any necessary changes, and test against the new version before upgrading your production deployment.

deploy-manage/upgrade/deployment-or-cluster/upgrade-on-ech.md

@@ -4,7 +4,7 @@
 The topics in this section apply to customers running the {{stack}} on {{ece}} (ECE) or {{eck}} (ECK). 
 :::
 
-Elastic provides customers with two major self-managed orchestrators to manage the Elastic Stack. Before you can upgrade the products in the stack, you need to ensure your orchestrator is running a compatible version. If you’re running a version of your orchestrator that’s incompatible with the Elastic Stack version you’re upgrading to, you’ll need to upgrade the orchestrator first. 
+Elastic provides customers with two major self-managed orchestrators to manage the {{stack}}. Before upgrading the products in the stack, ensure your orchestrator is running a compatible version. If you’re running a version of your orchestrator that’s incompatible with the {{stack}} version you’re upgrading to, upgrade the orchestrator first. 
 
 Refer to one of these topics, depending on which orchestrator you have: 
 

deploy-manage/upgrade/orchestrator.md

@@ -10,15 +10,15 @@ There are a number of things you need to plan for before performing the actual u
 
 Ensure the version you’re upgrading to for {{es}}, {{kib}}, and any ingest components supports your current operating system. Refer to the [Product and Operating System support matrix](https://www.elastic.co/support/matrix#matrix_os). 
 
-**OpenJDK compatibility and FIPS compliance**
+### OpenJDK compatibility and FIPS compliance
 
 By default, {{es}} is built using Java and includes a bundled version of [OpenJDK](https://openjdk.java.net/) within each distribution. While we strongly recommend using the bundled Java Virtual Machine (JVM) in all installations of {{es}}, if you choose to use your own JVM, ensure it’s compatible by reviewing the [Product and JVM support matrix](https://www.elastic.co/support/matrix#matrix_jvm). {{es}} 9.0 requires Java 21 and supports Java 24. 
 
 If you’re running {{es}} in FIPS 140-2 mode, {{es}} 9.0 has been tested with [Bouncy Castle's](https://www.bouncycastle.org/java.html) FIPS implementation and is the recommended Java security provider when running {{es}}. 
 
 ## Conduct a component inventory
 
-It is very important to map all the components that are being used on the {{stack}}. When you upgrade your deployment, you also may need to upgrade all the other components. You should record if each component is used, and if it is, also record the current version. While not comprehensive, here’s a list of components you should check: 
+It is very important to map all the components that are being used on the {{stack}}. When you upgrade your deployment, you also may need to upgrade all the other components. You should record whether each component is used, and if it is, also record the current version. While not comprehensive, here’s a list of components you should check: 
 
 * {{es}}
 * {{es}} Hadoop
@@ -77,7 +77,7 @@ Self-managed infrastructure – either on-prem or on public cloud, includes:
 * {{ece}} (ECE)
 * {{eck}} (ECK)
 
-For ECE and ECK, you must ensure the operator is running a compatible version with the {{stack}} version you’re upgrading to. If not, you need to upgrade that before you can upgrade your cluster. 
+For ECE and ECK, ensure the operator is running a version compatible with the {{stack}} version you’re upgrading to. If not, you need to upgrade that before you can upgrade your cluster. 
 
 If you’re running the {{stack}} on your own self-managed infrastructure, you must upgrade each component individually.