update ref links and version values

Author: salonichf5

content/ngf/installation/installing-ngf/upgrading-ngf.md

@@ -7,35 +7,35 @@ product: NGF
 docs: DOCS-0000
 ---
 
-This guide provides step-by-step instructions for upgrading NGINX Gateway Fabric from version 1.x to 2.0, highlighting key architectural changes, expected downtime, and important considerations for custom resource definitions.
+This guide provides step-by-step instructions for upgrading NGINX Gateway Fabric from version 1.x to 2.x, highlighting key architectural changes, expected downtime, and important considerations for custom resource definitions.
 
 ---
 
 ### Upgrade from v1.x to v2.0
 
-To upgrade NGINX Gateway Fabric from version 1.6.2 to the latest version 2.0.0, you must uninstall the existing NGINX Gateway Fabric CRDs and deployment, and perform a fresh installation. This will cause brief downtime during the upgrade process.
+To upgrade NGINX Gateway Fabric from version 1.x to the new architecture in version 2.x, you must uninstall the existing NGINX Gateway Fabric CRDs and deployment, and perform a fresh installation. This will cause brief downtime during the upgrade process.
 
 {{<note>}} You do not need to uninstall the Gateway API CRDs during the upgrade. These resources are compatible with the new NGINX Gateway Fabric version. {{</note>}}
 
-#### Uninstalling previous NGINX Gateway Fabric v1.6.x
+#### Uninstalling previous NGINX Gateway Fabric v1.x
 
-To remove the previous version 1.6.x of NGINX Gateway Fabric, follow these steps:
+To remove the previous version 1.x of NGINX Gateway Fabric, follow these steps:
 
 1. Run the following command to uninstall NGINX Gateway Fabric from the `nginx-gateway` namespace, updating `ngf` to your release name if different:
 
 ```shell
 helm uninstall ngf -n nginx-gateway 
 ```
 
-1. To remove the CRDs associated with NGINX Gateway Fabric version 1.6.x, run the following command:
+1. To remove the CRDs associated with NGINX Gateway Fabric version 1.x, run the following command:
 
 ```shell
-kubectl delete -k "github.com/nginxinc/nginx-gateway-fabric/config/crd?ref=< ngf-version >"
+kubectl apply -f https://raw.githubusercontent.com/nginx/nginx-gateway-fabric/v{{< version-ngf >}}/deploy/crds.yaml
 ```
 
-#### Install using Helm
+{{<tabs name="install-helm">}}
 
-Follow these steps to install NGINX Gateway Fabric v2.0.0 using helm:
+Follow these steps to install NGINX Gateway Fabric v2.x using helm:
 
 1. First, apply the new CRDs with the following command:
 
@@ -49,11 +49,11 @@ kubectl apply -k "github.com/nginxinc/nginx-gateway-fabric/config/crd?ref=< ngf-
 helm install ngf oci://ghcr.io/nginx/charts/nginx-gateway-fabric --create-namespace -n nginx-gateway
 ```
 
-For additional customization options during the helm installation process, take a look at [Installation with Helm](../../installation/installing-ngf/helm.md).
+For additional customization options during the helm installation process, take a look at [Installation with Helm]({{< ref "../../installation/installing-ngf/helm.md" >}}).
 
-#### Install using Manifests
+{{<tabs name="install-manifests">}}
 
-Follow these steps to install NGINX Gateway Fabric v2.0.0 using manifests:
+Follow these steps to install NGINX Gateway Fabric v2.x using manifests:
 
 1.  First, apply the new CRDs with the following command:
 
@@ -67,30 +67,28 @@ kubectl apply -f https://raw.githubusercontent.com/nginx/nginx-gateway-fabric/v{
 kubectl apply -f https://raw.githubusercontent.com/nginx/nginx-gateway-fabric/v{{< ngf-version >}}/deploy/default/deploy.yaml
 ```
 
-For additional customization options during the installation process using manifests, take a look at [Installation with Manifests](../../installation/installing-ngf/manifests.md)
+For additional customization options during the installation process using manifests, take a look at [Installation with Manifests]({{< ref "../../installation/installing-ngf/manifests.md" >}})
 
 ---
 
 ### Architecture changes
 
 With this release, NGINX Gateway Fabric adopts a new architecture that separates the control plane and data plane into independent deployments. This separation improves scalability, security, and operational clarity.
 
-The control plane is a Kubernetes controller built with `controller-runtime`. It watches Gateway API and Kubernetes resources (e.g., Services, Endpoints, Secrets) and dynamically provisions NGINX data plane deployments for each Gateway.
+The control plane is a Kubernetes controller that watches Gateway API and Kubernetes resources (e.g., Services, Endpoints, Secrets) and dynamically provisions NGINX data plane deployments for each Gateway.
 
 NGINX configurations are generated by the control plane and securely delivered to the data planes via gRPC, using the NGINX Agent. TLS is enabled by default, with optional integration with `cert-manager`.
 
 Each data plane pod runs NGINX alongside the Agent, which applies config updates and handles reloads without shared volumes or signals. This design ensures dynamic, per-Gateway traffic management and operational isolation.
 
 New fields have been added to the `NginxProxy` resource to configure infrastructure-related settings for data plane deployments. You can modify the `NginxProxy` resource at either the Gateway or GatewayClass level. These new fields provide the flexibility to customize deployment and service configurations.
 
-For detailed instructions on how to modify these settings, refer to the [Configure infrastructure-related settings](../../how-to/data-plane-configuration.md#configure-infrastructure-related-settings) guide.
+For detailed instructions on how to modify these settings, refer to the [Configure infrastructure-related settings]({{< ref "../../how-to/data-plane-configuration.md#configure-infrastructure-related-settings" >}}) guide.
 
 ---
 
-### Key links for the version 2.0.0 update
+### Key links for the version 2.x update
 
-- To read more on [modifying data plane configuration](../../how-to/data-plane-configuration.md)
-- To read more on [modifying control plane configuration](../../how-to/control-plane-configuration.md)
-- To adding secure [authentication to control plane and data planes](./control-plane-certs.md)
-- For detailed information on [architecture changes](../../overview//gateway-architecture.md)
-- For detailed [API reference](../../reference/api.md)
+- To read more on [modifying data plane configuration]({{< ref "../../how-to/data-plane-configuration.md" >}})
+- To adding secure [authentication to control plane and data planes]({{< ref "./control-plane-certs.md" >}})
+- For detailed [API reference]({{< ref "../../reference/api.md" >}})