From 99299f60f8886e8ec34c5440a18d0cfbacf67502 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Edu=20Gonz=C3=A1lez=20de=20la=20Herr=C3=A1n?= <25320357+eedugon@users.noreply.github.com> Date: Wed, 8 Oct 2025 12:42:08 +0200 Subject: [PATCH 01/11] WIP: upgrade from 7.17 guide --- deploy-manage/toc.yml | 1 + .../deployment-or-cluster/upgrade-717-eol.md | 250 ++++++++++++++++++ 2 files changed, 251 insertions(+) create mode 100644 deploy-manage/upgrade/deployment-or-cluster/upgrade-717-eol.md diff --git a/deploy-manage/toc.yml b/deploy-manage/toc.yml index abdae564db..a31c6dba6b 100644 --- a/deploy-manage/toc.yml +++ b/deploy-manage/toc.yml @@ -808,6 +808,7 @@ toc: - file: upgrade/prepare-to-upgrade/upgrade-assistant.md - file: upgrade/deployment-or-cluster.md children: + - file: upgrade/deployment-or-cluster/upgrade-717-eol.md - file: upgrade/deployment-or-cluster/upgrade-on-ech.md - file: upgrade/deployment-or-cluster/upgrade-on-ece.md - file: upgrade/deployment-or-cluster/upgrade-on-eck.md diff --git a/deploy-manage/upgrade/deployment-or-cluster/upgrade-717-eol.md b/deploy-manage/upgrade/deployment-or-cluster/upgrade-717-eol.md new file mode 100644 index 0000000000..3a9bae2277 --- /dev/null +++ b/deploy-manage/upgrade/deployment-or-cluster/upgrade-717-eol.md @@ -0,0 +1,250 @@ +--- +applies_to: + stack: all + serverless: unavailable +--- +# Upgrade from 7.17 to {{version.stack}} + +{{stack}} version 7.17 has a defined end of support date of 15 January 2026, as stated in the [Elastic Product & Version End of Life Policy](https://www.elastic.co/support/eol). This document provides a guided plan to upgrade from 7.17 to the latest {{version.stack}} release. It complements the official upgrade documentation by showing how the different pieces fit together in a complete upgrade exercise. + +% to decide +Wherever possible, this document links to the existing upgrade guides. In some cases, such as upgrades on {{ech}}, we provide more detailed, step-by-step instructions. + +The content applies to all deployment types ({{ech}} (ECH), {{ece}} (ECE), {{eck}} (ECK), and self-managed clusters). Use the tabs to follow the path for your deployment. + +## Overview + +Upgrading from 7.17 to {{version.stack}} requires two major upgrades. Each major upgrade must be prepared and executed independently, although the planning phase can be shared. + +1. **7.17.x → 8.19.x** + This brings the cluster onto the latest supported 8.x release, which is the required intermediate version before upgrading to 9.x. + Before being able to run this upgrade, all ingest components and client libraries must be upgraded to 7.17.x. + +2. **8.19.x → {{version.stack}}** + This completes the upgrade to the latest 9.x release. + Before being able to run this upgrade, all ingest components and client libraries must be upgraded to 8.19.x. + +The following sections describe these phases in detail and point to the relevant documentation for each deployment type. + +Refer to [upgrade paths](/deploy-manage/upgrade.md#upgrade-paths) for more information. + +(TBD: Consider [reindex to upgrade](https://www.elastic.co/docs/deploy-manage/upgrade/prepare-to-upgrade#reindex-to-upgrade)? as an alternative method to move directly to a new 9.x cluster? ) + +## Upgrade planning + +The [planning phase](/deploy-manage/upgrade/plan-upgrade.md) ensures that the upgrade is well understood and can be executed with minimal risk. +It involves defining a clear sequence of actions and assessing the impact on [service availability](/deploy-manage/upgrade.md#availability-during-upgrades) and performance during the upgrade. + +For the 7.17.x → 9.x upgrade path, the main planning outcome is a set of required actions to ensure compatibility across the ecosystem: + +* **Ingest components:** Before upgrading to 8.19.x, ensure that all ingest components ({{beats}}, {{agent}}, {{ls}}, APM) are on version 7.17.x. + Before the 8.19.x → {{version.stack}} upgrade, upgrade all ingest components to 8.19.x. +* **Client libraries:** If you rely on [{{es}} client libraries](/reference/elasticsearch-clients/index.md), make sure to include them in your plan. + Typically, libraries are upgraded to match the final version after the deployment upgrade. +* **ECK:** {applies_to}`eck:` Upgrade ECK from 2.x to 3.x before moving to 9.x. +* **ECE:** {applies_to}`ece:` Upgrade ECE from 3.x to 4.x before moving to 9.x. + +Finally, it is strongly recommended to [test the full upgrade process in a non-production environment](/deploy-manage/upgrade/plan-upgrade.md#test-in-a-non-production-environment) before applying it to production. + +(recommend to perform the entire list of compatibility checks in self-managed clusters?) + +### Planning result examples + +The following examples illustrate what a completed planning phase might look like for different deployment types. Each example describes the initial situation and outlines the overall upgrade plan. + +(TBD: maybe we remove all this section here and we just include it together with the execution steps) + +::::{applies-switch} + +:::{applies-item} ess: +- Ensure all deployments are in 7.17.x (upgrade any older deployment to 7.17.latest) +- Ensure all ingest components are in 7.17.x (upgrade any older component to 7.17.latest) +- Run upgrade assistant to prepare the cluster for the major upgrade to 8.19.x +- Upgrade deployments to latest 8.19.x +- Upgrade all ingest components to 8.19.x +- Run upgrade assistant to prepare the cluster for the major upgrade to 9.x +- Upgrade deployments to {{version.stack}} +- (optional) upgrade all ingest components to {{version.stack}} +::: + +:::{applies-item} ece: +- Ensure all deployments are in 7.17.x (upgrade any older cluster) +- Ensure all ingest components are in 7.17.x (upgrade any older component) +- If ECE runs on 3.x, upgrade ECE to latest 4.x release. + +- Upgrade deployments to latest 8.19.x +- Upgrade all ingest components to 8.19.x + +- Upgrade deployments to {{version.stack}} +- (optional) upgrade all ingest components to {{version.stack}} +::: + + +:::{applies-item} { eck: } +- Ensure all clusters are in 7.17.x (upgrade any older cluster) +- Ensure all ingest components are in 7.17.x (upgrade any older component) +- If ECK runs on 2.x, upgrade ECK to latest 3.x release. + +- Run upgrade assistant to check if the cluster is ready for a major upgrade. +- Upgrade clusters to latest 8.19.x +- Upgrade all ingest components to 8.19.x +- Run upgrade assistant to check if the cluster is ready for a major upgrade. +- Upgrade clusters to latest 9.x +- (optional) Upgrade all ingest components to 9.x +::: + +:::{applies-item} self: +- Ensure all deployments are in 7.17.x (upgrade any older cluster) +- Ensure all ingest components are in 7.17.x (upgrade any older component) + +- Run upgrade assistant to check if the cluster is ready for a major upgrade. +- Upgrade cluster to latest 8.19.x in the following order: {{es}}, {{kib}}, Fleet Server, and Elastic APM (if used) +- Upgrade all ingest components to 8.19.x + +- Run upgrade assistant to check if the cluster is ready for a major upgrade. +- Upgrade cluster to {{version.stack}} in the same order as before +- (optional) upgrade all ingest components to {{version.stack}} +::: + +:::: + +## Upgrade Step 1: 7.17.x → 8.19.x + +draft items for preparations: +- Assess deployment topology (clusters, nodes, orchestrator type) +- Inventory dependencies (plugins, custom ingest pipelines, clients, integrations) +- Run Upgrade Assistant and resolve issues +- Define snapshot/backup and rollback strategy +- Test upgrade steps in a staging environment +- Align with maintenance windows and SLAs + + +### Preparation + +* Index compatibility: upgrade assistant. +- Confirm prerequisites and compatibility +- Validate cluster health and shard allocation +- Review version-specific breaking changes (link to docs) +- Take snapshots / backups + +### Execution +- Upgrade process (tabs for {{ech}}, {{ece}}, {{eck}}, self-managed) +- Rolling vs full-cluster downtime options +- Client compatibility considerations +- Ingest components compatibility considerations. + +CCR / CCS / Remote clusters / ML / Transform indices implications? +Monitoring clusters implications? + +### Validation +- Post-upgrade health checks (cluster status, ingest, search) +- Validate monitoring dashboards and alerts +- Resolve deprecation warnings + +## Upgrade Step 2: 8.19.x → {{version.stack}} + +### Preparation + +* Index compatibility: upgrade assistant. +- Repeat prerequisites and compatibility checks +- Review 9.x breaking changes +- Ensure clients are compatible (REST API compatibility mode, etc.) +- Take snapshots / backups + +### Execution +- Upgrade process (tabs for {{ech}}, {{ece}}, {{eck}}, self-managed) +- Node upgrade order and orchestration +- Upgrade ecosystem components (Beats, Logstash, Elastic Agent, APM, etc.) + +CCR / CCS / Remote clusters / ML / Transform indices implications? +Monitoring clusters implications? + +### Validation +- Post-upgrade cluster validation +- Performance and stability checks +- Review and remove deprecated settings + +## Post-Upgrade Wrap-Up +- Confirm cluster stability over an observation period +- Update operational runbooks and monitoring baselines +- Validate client library upgrades and integrations +- Decommission old snapshots if no longer needed +- Document lessons learned + + \ No newline at end of file From 00244a02bc5c94def957078bcf73a46453a4cad6 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Edu=20Gonz=C3=A1lez=20de=20la=20Herr=C3=A1n?= <25320357+eedugon@users.noreply.github.com> Date: Wed, 15 Oct 2025 21:55:11 +0200 Subject: [PATCH 08/11] intro refined --- .../upgrade/deployment-or-cluster/upgrade-717.md | 8 ++------ 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/deploy-manage/upgrade/deployment-or-cluster/upgrade-717.md b/deploy-manage/upgrade/deployment-or-cluster/upgrade-717.md index 942fc30af1..53be0d78b4 100644 --- a/deploy-manage/upgrade/deployment-or-cluster/upgrade-717.md +++ b/deploy-manage/upgrade/deployment-or-cluster/upgrade-717.md @@ -7,13 +7,9 @@ applies_to: % add enterprise search related comments? -{{stack}} version 7.17 has a defined end of support date of 15 January 2026, as stated in the [Elastic Product & Version End of Life Policy](https://www.elastic.co/support/eol). This document provides a guided plan to upgrade from 7.17 to the latest {{version.stack}} release. It complements the official upgrade documentation by showing how the different pieces fit together in a complete upgrade exercise. +{{stack}} version 7.17 has a defined end of support date of 15 January 2026, as stated in the [Elastic Product & Version End of Life Policy](https://www.elastic.co/support/eol). This document provides a guided plan to upgrade from 7.17 to the latest {{version.stack}} release. It complements the official upgrade documentation by showing how the different pieces fit together in a complete upgrade exercise. -::::{important} -This guide applies only to deployments or clusters running {{es}} version 7.17.x. If you are using an earlier version, first upgrade to the latest 7.17 release before proceeding. -:::: - -The content applies to all deployment types ({{ech}} (ECH), {{ece}} (ECE), {{eck}} (ECK), and self-managed clusters). Use the tabs to follow the path for your deployment. +This guide applies to all deployment types ({{ech}} (ECH), {{ece}} (ECE), {{eck}} (ECK), and self-managed clusters) running {{es}} version **7.17.x**. If you are using an earlier version, upgrade first to the latest 7.17 release before proceeding. ## Overview From 3554a3a9f5bffd2a534053e0c95463d5c594f586 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Edu=20Gonz=C3=A1lez=20de=20la=20Herr=C3=A1n?= <25320357+eedugon@users.noreply.github.com> Date: Fri, 17 Oct 2025 13:30:40 +0200 Subject: [PATCH 09/11] Apply suggestions from code review Co-authored-by: shainaraskas <58563081+shainaraskas@users.noreply.github.com> --- .../deployment-or-cluster/upgrade-717.md | 32 ++++++++++++------- 1 file changed, 20 insertions(+), 12 deletions(-) diff --git a/deploy-manage/upgrade/deployment-or-cluster/upgrade-717.md b/deploy-manage/upgrade/deployment-or-cluster/upgrade-717.md index 53be0d78b4..f3875937fb 100644 --- a/deploy-manage/upgrade/deployment-or-cluster/upgrade-717.md +++ b/deploy-manage/upgrade/deployment-or-cluster/upgrade-717.md @@ -9,7 +9,7 @@ applies_to: {{stack}} version 7.17 has a defined end of support date of 15 January 2026, as stated in the [Elastic Product & Version End of Life Policy](https://www.elastic.co/support/eol). This document provides a guided plan to upgrade from 7.17 to the latest {{version.stack}} release. It complements the official upgrade documentation by showing how the different pieces fit together in a complete upgrade exercise. -This guide applies to all deployment types ({{ech}} (ECH), {{ece}} (ECE), {{eck}} (ECK), and self-managed clusters) running {{es}} version **7.17.x**. If you are using an earlier version, upgrade first to the latest 7.17 release before proceeding. +This guide applies to all deployment types: ({{ech}} (ECH), {{ece}} (ECE), {{eck}} (ECK), and self-managed clusters) running {{es}} version **7.17.x**. If you are using an earlier version, [upgrade first to the latest 7.17 release](https://www.elastic.co/guide/en/elastic-stack/7.17/upgrading-elastic-stack.html) before proceeding. ## Overview @@ -35,9 +35,9 @@ For detailed guidance on how to plan and execute this method, refer to [Reindex It may be suitable when: - You prefer to build new infrastructure rather than modify an existing one. - You want to reduce the risk of performing two consecutive major upgrades. -- You plan to redesign your topology or move to a new environment (for example, from self-managed to {{ech}} or {{ece}}). +- You plan to redesign your topology or move to a new environment, for example from self-managed to {{ech}} or {{ece}}. -This approach is intended for {{es}} use cases focused on indexing and querying your own data. If you need a smooth transition that preserves {{kib}} configurations and {{stack}} features data, follow the standard upgrade path instead. +This approach is intended for {{es}} use cases focused on indexing and querying your own data. If you need to preserve {{kib}} configurations and {{stack}} feature data, follow the standard upgrade path instead. :::: ## Upgrade planning [planning] @@ -62,9 +62,9 @@ For the 7.17.x → 9.x upgrade path, the main planning outcome is a set of requi * **Orchestration platforms:** - * {applies_to}`eck:` If you are running an ECK version earlier than 3.x, you need to upgrade [ECK before](/deploy-manage/upgrade/orchestrator/upgrade-cloud-on-k8s.md) the final upgrade to 9.x. This can be done either at the beginning, before the initial upgrade, or between the two upgrade phases. + * **ECK**: If you are running an ECK version earlier than 3.x, you need to [upgrade ECK to 3.x](/deploy-manage/upgrade/orchestrator/upgrade-cloud-on-k8s.md) before the final upgrade to 9.x. This can be done either at the beginning, before the initial upgrade, or between the two upgrade phases. - * {applies_to}`ece:` If you are running an ECE version earlier than 4.x, you need to [upgrade your ECE platform](/deploy-manage/upgrade/orchestrator/upgrade-cloud-enterprise.md) before the final upgrade to 9.x. This upgrade must be performed after upgrading your deployments to 8.19.x, since ECE 4.x is not compatible with 7.x deployments. + * **ECE**: If you are running an ECE version earlier than 4.x, you need to [upgrade your ECE platform to 4.x](/deploy-manage/upgrade/orchestrator/upgrade-cloud-enterprise.md) before the final upgrade to 9.x. This upgrade must be performed after upgrading your deployments to 8.19.x, because ECE 4.x is not compatible with 7.x deployments. Finally, we strongly recommend [testing the full upgrade process in a non-production environment](/deploy-manage/upgrade/plan-upgrade.md#test-in-a-non-production-environment) before applying it to production. @@ -88,7 +88,7 @@ Follow the guidelines below for your specific deployment type: :::{applies-item} ess: -The {{ecloud}} platform facilitates major upgrades by: +The {{ecloud}} platform facilitates major upgrades by doing the following: * Automatically creating a snapshot before the upgrade. * Detecting deprecated settings and index compatibility issues. * Blocking the upgrade until all issues are resolved through the Upgrade Assistant, ensuring a reliable outcome. @@ -109,12 +109,16 @@ You should make sure to: :::{applies-item} ece: -{{ece}} platform facilitates major upgrades by: +{{ece}} platform facilitates major upgrades by doing the following: * When [snapshots are configured](/deploy-manage/tools/snapshot-and-restore/cloud-enterprise.md), automatically creating a snapshot before the upgrade. * Detecting deprecated settings and index compatibility issues. * Blocking the upgrade until all issues are resolved through the Upgrade Assistant, ensuring a reliable outcome. -To prepare your deployment for the upgrade, complete the steps described in the [8.19 {{ecloud}} upgrade guide](https://www.elastic.co/guide/en/elastic-stack/8.19/upgrade-elastic-stack-for-elastic-cloud.html) up to the "Perform the upgrade" section. *Note: Although this guide refers to {{ecloud}}, the same preparation steps apply to ECE deployments.* +To prepare your deployment for the upgrade, complete the steps described in the [8.19 {{ecloud}} upgrade guide](https://www.elastic.co/guide/en/elastic-stack/8.19/upgrade-elastic-stack-for-elastic-cloud.html) up to the "Perform the upgrade" section. + +:::{note} +Although this guide refers to {{ecloud}}, the same preparation steps apply to ECE deployments. +::: You should make sure to: @@ -128,7 +132,7 @@ You should make sure to: 3. As a temporary solution, you can use [REST API compatibility mode](https://www.elastic.co/guide/en/elasticsearch/reference/8.19/rest-api-compatibility.html) if your custom client applications are affected by breaking changes. This mode should only serve as a bridge to ease the upgrade process, not as a long-term strategy. ::: -:::{applies-item} { eck: } +:::{applies-item} eck: Upgrade preparations for an {{eck}}-managed cluster are similar to a self-managed deployment. Before starting the upgrade: @@ -152,7 +156,7 @@ For additional details and best practices, review the [{{es}} upgrade setup guid Keep the following considerations in mind when upgrading your deployment or cluster: * If you use [Stack monitoring](/deploy-manage/monitor/stack-monitoring.md) with a dedicated monitoring cluster, upgrade your monitoring cluster first. -* If you use [remote clusters](/deploy-manage/remote-clusters.md) functionality, upgrade the remote clusters first. +* If you use [remote cluster](/deploy-manage/remote-clusters.md) functionality, upgrade the remote clusters first. To perform the upgrade, follow the instructions below for your specific deployment type: @@ -170,7 +174,11 @@ During the upgrade process, all components of your deployment are upgraded in th :::{applies-item} ece: -To upgrade your deployment to 8.19, follow the steps in [Upgrade on Elastic Cloud → Perform the upgrade](https://www.elastic.co/guide/en/elastic-stack/8.19/upgrade-elastic-stack-for-elastic-cloud.html#perform-cloud-upgrade). *Note: Although this guide refers to {{ecloud}}, the same steps apply to ECE deployments.* +To upgrade your deployment to 8.19, follow the steps in [Upgrade on Elastic Cloud → Perform the upgrade](https://www.elastic.co/guide/en/elastic-stack/8.19/upgrade-elastic-stack-for-elastic-cloud.html#perform-cloud-upgrade). + +:::{note} +Although this guide refers to {{ecloud}}, the same steps apply to ECE deployments. +::: During the upgrade process, all components of your deployment are upgraded in the expected order: - {{es}} @@ -178,7 +186,7 @@ During the upgrade process, all components of your deployment are upgraded in th - Integrations Server ({{fleet-server}} and APM) ::: -:::{applies-item} { eck: } +:::{applies-item} eck: To upgrade your cluster to 8.19, follow the steps in [Upgrade on ECK](/deploy-manage/upgrade/deployment-or-cluster/upgrade-on-eck.md). From 5f08804f2b95f62573b5370c4182bd0a5a60b5db Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Edu=20Gonz=C3=A1lez=20de=20la=20Herr=C3=A1n?= <25320357+eedugon@users.noreply.github.com> Date: Sat, 18 Oct 2025 10:54:17 +0200 Subject: [PATCH 10/11] suggestions implemented --- .../_snippets/upgrade-validation.md | 15 +++++ .../deployment-or-cluster/upgrade-717.md | 61 ++++++++----------- 2 files changed, 42 insertions(+), 34 deletions(-) create mode 100644 deploy-manage/upgrade/deployment-or-cluster/_snippets/upgrade-validation.md diff --git a/deploy-manage/upgrade/deployment-or-cluster/_snippets/upgrade-validation.md b/deploy-manage/upgrade/deployment-or-cluster/_snippets/upgrade-validation.md new file mode 100644 index 0000000000..2a8b043be4 --- /dev/null +++ b/deploy-manage/upgrade/deployment-or-cluster/_snippets/upgrade-validation.md @@ -0,0 +1,15 @@ +After completing the upgrade, verify that your system is fully operational. Check that data ingestion and search are working as expected, clients and integrations can connect, and {{kib}} is accessible. + +Confirm that the cluster is healthy and reports the expected version. You can use the following APIs to validate the cluster status after the upgrade: + +* Check cluster health + ```console + GET _cluster/health?pretty + ``` + Ensure the status is green, or yellow if that is expected for your configuration (for example, in single-node clusters). + +* Check nodes and version + ```console + GET _cat/nodes?v&h=name,node.role,master,ip,version + ``` + Verify that all nodes report the upgraded version in the version column. diff --git a/deploy-manage/upgrade/deployment-or-cluster/upgrade-717.md b/deploy-manage/upgrade/deployment-or-cluster/upgrade-717.md index f3875937fb..e9fb2f62d8 100644 --- a/deploy-manage/upgrade/deployment-or-cluster/upgrade-717.md +++ b/deploy-manage/upgrade/deployment-or-cluster/upgrade-717.md @@ -23,6 +23,10 @@ Upgrading from 7.17 to {{version.stack}} requires two major upgrades. Each major This completes the upgrade to the latest 9.x release. Before running this upgrade, all ingest components and client libraries must be upgraded to 8.19.x. +:::{note} +Upgrading only to version 8.19.x is also a supported path, as it remains a maintained and fully supported release. However, we recommend completing the upgrade to the latest {{version.stack}} version to take advantage of ongoing improvements and new features. +::: + The following sections describe these phases in detail and point to the relevant documentation for each deployment type. Refer to [upgrade paths](/deploy-manage/upgrade.md#upgrade-paths) for more information. @@ -46,7 +50,7 @@ The [planning phase](/deploy-manage/upgrade/plan-upgrade.md) ensures that the up It involves defining a clear sequence of actions and assessing the impact on [service availability](/deploy-manage/upgrade.md#availability-during-upgrades) and performance during the upgrade. -For the 7.17.x → 9.x upgrade path, the main planning outcome is a set of required actions to ensure compatibility across the ecosystem: +For the 7.17.x → 9.x upgrade path, the main planning outcome is a set of required actions to ensure compatibility across the environment: * **Ingest components:** @@ -158,6 +162,8 @@ Keep the following considerations in mind when upgrading your deployment or clus * If you use [Stack monitoring](/deploy-manage/monitor/stack-monitoring.md) with a dedicated monitoring cluster, upgrade your monitoring cluster first. * If you use [remote cluster](/deploy-manage/remote-clusters.md) functionality, upgrade the remote clusters first. +Before starting the upgrade, run the same checks and validations you plan to perform afterward, so you have a baseline for comparison. Refer to [](#819-validation) for example checks. + To perform the upgrade, follow the instructions below for your specific deployment type: ::::{applies-switch} @@ -186,7 +192,9 @@ During the upgrade process, all components of your deployment are upgraded in th - Integrations Server ({{fleet-server}} and APM) ::: + :::{applies-item} eck: +In ECK, upgrades are performed declaratively by updating the `spec.version` field in the resource manifest. Once the new version is applied, the operator automatically orchestrates the upgrade, ensuring that each component is upgraded safely and in the correct order. To upgrade your cluster to 8.19, follow the steps in [Upgrade on ECK](/deploy-manage/upgrade/deployment-or-cluster/upgrade-on-eck.md). @@ -201,12 +209,10 @@ Make sure to upgrade all components in the specified order. :::: -### 8.19 upgrade validation - -After completing the upgrade, verify that your system is fully operational. Check that data ingestion and search are working as expected, clients and integrations can connect, and {{kib}} is accessible. - -Confirm that the cluster is healthy and reports the expected version. +### 8.19 upgrade validation [819-validation] +:::{include} _snippets/upgrade-validation.md +::: ### Upgrade ingest components to 8.19.x @@ -216,6 +222,12 @@ Refer to [Upgrade your ingest components](/deploy-manage/upgrade/ingest-componen After upgrading your ingest components, verify that they’re running correctly and sending data to the cluster before proceeding with the next upgrade. +:::{note} +At this point, you have a fully operational {{stack}} 8.19.x environment. You can choose to remain on this version, as it’s fully maintained and supported. + +However, we recommend upgrading to {{version.stack}} to benefit from the latest features and performance improvements. +::: + ## Upgrade Step 2: 8.19.x → {{version.stack}} This step covers upgrading your deployment from 8.19.x to {{version.stack}}, assuming that all ingest components have been upgraded to 8.19.x, and client libraries are compatible with 9.x. @@ -351,34 +363,15 @@ Follow the steps in the [upgrade Elastic on-prem](https://www.elastic.co/guide/e ### {{version.stack}} upgrade validation -(TBD) +:::{include} _snippets/upgrade-validation.md +::: ### (Optional) Upgrade ingest components to {{version.stack}} -(TBD) -This step is optional, because all ingest components on 8.19.x are compatible with {{stack}} 9.x. - -Refer to [upgrade your ingest components](/deploy-manage/upgrade/ingest-components.md) for more details. - - -## Post-Upgrade Wrap-Up - -(TBD) -- Confirm cluster stability over an observation period -- Update operational runbooks and monitoring baselines -- Validate client library upgrades and integrations -- Decommission old snapshots if no longer needed -- Document lessons learned - - \ No newline at end of file +This step is optional, as all ingest components running on 8.19.x are fully compatible with {{stack}} 9.x. However, upgrading them to {{version.stack}} ensures version alignment across your environment and allows you to take advantage of the latest features, performance improvements, and fixes. + +Refer to [Upgrade your ingest components](/deploy-manage/upgrade/ingest-components.md) for detailed upgrade instructions. + +## Next steps + +You now have a fully upgraded {{stack}} {{version.stack}} environment. To explore new capabilities, see [What’s new in {{version.stack}}](/release-notes/intro/index.md#whats-new-in-the-latest-elastic-release). \ No newline at end of file From a674a858c3b7831ffa3b8f49266c945efbf19a59 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Edu=20Gonz=C3=A1lez=20de=20la=20Herr=C3=A1n?= <25320357+eedugon@users.noreply.github.com> Date: Sat, 18 Oct 2025 11:15:03 +0200 Subject: [PATCH 11/11] fixing switches --- .../deployment-or-cluster/upgrade-717.md | 49 ++++++++++--------- 1 file changed, 25 insertions(+), 24 deletions(-) diff --git a/deploy-manage/upgrade/deployment-or-cluster/upgrade-717.md b/deploy-manage/upgrade/deployment-or-cluster/upgrade-717.md index e9fb2f62d8..b3297ddedf 100644 --- a/deploy-manage/upgrade/deployment-or-cluster/upgrade-717.md +++ b/deploy-manage/upgrade/deployment-or-cluster/upgrade-717.md @@ -88,9 +88,9 @@ While the **Upgrade Assistant** helps you identify breaking changes that affect Follow the guidelines below for your specific deployment type: -::::{applies-switch} +:::::{applies-switch} -:::{applies-item} ess: +::::{applies-item} ess: The {{ecloud}} platform facilitates major upgrades by doing the following: * Automatically creating a snapshot before the upgrade. @@ -109,9 +109,9 @@ You should make sure to: 2. If you use [custom plugins or bundles](/deploy-manage/deploy/elastic-cloud/upload-custom-plugins-bundles.md), make sure they’re compatible with the next major release. 3. As a temporary solution, you can use [REST API compatibility mode](https://www.elastic.co/guide/en/elasticsearch/reference/8.19/rest-api-compatibility.html) if your custom client applications are affected by breaking changes. This mode should only serve as a bridge to ease the upgrade process, not as a long-term strategy. -::: +:::: -:::{applies-item} ece: +::::{applies-item} ece: {{ece}} platform facilitates major upgrades by doing the following: * When [snapshots are configured](/deploy-manage/tools/snapshot-and-restore/cloud-enterprise.md), automatically creating a snapshot before the upgrade. @@ -134,9 +134,9 @@ You should make sure to: 2. If you use [custom plugins or bundles](/deploy-manage/deploy/elastic-cloud/upload-custom-plugins-bundles.md), make sure they’re compatible with the next major release. 3. As a temporary solution, you can use [REST API compatibility mode](https://www.elastic.co/guide/en/elasticsearch/reference/8.19/rest-api-compatibility.html) if your custom client applications are affected by breaking changes. This mode should only serve as a bridge to ease the upgrade process, not as a long-term strategy. -::: +:::: -:::{applies-item} eck: +::::{applies-item} eck: Upgrade preparations for an {{eck}}-managed cluster are similar to a self-managed deployment. Before starting the upgrade: @@ -144,31 +144,30 @@ Upgrade preparations for an {{eck}}-managed cluster are similar to a self-manage * Review the [{{es}} upgrade setup guide](https://www.elastic.co/guide/en/elasticsearch/reference/8.19/setup-upgrade.html) for additional details and best practices. If you're upgrading from an {{eck}} version earlier than 3.x, make sure to [upgrade ECK first](/deploy-manage/upgrade/orchestrator/upgrade-cloud-on-k8s.md) before performing the final upgrade to 9.x. -::: +:::: -:::{applies-item} self: +::::{applies-item} self: Before starting the upgrade, follow the [Prepare to upgrade from 7.x](https://www.elastic.co/guide/en/elastic-stack/8.19/upgrading-elastic-stack.html#prepare-to-upgrade) steps. For additional details and best practices, review the [{{es}} upgrade setup guide](https://www.elastic.co/guide/en/elasticsearch/reference/8.19/setup-upgrade.html). -::: - :::: +::::: + ### 8.19 upgrade execution Keep the following considerations in mind when upgrading your deployment or cluster: * If you use [Stack monitoring](/deploy-manage/monitor/stack-monitoring.md) with a dedicated monitoring cluster, upgrade your monitoring cluster first. * If you use [remote cluster](/deploy-manage/remote-clusters.md) functionality, upgrade the remote clusters first. +* Before starting the upgrade, run the same checks and validations you plan to perform afterward, so you have a baseline for comparison. Refer to the [upgrade validation](#819-validation) section for example checks. -Before starting the upgrade, run the same checks and validations you plan to perform afterward, so you have a baseline for comparison. Refer to [](#819-validation) for example checks. - -To perform the upgrade, follow the instructions below for your specific deployment type: +The steps below describe how to upgrade the core components of your {{stack}} environment, {{es}}, {{kib}}, and, when applicable, {{fleet-server}} and Elastic APM, for each deployment type. -::::{applies-switch} +:::::{applies-switch} -:::{applies-item} ess: +::::{applies-item} ess: To upgrade your deployment to 8.19, follow the steps in [Upgrade on Elastic Cloud → Perform the upgrade](https://www.elastic.co/guide/en/elastic-stack/8.19/upgrade-elastic-stack-for-elastic-cloud.html#perform-cloud-upgrade). @@ -176,9 +175,9 @@ During the upgrade process, all components of your deployment are upgraded in th - {{es}} - {{kib}} - Integrations Server ({{fleet-server}} and APM) -::: +:::: -:::{applies-item} ece: +::::{applies-item} ece: To upgrade your deployment to 8.19, follow the steps in [Upgrade on Elastic Cloud → Perform the upgrade](https://www.elastic.co/guide/en/elastic-stack/8.19/upgrade-elastic-stack-for-elastic-cloud.html#perform-cloud-upgrade). @@ -190,25 +189,25 @@ During the upgrade process, all components of your deployment are upgraded in th - {{es}} - {{kib}} - Integrations Server ({{fleet-server}} and APM) -::: +:::: -:::{applies-item} eck: +::::{applies-item} eck: In ECK, upgrades are performed declaratively by updating the `spec.version` field in the resource manifest. Once the new version is applied, the operator automatically orchestrates the upgrade, ensuring that each component is upgraded safely and in the correct order. -To upgrade your cluster to 8.19, follow the steps in [Upgrade on ECK](/deploy-manage/upgrade/deployment-or-cluster/upgrade-on-eck.md). +To upgrade your cluster to 8.19, follow the steps in [Upgrade on ECK](/deploy-manage/upgrade/deployment-or-cluster/upgrade-on-eck.md), and start upgrading the {{es}} and {{kib}} resources that represent the cluster. After upgrading {{es}} and {{kib}}, upgrade any [other Elastic applications](/deploy-manage/deploy/cloud-on-k8s/orchestrate-other-elastic-applications.md) connected to the cluster, such as {{fleet-server}} or Elastic APM. -::: +:::: -:::{applies-item} self: +::::{applies-item} self: To upgrade your cluster to 8.19, follow the steps in [Upgrade self-managed {{stack}}](https://www.elastic.co/guide/en/elastic-stack/8.19/upgrading-elastic-stack-on-prem.html). Make sure to upgrade all components in the specified order. -::: - :::: +::::: + ### 8.19 upgrade validation [819-validation] :::{include} _snippets/upgrade-validation.md @@ -230,6 +229,8 @@ However, we recommend upgrading to {{version.stack}} to benefit from the latest ## Upgrade Step 2: 8.19.x → {{version.stack}} +**(work in progress, pending to align with Step 1)** + This step covers upgrading your deployment from 8.19.x to {{version.stack}}, assuming that all ingest components have been upgraded to 8.19.x, and client libraries are compatible with 9.x. ### {{version.stack}} upgrade preparations