diff --git a/docs_user/assemblies/assembly_adopting-key-manager-service-with-hsm.adoc b/docs_user/assemblies/assembly_adopting-key-manager-service-with-hsm.adoc
index 41a147a0e..feafa9145 100644
--- a/docs_user/assemblies/assembly_adopting-key-manager-service-with-hsm.adoc
+++ b/docs_user/assemblies/assembly_adopting-key-manager-service-with-hsm.adoc
@@ -8,7 +8,7 @@ ifdef::context[:parent-context: {context}]
 = Adopting the {key_manager} with HSM integration
 
 [role="_abstract"]
-Adopt the {key_manager_first_ref} from {OpenStackPreviousInstaller} to {rhos_long} when your source environment includes hardware security module (HSM) integration to preserve HSM functionality and maintain access to HSM-backed secrets. HSM provides enhanced security for cryptographic operations by storing encryption keys in dedicated hardware devices.
+Adopt the {key_manager_first_ref} with HSM integration to {rhos_long} to preserve HSM functionality and maintain access to HSM-backed secrets.
 
 For additional information about the {key_manager} before you start the adoption, see the following resources:
 
diff --git a/docs_user/assemblies/assembly_adopting-the-shared-file-systems-service.adoc b/docs_user/assemblies/assembly_adopting-the-shared-file-systems-service.adoc
index 1b4c66e2d..1908d406b 100644
--- a/docs_user/assemblies/assembly_adopting-the-shared-file-systems-service.adoc
+++ b/docs_user/assemblies/assembly_adopting-the-shared-file-systems-service.adoc
@@ -8,9 +8,9 @@ ifdef::context[:parent-context: {context}]
 = Adopting the {rhos_component_storage_file}
 
 [role="_abstract"]
-The {rhos_component_storage_file_first_ref} in {rhos_long} provides a self-service API to create and manage file shares. File shares (or "shares"), are built for concurrent read/write access from multiple clients. This makes the {rhos_component_storage_file} essential in cloud environments that require a ReadWriteMany persistent storage.
+The {rhos_component_storage_file_first_ref} provides a self-service API to create and manage file shares. File shares are built for concurrent read/write access from multiple clients, making the Shared File Systems service in cloud environments that require a ReadWriteMany persistent storage.
 
-File shares in {rhos_acro} require network access. Ensure that the networking in the {rhos_prev_long} ({OpenStackShort}) {rhos_prev_ver} environment matches the network plans for your new cloud after adoption. This ensures that tenant workloads remain connected to storage during the adoption process. The {rhos_component_storage_file} control plane services are not in the data path. Shutting down the API, scheduler, and share manager services do not impact access to existing shared file systems.
+File shares in {rhos_acro} require network access. Ensure that network plans match the {rhos_prev_long} environment to maintain tenant connectivity during adoption. The {rhos_component_storage_file} control plane services are not in the data path. Shutting down the API, scheduler, and share manager services do not impact access to existing shared file systems.
 
 Typically, storage and storage device management are separate networks. Shared File Systems services only need access to the storage device management network.
 For example, if you used a {CephCluster} cluster in the deployment, the "storage"
diff --git a/docs_user/assemblies/assembly_migrating-ceph-rbd.adoc b/docs_user/assemblies/assembly_migrating-ceph-rbd.adoc
index 4c1edb8fa..6d5790e1e 100644
--- a/docs_user/assemblies/assembly_migrating-ceph-rbd.adoc
+++ b/docs_user/assemblies/assembly_migrating-ceph-rbd.adoc
@@ -9,10 +9,9 @@ ifdef::context[:parent-context: {context}]
 
 [role="_abstract"]
 For Hyperconverged Infrastructure (HCI) or dedicated Storage nodes that are
-running {Ceph} {CephVernum} or later, you must migrate the daemons that are
-included in the {rhos_prev_long} control plane into the existing external Red
-Hat Enterprise Linux (RHEL) nodes. The external RHEL nodes typically include
-the Compute nodes for an HCI environment or dedicated storage nodes.
+running {Ceph} {CephVernum} or later, migrate the daemons from the {rhos_prev_long} control plane into the existing external Red Hat Enterprise Linux (RHEL) nodes.
+
+The external RHEL nodes typically include the Compute nodes for an HCI environment or dedicated storage nodes.
 
 == Prerequisites
 Before you begin the migration, complete the tasks in your {rhos_prev_long} {rhos_prev_ver} environment. For more information, see the "{Ceph} prerequisites" in the "Adoption overview" chapter.
diff --git a/docs_user/assemblies/assembly_migrating-ceph-rgw.adoc b/docs_user/assemblies/assembly_migrating-ceph-rgw.adoc
index 88b6f8179..8c469184c 100644
--- a/docs_user/assemblies/assembly_migrating-ceph-rgw.adoc
+++ b/docs_user/assemblies/assembly_migrating-ceph-rgw.adoc
@@ -8,7 +8,9 @@ ifdef::context[:parent-context: {context}]
 = Migrating {Ceph} RGW to external RHEL nodes
 
 [role="_abstract"]
-For Hyperconverged Infrastructure (HCI) or dedicated Storage nodes, you must migrate the Ceph Object Gateway (RGW) daemons that are included in the {rhos_prev_long} Controller nodes into the existing external Red Hat Enterprise Linux (RHEL) nodes. The external RHEL nodes typically include the Compute nodes for an HCI environment or {Ceph} nodes. Your environment must have {Ceph} {CephVernum} or later and be managed by `cephadm` or Ceph Orchestrator.
+For Hyperconverged Infrastructure (HCI) or dedicated Storage nodes, migrate the Ceph Object Gateway (RGW) daemons from the {rhos_prev_long} Controller nodes into the existing external Red Hat Enterprise Linux (RHEL) nodes.
+
+The RHEL nodes include the Compute nodes for an HCI environment or {Ceph} nodes. Your environment must have {Ceph} {CephVernum} or later and be managed by `cephadm` or Ceph Orchestrator.
 
 == Prerequisites
 
diff --git a/docs_user/assemblies/assembly_migrating-mon-from-controller-nodes.adoc b/docs_user/assemblies/assembly_migrating-mon-from-controller-nodes.adoc
index a9ff70c83..d63c4962c 100644
--- a/docs_user/assemblies/assembly_migrating-mon-from-controller-nodes.adoc
+++ b/docs_user/assemblies/assembly_migrating-mon-from-controller-nodes.adoc
@@ -8,8 +8,9 @@ ifdef::context[:parent-context: {context}]
 :context: migrating-ceph-mon
 
 [role="_abstract"]
-You must move Ceph Monitor daemons from the {rhos_prev_long} ({OpenStackShort}) Controller nodes to a set of target nodes. Target nodes are either existing {Ceph} nodes, or {OpenStackShort} Compute nodes if {Ceph} is
-deployed by {OpenStackPreviousInstaller} with a Hyperconverged Infrastructure (HCI) topology. Additional Ceph Monitors are deployed to the target nodes, and they are promoted as `_admin` nodes that you can use to manage the {CephCluster} cluster and perform day 2 operations.
+Move Ceph Monitor daemons from the {rhos_prev_long} ({OpenStackShort}) Controller nodes to a set of existing {Ceph} nodes, or to a set of {OpenStackShort} Compute nodes if {Ceph} is deployed by {OpenStackPreviousInstaller} with a Hyperconverged Infrastructure (HCI) topology.
+
+Additional Ceph Monitors are deployed to the target nodes and promoted as _admin nodes to manage the {CephCluster} cluster and perform day 2 operations.
 
 To migrate the Ceph Monitor daemons, you must perform the following high-level steps:
 
diff --git a/docs_user/assemblies/assembly_rhoso-180-adoption-overview.adoc b/docs_user/assemblies/assembly_rhoso-180-adoption-overview.adoc
index 0346244d5..cd34fab09 100644
--- a/docs_user/assemblies/assembly_rhoso-180-adoption-overview.adoc
+++ b/docs_user/assemblies/assembly_rhoso-180-adoption-overview.adoc
@@ -8,7 +8,9 @@ ifdef::context[:parent-context: {context}]
 = {rhos_long_noacro} {rhos_curr_ver} adoption overview
 
 [role="_abstract"]
-Adoption is the process of migrating a {rhos_prev_long} ({OpenStackShort}) {rhos_prev_ver} control plane to {rhos_long_noacro} {rhos_curr_ver}, and then completing an in-place upgrade of the data plane. You can retain existing infrastructure investments and modernize your {OpenStackShort} deployment on a containerized {rhocp_long} foundation. To ensure that you understand the entire adoption process and how to sufficiently prepare your {OpenStackShort} environment, review the prerequisites, adoption process, and post-adoption tasks.
+Adoption is the process of migrating a {rhos_prev_long} {rhos_prev_ver} control plane to {rhos_long_noacro} {rhos_curr_ver} and upgrading the data plane in-place. Retain existing infrastructure investments and modernize your {OpenStackShort} deployment on a containerized {rhocp_long} foundation.
+
+To understand the adoption process and to prepare your {OpenStackShort} environment, review the prerequisites, adoption process, and post-adoption tasks.
 
 [IMPORTANT]
 Read the whole adoption guide before you start
diff --git a/docs_user/modules/con_adopting-spine-leaf-networks.adoc b/docs_user/modules/con_adopting-spine-leaf-networks.adoc
index 12956dfd0..dfbdbcfc2 100644
--- a/docs_user/modules/con_adopting-spine-leaf-networks.adoc
+++ b/docs_user/modules/con_adopting-spine-leaf-networks.adoc
@@ -4,9 +4,9 @@
 = Configuring spine-leaf networks for the {rhos_long_noacro} deployment
 
 [role="_abstract"]
-When you adopt a {rhos_prev_long} ({OpenStackShort}) deployment with spine-leaf networking, like a Distributed Compute Node (DCN) architecture, you must each L2 network segment with a separate IP subnet and create create routed provider networks. Traffic between sites is routed at L3 through spine routers or similar network infrastructure.
+When you adopt a {rhos_prev_long} ({OpenStackShort}) deployment with spine-leaf networking, such as a Distributed Compute Node (DCN) architecture, adopt each L2 network segment with a separate IP subnet and create routed provider networks.
 
-You must configure routing for Compute nodes at edge sites to connect with control plane services, such as RabbitMQ or the database at the central site. The cloud will not function correctly without routes configured.
+Traffic between sites is routed at L3 through spine routers or similar network infrastructure. You must configure routing for Compute nodes at edge sites to connect with control plane services, such as RabbitMQ or the database at the central site. The cloud will not function correctly without routes configured.
 
 [NOTE]
 ====
diff --git a/docs_user/modules/con_adoption-guidelines.adoc b/docs_user/modules/con_adoption-guidelines.adoc
index 9c4a10b12..85f45bd4c 100644
--- a/docs_user/modules/con_adoption-guidelines.adoc
+++ b/docs_user/modules/con_adoption-guidelines.adoc
@@ -4,7 +4,7 @@
 = Guidelines for planning the adoption
 
 [role="_abstract"]
-When planning to adopt a {rhos_long} {rhos_curr_ver} environment, consider the scope of the change. An adoption is similar in scope to a data center upgrade. Different firmware levels, hardware vendors, hardware profiles, networking interfaces, storage interfaces, and so on affect the adoption process and can cause changes in behavior during the adoption.
+Adoption is similar in scope to a data center upgrade. Different firmware levels, hardware vendors, hardware profiles, networking interfaces, and storage interfaces can affect the adoption process and change behavior.
 
 Review the following guidelines to adequately plan for the adoption and increase the chance that you complete the adoption successfully:
 
diff --git a/docs_user/modules/con_preparing-the-shared-file-systems-service-configuration.adoc b/docs_user/modules/con_preparing-the-shared-file-systems-service-configuration.adoc
index 5fb0ac08f..474a29d13 100644
--- a/docs_user/modules/con_preparing-the-shared-file-systems-service-configuration.adoc
+++ b/docs_user/modules/con_preparing-the-shared-file-systems-service-configuration.adoc
@@ -4,7 +4,7 @@
 = Guidelines for preparing the {rhos_component_storage_file} configuration
 
 [role="_abstract"]
-To deploy {rhos_component_storage_file_first_ref} on the control plane, you must copy the original configuration file from the {rhos_prev_long} {rhos_prev_ver} deployment. You must review the content in the file to make sure you are adopting the correct configuration for {rhos_long} {rhos_curr_ver}. Not all of the content needs to be brought into the new cloud environment.
+Copy the {rhos_component_storage_file_first_ref} configuration from {rhos_prev_long} {rhos_prev_ver}, and review it to ensure that you copy the correct configuration for {rhos_long} {rhos_curr_ver}.
 
 Review the following guidelines for preparing your {rhos_component_storage_file} configuration file for adoption:
 
diff --git a/docs_user/modules/con_preventing-config-loss-when-using-oc-patch.adoc b/docs_user/modules/con_preventing-config-loss-when-using-oc-patch.adoc
index c9e7f6028..ec66b4792 100644
--- a/docs_user/modules/con_preventing-config-loss-when-using-oc-patch.adoc
+++ b/docs_user/modules/con_preventing-config-loss-when-using-oc-patch.adoc
@@ -4,9 +4,9 @@
 = Preventing configuration loss when using the `oc patch` command
 
 [role="_abstract"]
-When you use the `oc patch` command to modify a resource, the changes are applied directly to the live object in your OpenShift cluster. If you later edit the custom resource (CR) file for the resource and apply the updates by using `oc apply -f <filename>`, your previous patched changes are overwritten and lost from the resource.
+When you use `oc patch` to modify a resource, the changes are applied directly to live objects in your OpenShift cluster. If you later apply updates to the custom resource (CR) file by using `oc apply -f <filename>`, your previous patched changes are overwritten and lost from the resource.
 
-To prevent loss of configuration, you can use the `--patch-file` option to configure the patch and retain patch files. Alternatively, you can export your `openstackcontrolplane` CR after the patch is applied:
+To prevent configuration loss, use the `--patch-file` option or export your `openstackcontrolplane` CR after the patch is applied.
 
 ----
 $ oc get <resource_type> <resource_name> -o yaml > <filename>.yaml
diff --git a/docs_user/modules/con_storage-driver-certification.adoc b/docs_user/modules/con_storage-driver-certification.adoc
index c526210a8..e3ba5e5da 100644
--- a/docs_user/modules/con_storage-driver-certification.adoc
+++ b/docs_user/modules/con_storage-driver-certification.adoc
@@ -4,7 +4,7 @@
 = Storage driver certification
 
 [role="_abstract"]
-Before you adopt your {rhos_prev_long} {rhos_prev_ver} deployment to a {rhos_long} {rhos_curr_ver} deployment, confirm that your deployed storage drivers are certified for use with {rhos_acro} {rhos_curr_ver}. For information on software certified for use with {rhos_acro} {rhos_curr_ver}, see the Red Hat Ecosystem Catalog.
+Confirm that your deployed storage drivers are certified for {rhos_acro} {rhos_curr_ver} before adoption. See the Red Hat Ecosystem Catalog for certified software.
 
 [role="_additional-resources"]
 .Additional resources
diff --git a/docs_user/modules/proc_adopting-block-storage-service-with-dcn-backend.adoc b/docs_user/modules/proc_adopting-block-storage-service-with-dcn-backend.adoc
index bc8e9d2bd..eb9fd6724 100644
--- a/docs_user/modules/proc_adopting-block-storage-service-with-dcn-backend.adoc
+++ b/docs_user/modules/proc_adopting-block-storage-service-with-dcn-backend.adoc
@@ -4,7 +4,7 @@
 = Adopt the {block_storage} with multiple {Ceph} back ends (DCN)
 
 [role="_abstract"]
-Adopt the {block_storage_first_ref} in a Distributed Compute Node (DCN) deployment where multiple {CephCluster} clusters provide storage at different sites. You can deploy multiple `CinderVolume` instances, one for each availability zone, with each volume service configured to use its local {Ceph} cluster.
+Adopt the {block_storage_first_ref} in a Distributed Compute Node (DCN) deployment with multiple {CephCluster} clusters at different sites. Deploy multiple `CinderVolume` instances, one for each availability zone, with each volume service configured to use its local {Ceph} cluster.
 
 During adoption, the {block_storage} volume services that ran on edge site Compute nodes are migrated to run on {rhocp_long} at the central site. Although the control path for API requests now traverses the WAN to reach the {block_storage} running on {rhocp_long}, the data path remains local. Volume data continues to be stored in the {Ceph} cluster at each edge site. When you create a volume or clone a volume from a snapshot, the operation occurs entirely within the local {Ceph} cluster. This preserves data locality.
 
diff --git a/docs_user/modules/proc_adopting-compute-services-with-dcn-backend.adoc b/docs_user/modules/proc_adopting-compute-services-with-dcn-backend.adoc
index a599a8d44..840c8ee86 100644
--- a/docs_user/modules/proc_adopting-compute-services-with-dcn-backend.adoc
+++ b/docs_user/modules/proc_adopting-compute-services-with-dcn-backend.adoc
@@ -4,7 +4,9 @@
 = Adopting Compute services with multiple {Ceph} back ends (DCN)
 
 [role="_abstract"]
-In a Distributed Compute Node (DCN) deployment where {image_service_first_ref} and {block_storage_first_ref} services run on edge Compute nodes, each site has its own {CephCluster} cluster. The {compute_service_first_ref} nodes at each site must be configured with the {Ceph} connection details and {image_service} endpoint for their local site. Because the {image_service} has a separate API endpoint at each site, each site's `OpenStackDataPlaneNodeSet` custom resource (CR) must use a different `OpenStackDataPlaneService` CR that points to the correct {image_service}.
+Configure the edge {compute_service_first_ref} nodes at each site with the {Ceph} connection details and {image_service_first_ref} endpoint for their local site.
+
+In a Distributed Compute Node (DCN) deployment where {image_service} and {block_storage_first_ref} services run on edge Compute nodes, each site has its own {CephCluster} cluster. The {image_service} has a separate API endpoint at each site. Each site's `OpenStackDataPlaneNodeSet` custom resource (CR) must use a different `OpenStackDataPlaneService` CR that points to the correct {image_service}.
 
 In a DCN deployment, all node sets belong to a single {compute_service} cell. The central site and each edge site are separate `OpenStackDataPlaneNodeSet` resources within that cell. The per-site `OpenStackDataPlaneService` resources deliver different {Ceph} and {image_service} configurations to each node set while sharing the same cell-level {compute_service} configuration.
 
diff --git a/docs_user/modules/proc_adopting-image-service-with-block-storage-backend.adoc b/docs_user/modules/proc_adopting-image-service-with-block-storage-backend.adoc
index 7ae6c3e4b..883989c56 100644
--- a/docs_user/modules/proc_adopting-image-service-with-block-storage-backend.adoc
+++ b/docs_user/modules/proc_adopting-image-service-with-block-storage-backend.adoc
@@ -4,7 +4,7 @@
 = Adopting the {image_service} that is deployed with a {block_storage} back end
 
 [role="_abstract"]
-Adopt the {image_service_first_ref} that you deployed with a {block_storage_first_ref} back end in the {rhos_prev_long} ({OpenStackShort}) environment. The control plane `glanceAPI` instance is deployed with the following configuration. You use this configuration in the patch manifest that deploys the {image_service} with the block storage back end:
+Adopt the {image_service_first_ref} with a {block_storage_first_ref} back end by using the following configuration from the control plane `glanceAPI` instance. Use this configuration in the patch manifest that deploys the {image_service} with the block storage back end.
 
 ----
 ..
diff --git a/docs_user/modules/proc_adopting-image-service-with-dcn-backend.adoc b/docs_user/modules/proc_adopting-image-service-with-dcn-backend.adoc
index d74c899db..d6b94bb2f 100644
--- a/docs_user/modules/proc_adopting-image-service-with-dcn-backend.adoc
+++ b/docs_user/modules/proc_adopting-image-service-with-dcn-backend.adoc
@@ -4,7 +4,9 @@
 = Adopting the {image_service} with multiple {Ceph} back ends (DCN)
 
 [role="_abstract"]
-Adopt the {image_service_first_ref} in a Distributed Compute Node (DCN) deployment where multiple {CephCluster} clusters provide storage at different sites. This configuration deploys multiple `GlanceAPI` instances: a central API with access to all {Ceph} clusters, and edge APIs at each DCN site with access to their local cluster and the central cluster.
+Adopt the {image_service_first_ref} in a Distributed Compute Node (DCN) deployment with multiple {CephCluster} clusters that provide storage at different sites.
+
+This configuration deploys multiple `GlanceAPI` instances: a central API with access to all {Ceph} clusters, and edge APIs at each DCN site with access to their local cluster and the central cluster.
 
 During adoption, the {image_service} instances that ran on edge site Compute nodes are migrated to run on {rhocp_long} at the central site. Although the control path for API requests now traverses the WAN to reach the {image_service} running on {rhocp_long}, the data path remains local. Image data continues to be stored in the {Ceph} cluster at each edge site. When you create a virtual machine or volume from an image, the operation occurs at the local {Ceph} cluster. This architecture uses {Ceph} shallow copies (copy-on-write clones) to enable fast boot times without transferring image data across the WAN.
 
