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 6efb0a366..93c2676f5 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
@@ -6,8 +6,11 @@
 Roll Back a Software Upgrade Before the Second Controller Upgrade
 =================================================================
 
-You can perform an in-service abort of an upgrade before the second Controller
-\(controller-0 in the examples of this procedure\) have been upgraded.
+After the first controller is upgraded, you can still perform an in-service
+abort of an upgrade before the second Controller \(controller-0 in the examples
+of this procedure\) has been upgraded. The :command:`system upgrade-abort`
+command can be run from the node that is updated with the latest release and
+has upgraded successfully.
 
 .. rubric:: |proc|
 
@@ -49,12 +52,19 @@ You can perform an in-service abort of an upgrade before the second Controller
 
     The host is re-installed with the previous release load.
 
+    .. note::
+        The downgrade process will take a minimum of 20 to 30 minutes to
+        complete.
+
+        You can view the downgrade progress on controller-1 using the
+        BMC console.
+
 #.  Unlock controller-1.
 
     .. code-block:: none
 
         $ system host-unlock controller-1
-        
+
 #.  Complete the upgrade.
 
     .. code-block:: none
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 c3ce7e49d..bf8af33df 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
@@ -119,13 +119,14 @@ of |prod| software.
 #.  Confirm that the system is healthy.
 
     Check the current system health status, resolve any alarms and other issues
-    reported by the :command:`health-query-upgrade` command, then recheck the
-    system health status to confirm that all **System Health** fields are set
-    to **OK**.
+    reported by the :command:`system health-query-upgrade` command, then
+    recheck the system health status to confirm that all **System Health**
+    fields are set to **OK**. For example:
 
     .. code-block:: none
 
         ~(keystone_admin)]$ system health-query-upgrade
+
         System Health:
         All hosts are provisioned: [OK]
         All hosts are unlocked/enabled: [OK]
@@ -137,6 +138,7 @@ of |prod| software.
         All kubernetes control plane pods are ready: [OK]
         Required patches are applied: [OK]
         License valid for upgrade: [OK]
+        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
@@ -228,6 +230,13 @@ of |prod| software.
 
             -   System data is being migrated from release N to release N+1.
 
+            .. note::
+                The upgrade process will take a minimum of 20 to 30 minutes to
+                complete.
+
+                You can view the upgrade progress on controller-1 using the
+                BMC console.
+
         -   data-migration-complete or upgrading-controllers:
 
             -   State entered when controller-1 upgrade is complete.
@@ -241,6 +250,10 @@ of |prod| software.
 
             -   Upgrade must be aborted.
 
+            .. note::
+                Review the /var/log/sysinv.log on the active controller for
+                more details on data migration failure.
+
     #.  Check the upgrade state.
 
         .. code-block:: none
@@ -279,8 +292,7 @@ of |prod| software.
         If it transitions to **unlocked-disabled-failed**, check the issue
         before proceeding to the next step. The alarms may indicate a
         configuration error. Check the result of the configuration logs on
-        controller-1, \(for example, Error logs in
-        controller1:/var/log/puppet\).
+        controller-1, \(for example, Error logs in controller1:/var/log/puppet\).
 
 #.  Set controller-1 as the active controller. Swact to controller-1.
 
@@ -321,6 +333,10 @@ of |prod| software.
             -   State entered when both controllers are running release nn.nn
                 software.
 
+        .. note::
+            |AIO-DX| or Controllers of Standard configurations can be
+            upgraded, using steps 1-9 above.
+
 #.  Check the system health to ensure that there are no unexpected alarms.
 
     .. code-block:: none
@@ -331,6 +347,9 @@ of |prod| software.
 
 #.  If using Ceph storage backend, upgrade the storage nodes one at a time.
 
+    .. note::
+        Proceed to step 13 if no storage/worker node is present.
+
     The storage node must be locked and all OSDs must be down in order to do
     the upgrade.