diff --git a/doc/source/dist_cloud/kubernetes/upgrade-management-overview.rst b/doc/source/dist_cloud/kubernetes/upgrade-management-overview.rst
index 82ddace73..0cf3aa218 100644
--- a/doc/source/dist_cloud/kubernetes/upgrade-management-overview.rst
+++ b/doc/source/dist_cloud/kubernetes/upgrade-management-overview.rst
@@ -37,11 +37,11 @@ follows:
 
 .. rubric:: |prereq|
 
-For |AIO-SX| subclouds, end user container images in `registry.local` will be
-backed up during the upgrade process. This only includes images other than
-|prod| system and application images. These images are limited to 5 GBytes in
-total size. If the system contains more than 5 GBytes of these images, the
-upgrade start will fail.
+For all deployment configurations, end user container images in
+`registry.local` will be backed up during the upgrade process. This only
+includes images other than |prod| system and application images. These images
+are limited to 5 GB in total size. If the system contains more than 5 GB of
+these images, the upgrade start will fail.
 
 The following prerequisites apply to a |prod-dc| upgrade management service.
 
@@ -75,15 +75,6 @@ The following prerequisites apply to a |prod-dc| upgrade management service.
 -   The subclouds must all be |AIO-SX|, and must use the Redfish
     platform management service.
 
--   **Remove Non GA Applications**:
-
-    -   Use the :command:`system application-remove` and :command:`system
-        application-delete` commands to remove the application on the
-        subclouds:
-
-    -   Remove any non-GA and |prefix|-openstack applications, from the
-        |prod-dc| system, if they exist.
-
 .. only:: partner
 
     .. include:: /_includes/upgrade-management-overview.rest
diff --git a/doc/source/updates/kubernetes/rolling-back-a-software-upgrade-before-the-second-controller-upgrade.rst b/doc/source/updates/kubernetes/rolling-back-a-software-upgrade-before-the-second-controller-upgrade.rst
index 93c2676f5..6a8582a75 100644
--- a/doc/source/updates/kubernetes/rolling-back-a-software-upgrade-before-the-second-controller-upgrade.rst
+++ b/doc/source/updates/kubernetes/rolling-back-a-software-upgrade-before-the-second-controller-upgrade.rst
@@ -57,7 +57,7 @@ has upgraded successfully.
         complete.
 
         You can view the downgrade progress on controller-1 using the
-        BMC console.
+        serial console.
 
 #.  Unlock controller-1.
 
diff --git a/doc/source/updates/kubernetes/upgrading-all-in-one-duplex-or-standard.rst b/doc/source/updates/kubernetes/upgrading-all-in-one-duplex-or-standard.rst
index bf8af33df..dd4114c14 100644
--- a/doc/source/updates/kubernetes/upgrading-all-in-one-duplex-or-standard.rst
+++ b/doc/source/updates/kubernetes/upgrading-all-in-one-duplex-or-standard.rst
@@ -2,9 +2,9 @@
 .. btn1592861794542
 .. _upgrading-all-in-one-duplex-or-standard:
 
-======================================
+====================================
 Upgrade All-in-One Duplex / Standard
-======================================
+====================================
 
 You can upgrade the |prod| Duplex or Standard configurations with a new release
 of |prod| software.
@@ -141,9 +141,9 @@ of |prod| software.
         No instances running on controller-1: [OK]
 
     By default, the upgrade process cannot be run and is not recommended to be
-    run with Active Alarms present. However, management affecting alarms can be
-    ignored with the :command:`--force` option with the :command:`system
-    upgrade-start` command to force the upgrade process to start.
+    run with active alarms present. Use the command :command:`system upgrade-start --force`
+    to force the upgrade process to start and ignore non-management-affecting
+    alarms.
 
     .. note::
         It is strongly recommended that you clear your system of any and all
@@ -169,9 +169,9 @@ of |prod| software.
         | to_release   | nn.nn                                |
         +--------------+--------------------------------------+
 
-    This will make a copy of the system data to be used in the upgrade.
-    Configuration changes are not allowed after this point until the swact to
-    controller-1 is completed.
+    This will make a copy of the upgrade data onto a DRBD file system to be used
+     in the upgrade. Configuration changes are not allowed after this point
+     until the swact to controller-1 is completed.
 
     The following upgrade state applies once this command is executed:
 
@@ -193,7 +193,7 @@ of |prod| software.
 
     .. note::
         Use the command :command:`system upgrade-start --force` to force the
-        upgrades process to start and to ignore management affecting alarms.
+        upgrade process to start and ignore non-management-affecting alarms.
         This should ONLY be done if you feel these alarms will not be an issue
         over the upgrades process.
 
@@ -235,7 +235,7 @@ of |prod| software.
                 complete.
 
                 You can view the upgrade progress on controller-1 using the
-                BMC console.
+                serial console.
 
         -   data-migration-complete or upgrading-controllers: