Merge pull request #310424 from MJyot/main

Update retirement FAQ for Application Gateway V1

Author: prmerger-automator[bot]

articles/application-gateway/migrate-v1-v2.md

@@ -46,6 +46,9 @@ This article primarily helps with the configuration migration. Client traffic mi
 
 [!INCLUDE [updated-for-az](~/reusable-content/ce-skilling/azure/includes/updated-for-az.md)]
 
+> [!NOTE]
+> If NetworkIsolation is enabled on the subscription, all Application Gateway v2 deployments whether public‑only or  private‑only must be deployed in a subnet delegated to Microsoft.Network/applicationGateways.  Use the following [steps to set up subnet delegation](/azure/virtual-network/manage-subnet-delegation?tabs=manage-subnet-delegation-portal).
+
 ## Configuration migration
 The configuration migration focuses on setting up the new V2 gateway with the settings from your existing V1 environment. We provide two Azure PowerShell scripts designed to facilitate the migration of configurations from V1 (Standard or WAF) to V2 (Standard_V2 or WAF_V2) gateways. These scripts help streamline the transition process by automating key deployment and configuration tasks.
 

articles/application-gateway/retirement-faq.md

@@ -21,33 +21,25 @@ New Customers won't be allowed to create V1 from 1 July 2023 onwards. However, a
 
 ### What happens to existing Application Gateway V1 after 28 April 2026?
 
-Once the deadline arrives V1 gateways aren't supported. Any V1 SKU resources that are still active are stopped, and force deleted.
-
-### What is the definition of a new customer on Application Gateway V1 SKU?
-
-Customers who didn't have Application Gateway V1 SKU in their subscriptions as of 4 July 2023 are considered as new customers. These customers aren't able to create new V1 gateways in subscriptions that didn't have an existing V1 gateway as of 4 July 2023.
-
-### What is the definition of an existing customer on Application Gateway V1 SKU?
-
-Customers who had active or stopped but allocated Application Gateway V1 SKU in their subscriptions as of  4 July 2023, are considered existing customers. These customers get until end of August, 2024 to create new V1 application gateways in their existing subscriptions and until April 28,2026 to migrate their V1 gateways to V2.
+After April 28th 2026, V1 SKU will no longer be supported, and no SLA will be provided for customers using this SKU of Application Gateway. Traffic passing through V1 SKUs after retirement can't be guaranteed as our teams begin the process of cleaning up and decommissioning the hardware that supported V1 SKUs of Application Gateway. 
 
 ### Does this migration plan affect any of my existing workloads that run on Application Gateway V1 SKU?
 
-Until April 28, 2026, existing Application Gateway V1 deployments are supported. After April 28, 2026, any V1 SKU resources that are still active are stopped, and force deleted.
+Until April 28, 2026, existing Application Gateway V1 deployments are supported. After April 28, 2026, any V1 SKU resources that are still active will no longer receive  patches, support, or SLA coverage. Workloads running on V1 will face service disruption, as we'll begin blocking the data path and subsequently deleting the resources. 
 
 ### What happens to my V1 application gateways if I don’t plan on migrating soon?
 
-On April 28, 2026, the V1 gateways are fully retired and all active AppGateway V1s are stopped & deleted. To prevent business impact, we highly recommend starting to plan your migration at the earliest and complete it before April 28, 2026.
+On April 28, 2026, the V1 gateways are fully retired and all active AppGateway V1s will no longer receive  patches, support, or SLA coverage and will face service disruptions. To prevent business impact, we highly recommend starting to plan your migration at the earliest and complete it before April 28, 2026.
 
 ### Does the retirement of Basic SKU Public IPs in September 2025 affect my existing V1 Application Gateways?
 
-While the Basic SKU Public IPs are scheduled for retirement by September 2025, the Basic IP resources linked to Application Gateway V1 deployments will not be impacted until the retirement of V1 Application Gateways. This will be handled by Microsoft and needs no customer intervention.
+While the Basic SKU Public IPs are scheduled for retirement by September 2025, the Basic IP resources linked to Application Gateway V1 deployments wo'nt be impacted until the retirement of V1 Application Gateways. This will be handled by Microsoft and needs no customer intervention.
 
 ### How do I migrate my application gateway V1 to V2 SKU?
 
 If you have an Application Gateway V1, [Migration from v1 to v2](./migrate-v1-v2.md) can be currently done in two stages:
 - Stage 1: Migrate the configuration - Detailed instruction for Migrating the configuration can be found [here](./migrate-v1-v2.md#configuration-migration).
-- Stage 2: Migrate the client traffic -Client traffic migration varies depending on your specific environment. We now have a [powershell script to retain the Public IP from V1 in V2](./migrate-v1-v2.md#public-ip-retention-script).High level guidelines on traffic migration are provided [here](./migrate-v1-v2.md#traffic-migration-recommendations).
+- Stage 2: Migrate the client traffic -Client traffic migration varies depending on your specific environment. We now have a [PowerShell script to retain the Public IP from V1 in V2](./migrate-v1-v2.md#public-ip-retention-script). High level guidelines on traffic migration are provided [here](./migrate-v1-v2.md#traffic-migration-recommendations).
 
 ### Can Microsoft migrate this data for me?
 
@@ -70,9 +62,9 @@ Yes, see [Caveats/Limitations](./migrate-v1-v2.md#caveatslimitations).
 
 ### Does Application Gateway V2 support NTLM or Kerberos authentication?
 
-Yes. Application Gateway v2 now supports proxying requests with NTLM or Kerberos authentication.For more information, see [Dedicated backend connection](configuration-http-settings.md#dedicated-backend-connection).
+Yes. Application Gateway v2 now supports proxying requests with NTLM or Kerberos authentication. For more information, see [Dedicated backend connection](configuration-http-settings.md#dedicated-backend-connection).
 
-### How are backend certificate behaviours different between Application Gateway V1 and V2 SKUs? How should I manage the migration with the differences in behavior of backend certificate validations between V1 and V2 SKUs?
+### How are backend certificate behaviors different between Application Gateway V1 and V2 SKUs? How should I manage the migration with the differences in behavior of backend certificate validations between V1 and V2 SKUs?
 
 Certificate Validation Behavior in Application Gateway
 
@@ -90,19 +82,23 @@ Yes.
 
 ### Does the Azure PowerShell script also switch over the traffic from my v1 gateway to the newly created v2 gateway?
 
-No, the Azure PowerShell script only migrates the configuration. Actual traffic migration is your responsibility and under your control.You can use the [public IP retention script](./migrate-v1-v2.md#public-ip-retention-script) to retain the Public IP from V1 in V2.This operation has a downtime of 1-5 minutes. 
+No, the Azure PowerShell script only migrates the configuration. Actual traffic migration is your responsibility and under your control. You can use the [public IP retention script](./migrate-v1-v2.md#public-ip-retention-script) to retain the Public IP from V1 in V2. This operation has a downtime of 1-5 minutes. 
 
 ### Is the new v2 gateway created by the Azure PowerShell script sized appropriately to handle all of the traffic that is served by my v1 gateway?
 
 The Azure PowerShell script creates a new v2 gateway with an appropriate size to handle the traffic on your existing v1 gateway. Autoscaling is disabled by default, but you can enable autoscaling when you run the script.
 
+### Can I create an Application Gateway V2 in the same subnet as an existing V1 gateway?
+
+No, V1 and V2 gateways can't coexist in the same subnet. Each gateway type requires its own dedicated subnet within the virtual network. If you plan to migrate from V1 to V2, you must create a new subnet for the V2 gateway and ensure sufficient IP address space is allocated.
+
 ### I configured my v1 gateway  to send logs to Azure storage. Does the script replicate this configuration for v2 as well?
 
 No, the script doesn't replicate this configuration for v2. You must add the log configuration separately to the migrated v2 gateway.
 
 ### Does this script support certificate uploaded to Azure Key Vault?
 
-Yes, you can download the certificate from Keyvault and provide it as input to the migration script.The [enchanced cloning script](./migrate-v1-v2.md#1-enhanced-cloning-script) automatically copies all the SSL certs from V1 to the newly created V2.
+Yes, you can download the certificate from Keyvault and provide it as input to the migration script. The [enhanced cloning script](./migrate-v1-v2.md#1-enhanced-cloning-script) automatically copies all the SSL certs from V1 to the newly created V2.
 
 ### I ran into some issues with using this script. How can I get help?
 

articles/application-gateway/v1-retirement.md

@@ -21,7 +21,7 @@ We announced the deprecation of Application Gateway V1 on **April 28 ,2023**. Be
 
 - Deprecation announcement: April 28 ,2023 
 
--	No new subscriptions for V1 deployments: July 1,2023 onwards - Application Gateway V1 is no longer available for deployment on subscriptions without V1 gateways(Refer to [FAQ](./retirement-faq.md#what-is-the-definition-of-a-new-customer-on-application-gateway-v1-sku) for details) from July 1 2023 onwards.
+-	No new subscriptions for V1 deployments: July 1,2023 onwards - Application Gateway V1 is no longer available for deployment on subscriptions without V1 gateways from July 1 2023 onwards.
 
 - No new V1 deployments: Sept 1, 2024 - V1 creation is stopped completely for all customers 1 September 2024 onwards.