Fix partial and backport

Author: danielehc

content/consul/v1.18.x/content/docs/enterprise/upgrades.mdx

@@ -6,21 +6,21 @@ description: >-
 ---
 
 # Automated Upgrades
+
 This page describes automated upgrades, a Consul Enterprise feature that helps you upgrade the version of Consul your servers are running.
 
+@include 'alerts/enterprise-alert.mdx'
+
 ## Introduction
-One of the fundamental operations to be performed in any production environment is to upgrade Consul servers to a new version without experiencing downtime, while minimizing any risk factors that could lead to future outages.
 
-Consul Enterprise helps you automatically upgrade a cluster of Consul servers to a new version.
+One of the fundamental operations to be performed in any production environment is to upgrade Consul servers to a new version without experiencing downtime, while minimizing any risk factors that could lead to future outages.
 
 Consul autopilot monitors the amount of servers in the cluster. When a sufficient amount of new server nodes join, Consul promotes them to voters, elects a new leader among the new servers, and then demotes the servers running old versions to non-voters. Once this demotion occurs, the old servers can be safely removed from the cluster.
 
-@include 'alerts/enterprise-alert.mdx'
-
 Automated upgrades can help you in the following scenarios:
 
-- **Upgrade to a new Consul version**: When you want to upgrade Consul servers to a newer version without downtime.
-- **Migrate to different server nodes**: When you have a new Consul server image with security patches and want to replace the running Consul server instances automatically, without experiencing downtime.
+- [Upgrade to a new Consul version](#upgrade-to-a-new-consul-version): When you want to upgrade Consul servers to a newer version without downtime.
+- [Migrate to different server nodes](#migrate-to-different-server-nodes): When you have a new Consul server image with security patches and want to replace the running Consul server instances automatically, without experiencing downtime.
 
 ## Prerequisites
 
@@ -31,16 +31,16 @@ To test the automated upgrades feature explained in this tutorial you will need:
 
 The different Consul versions need to be compatible for a direct upgrade. Check [Protocol Compatibility Promise](/consul/docs/upgrade/compatibility) and [Upgrade instructions](/consul/docs/upgrade/instructions) to make sure the versions you are using are compatible.
 
-## Workflow
+## Upgrade to a new Consul version
 
 The process to upgrade Consul servers to a newer version with automated upgrades consists of the following steps:
 
-1. Verify that automated upgrades is enabled
-1. Add new Consul servers
-1. Verify upgrade
-1. Stop old servers
+1. [Verify that automated upgrades is enabled](#verify-that-automated-upgrades-is-enabled)
+1. [Add new Consul servers](#add-new-consul-servers)
+1. [Verify upgrade](#verify-upgrade)
+1. [Stop old servers](#stop-old-servers)
 
-## Verify that automated upgrades is enabled
+### Verify that automated upgrades is enabled
 
 The automated upgrades feature is enabled by default in Consul Enterprise. 
 
@@ -70,7 +70,7 @@ UpgradeVersionTag = ""
 
 If the feature is disabled in your datacenter, enable it with the `consul operator autopilot set-config -disable-upgrade-migration=false` command.
 
-## Add new servers
+### Add new Consul servers
 
 The following example uses an existing Consul Enterprise `1.21.7` datacenter with three servers and `bootstrap_expect = 3`. 
 
@@ -98,7 +98,7 @@ consul-server-2a  73e267e5-f817-0577-bbe5-2f843adff357  172.18.0.4:8300   follow
 
 Consul will keep the added servers as `non-voter` members until enough servers running the new Consul version are part of the datacenter. When the number of new servers is enough to form a quorum and elect a new leader, autopilot promotes the new servers to voters and triggers a new leader election, before it finally demotes the old servers.
 
-## Verify upgrade
+### Verify upgrade
 
 After enough servers running the new version join the datacenter, Consul autopilot starts the upgrade process.
 
@@ -185,10 +185,10 @@ For example, if `UpgradeVersionTag` is set to `build`, and `node-meta.build` is
 `0.0.2` when considered by autopilot for a migration. The upgrade logic will follow semantic versioning and the version string must be in the form of either `X`, `X.Y`, or `X.Y.Z`.
 
 To upgrade Consul servers using `UpgradeVersionTag`, complete the following steps:
-1. Configure autopilot for existing servers
-1. Add new Consul servers 
-1. Verify upgrade
-1. Stop old servers
+1. [Configure autopilot for existing servers](#configure-autopilot-for-existing-servers)
+1. [Add new Consul servers ](#add-new-consul-servers-1)
+1. [Verify upgrade](#verify-upgrade-1)
+1. [Stop old servers](#stop-old-servers-1)
 
 ### Configure autopilot for existing servers
 
@@ -300,6 +300,8 @@ autopilot {
 
 </CodeTabs>
 
+### Verify upgrade
+
 After the third new server starts, autopilot detects the possibility of a quorum among the new servers, and promotes them to voters.
 
 New nodes are first promoted to `voter` state.

content/consul/v1.19.x/content/docs/enterprise/upgrades.mdx

@@ -1,7 +1,6 @@
 <EnterpriseAlert>
 
-This feature requires
-HashiCorp Cloud Platform (HCP) or self-managed Consul Enterprise.
+This feature requires Consul Enterprise.
 Refer to the [enterprise feature matrix](/consul/docs/enterprise#consul-enterprise-feature-availability) for additional information.
 
 </EnterpriseAlert>