diff --git a/docs_user/modules/proc_adopting-image-service-with-object-storage-backend.adoc b/docs_user/modules/proc_adopting-image-service-with-object-storage-backend.adoc
index 4d26ae245..53a141d1a 100644
--- a/docs_user/modules/proc_adopting-image-service-with-object-storage-backend.adoc
+++ b/docs_user/modules/proc_adopting-image-service-with-object-storage-backend.adoc
@@ -4,7 +4,7 @@
 = Adopting the {image_service} that is deployed with a {object_storage} back end
 
 [role="_abstract"]
-Adopt the {image_service_first_ref} that you deployed with an {object_storage_first_ref} back end in the {rhos_prev_long} ({OpenStackShort}) environment. The control plane `glanceAPI` instance is deployed with the following configuration. You use this configuration in the patch manifest that deploys the {image_service} with the object storage back end:
+Adopt the {image_service_first_ref} with an {object_storage_first_ref} back end by using the following configuration from the control plane `glanceAPI` instance. Use this configuration in the patch manifest that deploys the {image_service} with the object storage back end.
 
 ----
 ..
diff --git a/docs_user/modules/proc_adopting-key-manager-service-with-proteccio-hsm.adoc b/docs_user/modules/proc_adopting-key-manager-service-with-proteccio-hsm.adoc
index e35a26ac8..da5b3ccec 100644
--- a/docs_user/modules/proc_adopting-key-manager-service-with-proteccio-hsm.adoc
+++ b/docs_user/modules/proc_adopting-key-manager-service-with-proteccio-hsm.adoc
@@ -4,7 +4,9 @@
 = Adopting the {key_manager} with Proteccio HSM integration
 
 [role="_abstract"]
-To adopt the {key_manager_first_ref} with Proteccio hardware security module (HSM) integration, you patch an existing `OpenStackControlPlane` custom resource (CR) where {key_manager} is disabled. The patch starts the service with the configuration parameters from the {rhos_prev_long} ({OpenStackShort}) environment and preserves access to existing HSM-backed secrets. You configure the {key_manager} to use both the `simple_crypto` and `pkcs11` back ends.
+Adopt the {key_manager_first_ref} with Proteccio HSM by patching the `OpenStackControlPlane` custom resource (CR) where {key_manager} is disabled. Configure the {key_manager} to use both the `simple_crypto` and `pkcs11` back ends.
+
+The patch starts the service with the configuration parameters from the {rhos_prev_long} ({OpenStackShort}) environment and preserves access to existing HSM-backed secrets.
 
 The {key_manager} Proteccio HSM adoption is complete if you see the following results:
 
diff --git a/docs_user/modules/proc_adopting-key-manager-service.adoc b/docs_user/modules/proc_adopting-key-manager-service.adoc
index 4b9aff482..097b78072 100644
--- a/docs_user/modules/proc_adopting-key-manager-service.adoc
+++ b/docs_user/modules/proc_adopting-key-manager-service.adoc
@@ -4,7 +4,9 @@
 = Adopting the {key_manager}
 
 [role="_abstract"]
-To adopt the {key_manager_first_ref}, you patch an existing `OpenStackControlPlane` custom resource (CR) where {key_manager} is disabled. The patch starts the service with the configuration parameters that are provided by the {rhos_prev_long} ({OpenStackShort}) environment. You configure the {key_manager} to use the `simple_crypto` back end.
+Adopt the {key_manager_first_ref} by patching the existing `OpenStackControlPlane` custom resource (CR) where {key_manager} is disabled. Configure the {key_manager} to use the `simple_crypto` back end.
+
+The patch starts the service with the configuration parameters that are provided by the {rhos_prev_long} ({OpenStackShort}) environment.
 
 The {key_manager} adoption is complete if you see the following results:
 
diff --git a/docs_user/modules/proc_adopting-networker-services-to-the-data-plane.adoc b/docs_user/modules/proc_adopting-networker-services-to-the-data-plane.adoc
index c223178eb..770838cb5 100644
--- a/docs_user/modules/proc_adopting-networker-services-to-the-data-plane.adoc
+++ b/docs_user/modules/proc_adopting-networker-services-to-the-data-plane.adoc
@@ -4,7 +4,7 @@
 = Adopting Networker services to the {rhos_acro} data plane
 
 [role="_abstract"]
-Adopt the Networker services in your existing {rhos_prev_long} deployment to the {rhos_long} data plane. The Networker services could be running on Controller nodes or dedicated Networker nodes. You decide which services you want to run on the Networker nodes, and create a separate `OpenStackDataPlaneNodeSet` custom resource (CR) for the Networker nodes.
+Adopt Networker services to the {rhos_long} data plane by creating a `OpenStackDataPlaneNodeSet` custom resource (CR) that includes the services to run on the Networker nodes. The Networker services could be running on Controller nodes or dedicated Networker nodes.
 
 [TIP]
 ====
diff --git a/docs_user/modules/proc_adopting-the-compute-service.adoc b/docs_user/modules/proc_adopting-the-compute-service.adoc
index b6008d3cf..fc92c24bc 100644
--- a/docs_user/modules/proc_adopting-the-compute-service.adoc
+++ b/docs_user/modules/proc_adopting-the-compute-service.adoc
@@ -4,7 +4,7 @@
 = Adopting the {compute_service}
 
 [role="_abstract"]
-To adopt the {compute_service_first_ref}, you patch an existing `OpenStackControlPlane` custom resource (CR) where the {compute_service} is disabled. The patch starts the service with the configuration parameters that are provided by the {rhos_prev_long} ({OpenStackShort}) environment. The following procedure describes a single-cell setup.
+Adopt the {compute_service_first_ref} by patching the existing `OpenStackControlPlane` custom resource (CR) where the {compute_service} is disabled. The patch starts the service with the configuration parameters from {rhos_prev_long}. This procedure describes a single-cell setup.
 
 //[NOTE]
 //The following example scenario describes a single-cell setup. Real
diff --git a/docs_user/modules/proc_adopting-the-loadbalancer-service.adoc b/docs_user/modules/proc_adopting-the-loadbalancer-service.adoc
index f995d74d7..5be427b8b 100644
--- a/docs_user/modules/proc_adopting-the-loadbalancer-service.adoc
+++ b/docs_user/modules/proc_adopting-the-loadbalancer-service.adoc
@@ -4,7 +4,9 @@
 = Adopting the {loadbalancer_service}
 
 [role="_abstract"]
-To adopt the {loadbalancer_first_ref}, you patch an existing `OpenStackControlPlane` custom resource (CR) where the {loadbalancer_service} is disabled. The patch starts the service with the configuration parameters that are provided by the {rhos_prev_long} ({OpenStackShort}) environment. After completing the data plane adoption, you must trigger a failover of existing load balancers to upgrade their amphora virtual machines to use the new image and to establish connectivity with the new control plane.
+Adopt the {loadbalancer_first_ref} by patching the existing `OpenStackControlPlane` custom resource (CR) where the {loadbalancer_service} is disabled. The patch starts the service with the configuration parameters from {rhos_prev_long}.
+
+After data plane adoption, trigger a failover of existing load balancers to upgrade amphora virtual machines to use the new image and to establish connectivity with the new control plane.
 
 .Procedure
 
diff --git a/docs_user/modules/proc_configuring-control-plane-networking-for-spine-leaf.adoc b/docs_user/modules/proc_configuring-control-plane-networking-for-spine-leaf.adoc
index 4ba45bd6a..2e2c270ea 100644
--- a/docs_user/modules/proc_configuring-control-plane-networking-for-spine-leaf.adoc
+++ b/docs_user/modules/proc_configuring-control-plane-networking-for-spine-leaf.adoc
@@ -4,7 +4,7 @@
 = Configuring control plane networking for spine-leaf topologies
 
 [role="_abstract"]
-If you are adopting a spine-leaf or Distributed Compute Node (DCN) deployment, update the control plane networking for communication across sites. Add subnets for remote sites to your existing `NetConfig` custom resource (CR) and update `NetworkAttachmentDefinition` CRs with routes to enable connectivity between the central control plane and remote sites.
+Adopt a spine-leaf or Distributed Compute Node (DCN) deployment by updating the control plane networking for communication across sites. Add subnets for remote sites to `NetConfig` custom resources (CR) and add routes to `NetworkAttachmentDefinition` CRs to enable inter-site connectivity.
 
 .Prerequisites
 
diff --git a/docs_user/modules/proc_configuring-networking-for-control-plane-services.adoc b/docs_user/modules/proc_configuring-networking-for-control-plane-services.adoc
index 1447adeff..34a3bb692 100644
--- a/docs_user/modules/proc_configuring-networking-for-control-plane-services.adoc
+++ b/docs_user/modules/proc_configuring-networking-for-control-plane-services.adoc
@@ -4,7 +4,11 @@
 = Configuring isolated networks on control plane services
 
 [role="_abstract"]
-After the NMState operator creates the desired hypervisor network configuration for isolated networks, you must configure the {rhos_prev_long} ({OpenStackShort}) services to use the configured interfaces. You define a `NetworkAttachmentDefinition` custom resource (CR) for each isolated network. In some clusters, these CRs are managed by the Cluster Network Operator, in which case you use `Network` CRs instead. For more information, see
+After the NMState operator creates the required hypervisor network configuration for isolated networks, configure {rhos_prev_long} services to use isolated network interfaces by defining `NetworkAttachmentDefinition` CRs for each network.
+
+In clusters managed by Cluster Network Operator, use `Network` CRs instead.
+
+For more information, see
 link:{defaultOCPURL}/networking/cluster-network-operator#nw-cluster-network-operator_cluster-network-operator[Cluster Network Operator] in _Networking_.
 
 .Procedure
diff --git a/docs_user/modules/proc_deploying-the-bare-metal-provisioning-service.adoc b/docs_user/modules/proc_deploying-the-bare-metal-provisioning-service.adoc
index b1b33da6c..ca4520678 100644
--- a/docs_user/modules/proc_deploying-the-bare-metal-provisioning-service.adoc
+++ b/docs_user/modules/proc_deploying-the-bare-metal-provisioning-service.adoc
@@ -4,7 +4,7 @@
 = Deploying the {bare_metal}
 
 [role="_abstract"]
-To deploy the {bare_metal_first_ref}, you patch an existing `OpenStackControlPlane` custom resource (CR) that has the {bare_metal} disabled. The `ironic-operator` applies the configuration and starts the Bare Metal Provisioning services. After the services are running, the {bare_metal} automatically begins polling the power state of the bare-metal nodes that it manages.
+Deploy the {bare_metal_first_ref} by patching the `OpenStackControlPlane` CR with the {bare_metal} disabled. The `ironic-operator` applies the configuration and starts the Bare Metal Provisioning services. The {bare_metal} then automatically polls the power state of the bare-metal nodes.
 
 [NOTE]
 By default, {rhos_acro} versions {rhos_curr_ver} and later of the {bare_metal} include a new multitenant aware role-based access control (RBAC) model. As a result, bare-metal nodes might be missing when you run the `openstack baremetal node list` command after you adopt the {bare_metal}. Your nodes are not deleted. Due to the increased access restrictions in the RBAC model, you must identify which project owns the missing bare-metal nodes and set the `owner` field on each missing bare-metal node.
diff --git a/docs_user/modules/proc_migrating-ceph-mds.adoc b/docs_user/modules/proc_migrating-ceph-mds.adoc
index 6c7e90c99..cfcfab109 100644
--- a/docs_user/modules/proc_migrating-ceph-mds.adoc
+++ b/docs_user/modules/proc_migrating-ceph-mds.adoc
@@ -4,12 +4,13 @@
 = Migrating {Ceph} MDS to new nodes within the existing cluster
 
 [role="_abstract"]
-You can migrate the MDS daemon when {rhos_component_storage_file_first_ref}, deployed with either a cephfs-native or ceph-nfs back end, is part of the overcloud deployment. The MDS migration is performed by `cephadm`, and you move the daemons placement from a hosts-based approach to a label-based approach.
+Migrate the MDS daemon from a hosts-based approach to a label-based approach. The Shared File Systems service (manila) must be deployed with either a cephfs-native or ceph-nfs back end. The MDS migration is performed by `cephadm`.
+
 ifeval::["{build}" != "upstream"]
-This ensures that you can visualize the status of the cluster and where daemons are placed by using the `ceph orch host` command. You can also have a general view of how the daemons are co-located within a given host, as described in the Red Hat Knowledgebase article https://access.redhat.com/articles/1548993[Red Hat Ceph Storage: Supported configurations].
+The label-based approach ensures that you can visualize the status of the cluster and where daemons are placed by using the `ceph orch host` command. You can also have a general view of how the daemons are co-located within a given host, as described in the Red Hat Knowledgebase article https://access.redhat.com/articles/1548993[Red Hat Ceph Storage: Supported configurations].
 endif::[]
 ifeval::["{build}" != "downstream"]
-This ensures that you can visualize the status of the cluster and where daemons are placed by using the `ceph orch host` command, and have a general view of how the daemons are co-located within a given host.
+The label-based approach ensures that you can visualize the status of the cluster and where daemons are placed by using the `ceph orch host` command, and have a general view of how the daemons are co-located within a given host.
 endif::[]
 
 .Prerequisites
diff --git a/docs_user/modules/proc_migrating-mgr-from-controller-nodes.adoc b/docs_user/modules/proc_migrating-mgr-from-controller-nodes.adoc
index 490d2002b..79a73d61f 100644
--- a/docs_user/modules/proc_migrating-mgr-from-controller-nodes.adoc
+++ b/docs_user/modules/proc_migrating-mgr-from-controller-nodes.adoc
@@ -4,7 +4,7 @@
 = Migrating Ceph Manager daemons to {Ceph} nodes
 
 [role="_abstract"]
-You must migrate your Ceph Manager daemons from the {rhos_prev_long} ({OpenStackShort}) Controller nodes to a set of target nodes. Target nodes are either existing {Ceph} nodes, or {OpenStackShort} Compute nodes if {Ceph} is deployed by {OpenStackPreviousInstaller} with a Hyperconverged Infrastructure (HCI) topology.
+Migrate Ceph Manager daemons from {rhos_prev_long} Controller nodes to a set of existing {Ceph} nodes, or Compute nodes if {Ceph} is deployed by {OpenStackPreviousInstaller} with a Hyperconverged Infrastructure (HCI) topology.
 
 [NOTE]
 The following procedure uses `cephadm` and the Ceph Orchestrator to drive the Ceph Manager migration, and the Ceph spec to modify the placement and reschedule the Ceph Manager daemons. Ceph Manager is run in an active/passive state. It also provides many modules, including the Ceph Orchestrator. Every potential module, such as the Ceph Dashboard, that is provided by `ceph-mgr` is implicitly migrated with Ceph Manager.
diff --git a/docs_user/modules/proc_migrating-the-rgw-backends.adoc b/docs_user/modules/proc_migrating-the-rgw-backends.adoc
index 80a1a9983..558278dd8 100644
--- a/docs_user/modules/proc_migrating-the-rgw-backends.adoc
+++ b/docs_user/modules/proc_migrating-the-rgw-backends.adoc
@@ -4,7 +4,10 @@
 = Migrating the {Ceph} RGW back ends
 
 [role="_abstract"]
-You must migrate your Ceph Object Gateway (RGW) back ends from your Controller nodes to your {Ceph} nodes. To ensure that you distribute the correct amount of services to your available nodes, you use `cephadm` labels to refer to a group of nodes where a given daemon type is deployed. For more information about the cardinality diagram, see xref:ceph-daemon-cardinality_migrating-ceph[{Ceph} daemon cardinality].
+Migrate Ceph Object Gateway (RGW) back ends from Controller nodes to {Ceph} nodes. To distribute the correct amount of services to your available nodes, use `cephadm` labels to refer to a group of nodes where a given daemon type is deployed.
+
+For more information about the cardinality diagram, see xref:ceph-daemon-cardinality_migrating-ceph[{Ceph} daemon cardinality].
+
 The following procedure assumes that you have three target nodes, `cephstorage-0`, `cephstorage-1`, `cephstorage-2`.
 
 .Procedure
diff --git a/docs_user/modules/proc_reusing-existing-subnet-ranges.adoc b/docs_user/modules/proc_reusing-existing-subnet-ranges.adoc
index 65c20cd2b..f05803a41 100644
--- a/docs_user/modules/proc_reusing-existing-subnet-ranges.adoc
+++ b/docs_user/modules/proc_reusing-existing-subnet-ranges.adoc
@@ -4,7 +4,7 @@
 = Reusing existing subnet ranges
 
 [role="_abstract"]
-You can reuse existing subnet ranges if they have enough IP addresses to allocate to the new control plane services. You configure the new control plane services to use the same subnet as you used in the {rhos_prev_long} ({OpenStackShort}) environment, and configure the allocation pools that are used by the new services to exclude IP addresses that are already allocated to existing cluster nodes. By reusing existing subnets, you avoid additional link local route configuration between the existing and new subnets.
+Configure new control plane services to reuse the subnets from the {rhos_prev_long} ({OpenStackShort}) environment, and to exclude IP addresses that are already allocated to existing cluster nodes. This avoids additional link local route configuration between the existing and new subnets.
 
 ifeval::["{build_variant}" != "ospdo"]
 If your existing subnets do not have enough IP addresses in the existing subnet ranges for the new control plane services, you must create new subnet ranges.
diff --git a/docs_user/modules/proc_updating-shiftstack-credentials.adoc b/docs_user/modules/proc_updating-shiftstack-credentials.adoc
index c6075239a..a4591859e 100644
--- a/docs_user/modules/proc_updating-shiftstack-credentials.adoc
+++ b/docs_user/modules/proc_updating-shiftstack-credentials.adoc
@@ -4,7 +4,7 @@
 = Updating {OpenShiftShort} on {OpenStackShort} credentials and recovering the image-registry operator
 
 [role="_abstract"]
-After {rhos_long} adoption, any {rhocp_long} clusters that were deployed on {rhos_prev_long} ({OpenStackShort}) 17.1 with installer-provisioned infrastructure still reference the {OpenStackPreviousInstaller} keystone endpoint in their cloud credentials. To authenticate with keystone and avoid timeouts, update the credentials and image-registry operator.
+After adoption, update {rhocp_long} clusters with installer-provisioned infrastructure to reference the new keystone endpoint in the cloud credentials instead of the {OpenStackPreviousInstaller} endpoint. This facilitates authentication with keystone and avoids timeouts.
 
 [IMPORTANT]
 Run all commands against the guest {OpenShiftShort} cluster that is running on {OpenStackShort} VMs, not the underlying {rhos_acro} host cluster.
diff --git a/docs_user/modules/ref_adoption-duration-and-impact.adoc b/docs_user/modules/ref_adoption-duration-and-impact.adoc
index aa576e3bd..25b2ea330 100644
--- a/docs_user/modules/ref_adoption-duration-and-impact.adoc
+++ b/docs_user/modules/ref_adoption-duration-and-impact.adoc
@@ -4,7 +4,9 @@
 = Adoption duration and impact
 
 [role="_abstract"]
-The durations in the following table were recorded in a test environment that consisted of 228 Compute nodes and 3 Networker nodes. To accurately estimate the adoption duration for each task, perform these procedures in a test environment with hardware that is similar to your production environment. Ensure that you set up the {rhocp_long}  environment and install the Operators before testing.
+The durations in the following table were recorded in a test environment that consisted of 228 Compute nodes and 3 Networker nodes. To accurately estimate the duration for each task, perform these procedures in a test environment with similar hardware to your production environment.
+
+Set up the {rhocp_long} environment and install the Operators before testing.
 
 [IMPORTANT]
 Durations can vary significantly based on the content of your environment, for example, the size of your service databases or the number of services. The durations represent raw execution time. They do not include human operator activity.
diff --git a/docs_user/modules/ref_ceph-daemon-cardinality.adoc b/docs_user/modules/ref_ceph-daemon-cardinality.adoc
index 391bc0812..0a9aae3b6 100644
--- a/docs_user/modules/ref_ceph-daemon-cardinality.adoc
+++ b/docs_user/modules/ref_ceph-daemon-cardinality.adoc
@@ -4,12 +4,15 @@
 = {Ceph} daemon cardinality
 
 [role="_abstract"]
-{Ceph} {CephVernum} and later applies strict constraints in the way daemons can be colocated within the same node.
+{Ceph} {CephVernum} and later applies strict constraints in the way daemons can be colocated within the same node. Your topology depends on the available hardware and the amount of Red Hat Ceph Storage services in the Controller nodes that you retire.
+
+The amount of services that you can migrate depends on the amount of available nodes in the cluster.
+
+The following diagrams show the distribution of Red Hat Ceph Storage daemons on Red Hat Ceph Storage nodes where at least 3 nodes are required.
+
 ifeval::["{build}" != "upstream"]
 For more information, see the Red Hat Knowledgebase article link:https://access.redhat.com/articles/1548993[Red Hat Ceph Storage: Supported configurations].
 endif::[]
-Your topology depends on the available hardware and the amount of {Ceph} services in the Controller nodes that you retire.
-The amount of services that you can migrate depends on the amount of available nodes in the cluster. The following diagrams show the distribution of {Ceph} daemons on {Ceph} nodes where at least 3 nodes are required.
 
 * The following scenario includes only RGW and RBD, without the {Ceph} dashboard:
 +