diff --git a/content/ngf/how-to/data-plane-configuration.md b/content/ngf/how-to/data-plane-configuration.md
index a18725ce5..1fb00c9c2 100644
--- a/content/ngf/how-to/data-plane-configuration.md
+++ b/content/ngf/how-to/data-plane-configuration.md
@@ -397,6 +397,16 @@ Each patch has two fields:
 
 Patches are applied in the order they appear in the array. Later patches can override fields set by earlier patches.
 
+**Which patch type should I use?**
+
+- **StrategicMerge** is the default and most user-friendly for Kubernetes-native resources like Deployments and Services. It understands lists and merges fields intelligently (for example, merging containers by name). Use this for most use cases.
+- **Merge** (JSON Merge Patch) is simpler and works well for basic object merges, but does not handle lists or complex merging. Use this if you want to replace entire fields or for non-Kubernetes-native resources.
+- **JSONPatch** is the most powerful and flexible, allowing you to add, remove, or replace specific fields using RFC 6902 operations. Use this for advanced or fine-grained changes, but it is more verbose and error-prone.
+
+If unsure, start with StrategicMerge. Use JSONPatch only if you need to surgically modify fields that cannot be addressed by the other patch types.
+
+Patches are applied after all other NginxProxy configuration is rendered. Invalid patches will result in a validation error and will not be applied.
+
 #### Example: Configure Service with session affinity
 
 ```yaml
@@ -485,18 +495,4 @@ spec:
               publishNotReadyAddresses: true
 ```
 
-In this example, the final Service will have `sessionAffinity: None` and `publishNotReadyAddresses: true` because the second patch overrides the values from the first patch.
-
-{{< note >}}
-**Which patch type should I use?**
-
-- **StrategicMerge** is the default and most user-friendly for Kubernetes-native resources like Deployments and Services. It understands lists and merges fields intelligently (e.g., merging containers by name). Use this for most use cases.
-- **Merge** (JSON Merge Patch) is simpler and works well for basic object merges, but does not handle lists or complex merging. Use this if you want to replace entire fields or for non-Kubernetes-native resources.
-- **JSONPatch** is the most powerful and flexible, allowing you to add, remove, or replace specific fields using RFC 6902 operations. Use this for advanced or fine-grained changes, but it is more verbose and error-prone.
-
-If unsure, start with StrategicMerge. Use JSONPatch only if you need to surgically modify fields that cannot be addressed by the other patch types.
-
-Patches are applied after all other NginxProxy configuration is rendered. Invalid patches will result in a validation error and will not be applied.
-{{< /note >}}
-
----
+In this example, the final Service will have `sessionAffinity: None` and `publishNotReadyAddresses: true` because the second patch overrides the values from the first patch.
\ No newline at end of file
diff --git a/content/ngf/install/upgrade-version.md b/content/ngf/install/upgrade-version.md
index 4d6e06f89..b586bec06 100644
--- a/content/ngf/install/upgrade-version.md
+++ b/content/ngf/install/upgrade-version.md
@@ -13,12 +13,11 @@ It covers the necessary steps for minor versions as well as major versions (such
 
 Many of the nuances in upgrade paths relate to how custom resource definitions (CRDs) are managed.
 
-
 ## Minor NGINX Gateway Fabric upgrades
 
-{{< call-out "important" >}}
-Upgrading from v2.0.x to v2.1 requires the NGINX Gateway Fabric control plane to be uninstalled and then reinstalled to avoid any downtime to user traffic. CRDs do not need to be removed. The NGINX data plane deployment is not affected by this process, and traffic should still flow uninterrupted. The steps are described below.
-{{< /call-out >}}
+Upgrading from v2.0.x to v2.1 requires the NGINX Gateway Fabric control plane to be uninstalled and then reinstalled to avoid any downtime to user traffic. 
+
+CRDs **do not** need to be removed. The NGINX data plane deployment **is not** affected by this process, and traffic should still flow uninterrupted.
 
 {{< call-out "important" >}} NGINX Plus users need a JWT secret before upgrading from version 1.4.0 to 1.5.x.
 
@@ -26,7 +25,6 @@ Follow the steps in [Set up the JWT]({{< ref "/ngf/install/nginx-plus.md#set-up-
 
 {{< /call-out >}}
 
-
 ### Upgrade Gateway resources
 
 To upgrade your Gateway API resources, take the following steps: