Saving...

Author: jmikell821

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

@@ -146,10 +146,12 @@ With the exception of serverless, the following recommendations are best practic
     If you use {{ccr}}, a cluster that contains follower indices must run the same or newer (compatible) version as the remote cluster. For more information and to view the version compatibility matrix, refer to [Cross cluster replication](/deploy-manage/tools/cross-cluster-replication.md). You can view your remote clusters from **Stack Management > Remote Clusters**.
     ::::
 
-9. If you have any anomaly detection result indices `.ml-anomalies-*` that were created in {{es}} 7.x, they must be reindexed, marked as read-only, or deleted before upgrading to 9.x. To learn how to do this, refer to [Anomaly detection results migration](prepare-to-upgrade.md#anomaly-migration). 
+9. 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.
 
+10. If you have any anomaly detection result indices `.ml-anomalies-*` that were created in {{es}} 7.x, they must be reindexed, marked as read-only, or deleted before upgrading to 9.x. To learn how to do this, refer to [Anomaly detection results migration](prepare-to-upgrade.md#anomaly-migration). 
 
-10. If you have any transform destination indices that were created in {{es}} 7.x, they must be reset, reindexed, or deleted before upgrading to 9.x. To learn how to do this, refer to [Transform destination indices migration](prepare-to-upgrade.md#transform-migration). 
+
+11. If you have any transform destination indices that were created in {{es}} 7.x, they must be reset, reindexed, or deleted before upgrading to 9.x. To learn how to do this, refer to [Transform destination indices migration](prepare-to-upgrade.md#transform-migration). 
 
 
 ## Reindex to upgrade (optional) [reindex-to-upgrade]

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

@@ -1 +1,14 @@
 # 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. 
+
+It's important that you upgrade your components in this order: 
+* [{{es}}](/deploy-manage/upgrade/deployment-or-cluster/elasticsearch.md)
+* [{{kib}}](/deploy-manage/upgrade/deployment-or-cluster/kibana.md)
+* [Elastic APM](../../../solutions/observability/apps/upgrade.md)
+* [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.
+
+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`).