[DOC-14468]: Feedback on Upgrade | Couchbase Docs

modules/install/pages/upgrade.adoc

@@ -24,7 +24,7 @@ See xref:install:upgrade-procedure-selection.adoc#swap-rebalance[Swap Rebalance]
 
 Before upgrading, consider the following version compatibility concerns.
 
-[#8-0-storage-backend]
+[#storage-backend-8.0]
 === New Default Storage Backend in Couchbase Server Version 8.0
 
 After you fully upgrade to Couchbase Server 8.0.x or later, the default storage backend for buckets is Magma with 128 vBuckets.
@@ -34,15 +34,15 @@ This new default results in 2 behavior changes from previous versions:
 
 * If you create a bucket and do not specify the storage backend, your bucket uses the Magma storage backend instead of the Couchstore backend.
 * If you specify Magma as the storage backend but do not set the new `numVBuckets` parameter, the bucket has 128 vBuckets instead of the prior default of 1024 vBuckets.
-Magma buckets with 128 vBuckets is a new feature in Couchbase Server 8.0 and later.
+Magma buckets with 128 vBuckets are a new feature in Couchbase Server 8.0 and later.
 
 These behavior changes could cause issues if you rely on the prior behavior and you use deployment scripts.
 If you have deployment scripts that create buckets, review them to determine if you need to make changes.
 
 For example, suppose your deployment script does not specify the storage backend when it creates a bucket that you intend to use with the xref:learn:views/views-intro.adoc[views] feature.
 On versions prior to Couchbase Server 8.0, your script created a Couchstore bucket with 1024 vBuckets,
 In version 8.0, due to change in the default backend, your script creates a bucket with the Magma storage backend with 128 vBuckets.
-Attempting to use MapReduce Views with this bucket results in errors, because Magma buckets do not support this feature.
+Attempting to use MapReduce Views with this bucket results in errors because Magma buckets do not support this feature.
 
 include::learn:partial$views-deprecation-notice.adoc[]
 
@@ -149,9 +149,8 @@ TIP: As far as is possible, you should aim to keep your cluster up to date with
 | Any 6.0.x / 6.5.x → 6.6 → 7.2.3 → latest 7.2.x → 8.0.1
 
 | 7.x
-| Any 7.0.x / 7.1.x → 7.2.3 → latest 7.2.x → 8.0.1
-
-Any 7.2.x → latest 7.2.x → 8.0.1
+| Any 7.0.x / 7.1.x → 7.2.3 → latest 7.2.x → 8.0.1 +
+Any 7.2.x → latest 7.2.x → 8.0.1 +
 Any 7.6.x → latest 7.6.x → 8.0.1
 
 |===
@@ -171,9 +170,8 @@ Any 7.6.x → latest 7.6.x → 8.0.1
 | Any 6.0.x / 6.5.x → 6.6 → 7.2.3 → latest 7.2.x → 8.0.1
 
 | 7.x
-| Any 7.0.x / 7.1.x → 7.2.3 → latest 7.2.x → 8.0.1
-
-Any 7.2.x → latest 7.2.x → 8.0.1
+| Any 7.0.x / 7.1.x → 7.2.3 → latest 7.2.x → 8.0.1 +
+Any 7.2.x → latest 7.2.x → 8.0.1 +
 Any 7.6.x → latest 7.6.x → 8.0.1
 
 |===
@@ -230,15 +228,15 @@ and from *7.2.3* to *7.6.x*.
 == Upgrade from Community Edition to Enterprise
 
 
-If you’re currently operating a Couchbase Server cluster on Community Edition, you can upgrade it to Enterprise Edition by way of a xref:upgrade-strategies.adoc#online-upgrade[rolling online upgrade].
+If you're operating a Couchbase Server cluster on Community Edition, you can upgrade it to Enterprise Edition by way of a xref:upgrade-strategies.adoc#online-upgrade[rolling online upgrade].
 This involves switching out the Community Edition nodes with fresh, net-new Enterprise Edition nodes.
 Both swap rebalance and remove and rebalance methods are supported.
 Delta Recovery is not supported since the new nodes must be fresh Enterprise Edition installations without any pre-existing Community Edition data remaining on them.
 
 NOTE: Rolling upgrades from CE to EE are not supported if there are index service nodes running in the cluster.
 
 The Enterprise Edition nodes must be running the same version number of Couchbase Server as the Community Edition nodes that they're replacing, otherwise the upgrade may fail.
-This means you can not upgrade to a later version of Couchbase Server while also upgrading to Enterprise Edition during the same rolling upgrade.
+This means you cannot upgrade to a later version of Couchbase Server while also upgrading to Enterprise Edition during the same rolling upgrade.
 
 If you want to upgrade from an earlier version of `Community Edition` to a later version of `Enterprise Edition`, you need to perform 2 separate upgrade procedures:
 
@@ -281,13 +279,13 @@ For information, see xref:learn:security/certificates.adoc#node-certificate-vali
 == Downgrade
 
 If you have issues with an upgrade, you may want to downgrade to the earlier version of Couchbase Server.
-Your ability to downgrade depends on the whether the upgrade was between and major or minor version numbers or a maintenance version.
+Your ability to downgrade depends on whether the upgrade was between major or minor version numbers or a maintenance version.
 See <<version-numbers>> for an explanation of Couchbase Server's version numbering scheme.
 
 [#downgrade_major_minor]
 === Downgrading an Upgrade Between Major or Minor Versions
 
-A major or minor version upgrade is an upgrade between versions that have different first or second digit in their version numbers.
+A major or minor version upgrade is an upgrade between versions that have a different first or second digit in their version numbers.
 Examples of a major or minor version upgrade include:
 
 * Upgrading from version 6.6.0 to version 7.2.3 is a major upgrade.
@@ -317,12 +315,12 @@ Because finalization increases the difficulty in rolling back an upgrade, it's v
 See the next section for tips on preventing finalization until you're ready to finalize your upgrade.
 
 NOTE: If you do need to roll back a finalized upgrade and you have a disaster recovery cluster running the previous version synced via XDCR, consider switching to it.
-Then you can create a new cluster running the prior version and either use it as the disaster recovery cluster or switch back to it after it has synched all data.
+Then you can create a new cluster running the prior version and either use it as the disaster recovery cluster or switch back to it after it has synced all data.
 
 [#prevent-finalization]
 === Preventing Finalization
 
-You should verify that your applications perform well using the new version of Couchbase Server before you finalize your upgrade.
+You should verify that your applications perform well when using the new version of Couchbase Server before you finalize your upgrade.
 Fully testing your applications may require you to upgrade all nodes in the cluster.
 However, Couchbase Server finalizes your installation when you upgrade the last node to the new version of Couchbase Server.
 
@@ -386,7 +384,7 @@ To perform an online downgrade:
 . On the node you removed, install the earlier version of Couchbase Server.
 . xref:manage:manage-nodes/add-node-and-rebalance.adoc[Add the node back to the cluster].
 . Perform a rebalance to complete the addition.
-. Repeat steps 1-5 for each node in the cluster until all nodes are running the earlier version of Couchbase Server.
+. Repeat steps 1–5 for each node in the cluster until all nodes are running the earlier version of Couchbase Server.
 . If you added an arbiter node to prevent finalization, remove the arbiter node and perform a rebalance to complete the downgrade.
 See <<prevent-finalization>> for more information about using an arbiter node to prevent finalization.