elastic · jmikell821 · Mar 24, 2025 · Mar 24, 2025 · Mar 24, 2025
@@ -42,5 +42,6 @@ After you're done upgrading, upgrade your ingest components in the following ord
 . {ls}: {logstash-ref}/upgrading-logstash.html[upgrade instructions]
 . {beats}: {beats-ref}/upgrading.html[upgrade instructions]
 . {agent}: {fleet-guide}/upgrade-elastic-agent.html[upgrade instructions]
-. {apm-agent}s: {observability-guide}/apm-upgrade.html[upgrade instructions]
+. {apm-agents-ref}/index.html[{apm-agent}s]
+. Custom clients
 
@@ -140,4 +140,5 @@ Next, upgrade your ingest components in the following order:
 . {ls}: {logstash-ref}/upgrading-logstash.html[upgrade instructions]
 . {beats}: {beats-ref}/upgrading.html[upgrade instructions]
 . {agent}: {fleet-guide}/upgrade-elastic-agent.html[upgrade instructions]
-. {apm-agent}s: {observability-guide}/apm-upgrade.html[upgrade instructions]
+. {apm-agents-ref}/index.html[{apm-agent}s]
+. Custom clients
@@ -111,4 +111,5 @@ Once you have upgraded from 8.18, you need to update your ingest components in t
 . {ls}: {logstash-ref}/upgrading-logstash.html[upgrade instructions]
 . {beats}: {beats-ref}/upgrading.html[upgrade instructions]
 . {agent}: {fleet-guide}/upgrade-elastic-agent.html[upgrade instructions]
-. {apm-agent}s: {observability-guide}/apm-upgrade.html[upgrade instructions]
+. {apm-agents-ref}/index.html[{apm-agent}s]
+. Custom clients
@@ -1,28 +1,24 @@
 [[upgrading-elastic-stack-on-prem]]
 == Upgrade Elastic on self-managed infrastructure 
 
-When you are <<upgrading-elastic-stack, prepared to upgrade>>,
+Once you're <<upgrading-elastic-stack, prepared to upgrade>>,
 you will need to upgrade each of your Elastic components individually.
 
-. Consider closing {ml} jobs before you start the upgrade process. While {ml}
-jobs can continue to run during a rolling upgrade, it increases the overhead
-on the cluster during the upgrade process.
-
-. Upgrade the components of your {stack} in this order:
-+
+Upgrade the components of your {stack} in this order:
 
 //.. {es} Hadoop: {hadoop-ref}/install.html[install instructions]
-.. {es}: <<upgrading-elasticsearch, upgrade instructions>>
-.. {kib}: <<upgrading-kibana, upgrade instructions>>
+. {es}: <<upgrading-elasticsearch, upgrade instructions>>
+. {kib}: <<upgrading-kibana, upgrade instructions>>
 //.. Java API Client: {java-api-client}/installation.html#maven[dependency configuration]
-.. {ls}: {logstash-ref}/upgrading-logstash.html[upgrade instructions] (See note below)
-.. {beats}: {beats-ref}/upgrading.html[upgrade instructions]
-.. {agent}: {fleet-guide}/upgrade-elastic-agent.html[upgrade instructions]
-.. {apm-agent}s {observability-guide}/apm-upgrade.html[upgrade instructions]
+. {ls}: {logstash-ref}/upgrading-logstash.html[upgrade instructions] (See note below)
+. {beats}: {beats-ref}/upgrading.html[upgrade instructions]
+. {agent}: {fleet-guide}/upgrade-elastic-agent.html[upgrade instructions]
+. {apm-agents-ref}/index.html[{apm-agent}s]
+. Custom clients
 
 [NOTE]
 --
 If you are using {ls} and the {logstash-ref}/plugins-filters-elastic_integration.html[`logstash-filter-elastic_integration`] plugin to extend Elastic integrations, upgrade {ls} (or the `logstash-filter-elastic_integration` plugin specifically) _before_ you upgrade {kib}.
 
-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`).  
+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`).  
 --
@@ -76,7 +76,7 @@ If you’re running the {stack} on your own self-managed infrastructure, you’l
 
 Before you upgrade to {version}, it's important to take some preparation steps. Unless noted, these following recommendations are best practices regardless of deployment method. 
 
-IMPORTANT: 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.
+IMPORTANT: Upgrading from a release candidate build, such as 9.0.0-rc1, is not supported. Pre-releases should only be used for testing in a temporary environment.
 
 To upgrade to {version} from 8.17 or earlier, **you must first upgrade to the latest patch version of 8.18**. This enables you to use the **Upgrade Assistant** to identify and resolve issues,
 reindex indices created before 8.0, and then perform a rolling upgrade.
@@ -87,7 +87,7 @@ even if you opt to do a full-cluster restart of your {es} cluster.*
 Alternatively, you can create a new {version} deployment and reindex from remote.
 For more information, refer to <<upgrading-reindex,Reindex to upgrade>>.
 
-{beats} and {ls} 8.17 are compatible with {es} {version} 
+{beats} and {ls} 8.18 are compatible with {es} {version} 
 to give you flexibility in scheduling the upgrade.
 
 .Remote cluster compatibility
@@ -130,6 +130,9 @@ For more information, see {ref}/rest-api-compatibility.html[REST API compatibili
 IMPORTANT: You cannot downgrade {es} nodes after upgrading. If you cannot complete the upgrade process, you will need to {ref}/snapshots-restore-snapshot.html[restore from the snapshot].
 +
 . If you use a separate {ref}/monitoring-production.html[monitoring cluster], you should upgrade the monitoring cluster before the production cluster. In general, the monitoring cluster and the clusters being monitored should be running the same version of the stack. A monitoring cluster cannot monitor production clusters running newer versions of the stack. If necessary, the monitoring cluster can monitor production clusters running the latest release of the previous major version.
+. To reduce overhead on the cluster during the upgrade, close {ml} jobs. Although {ml} jobs can run during a rolling upgrade, doing so increases the cluster workload.
+. If you have `.ml-anomalies-*` anomaly detection result indices created in Elasticsearch 7.x, reindex, mark as read-only, or delete them before you upgrade to 9.0.0. For more information, refer to <<anomaly-detection-results-migration, Migrate anomaly detection results>>.
+. If you have transform destination indices created in Elasticsearch 7.x, reset, reindex, or delete them before you upgrade to 9.0.0. For more information, refer to <<breaking_90_transform_destination_index, Migrate transform destination indices>>.
 
 [discrete]
 [[anomaly-detection-results-migration]]
@@ -464,7 +467,7 @@ The {transform} destination indices created in {es} 7.x must be either reset, re
 
 **Reindexing**: You can reindex the destination index and then update the {transform} to write to the new destination index. This is useful if there are results that you want to retain that may not exist in the source index. To prevent the {transform} and reindex tasks from conflicting with one another, you can either pause the {transform} while the reindex runs, or you can write to the new destination index while the reindex backfills old results.
 
-**Deleting**: You can delete any {transform} that are no longer being used. Once the {transform} is deleted, you can either delete the destination index or make it read-only.
+**Deleting**: You can delete any {transforms} that are no longer being used. Once the {transform} is deleted, you can either delete the destination index or make it read-only.
 
 .Which indices require attention?
 [%collapsible]