You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: articles/application-gateway/retirement-faq.md
+9-9Lines changed: 9 additions & 9 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -21,25 +21,25 @@ New Customers won't be allowed to create V1 from 1 July 2023 onwards. However, a
21
21
22
22
### What happens to existing Application Gateway V1 after 28 April 2026?
23
23
24
-
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 cannot be guaranteed as our teams begin the process of cleaning up and decommissioning the hardware that supported V1 SKUs of Application Gateway.
24
+
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.
25
25
26
26
### Does this migration plan affect any of my existing workloads that run on Application Gateway V1 SKU?
27
27
28
-
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 will begin blocking the data path and subsequently deleting the resources.
28
+
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.
29
29
30
30
### What happens to my V1 application gateways if I don’t plan on migrating soon?
31
31
32
32
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.
33
33
34
34
### Does the retirement of Basic SKU Public IPs in September 2025 affect my existing V1 Application Gateways?
35
35
36
-
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.
36
+
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.
37
37
38
38
### How do I migrate my application gateway V1 to V2 SKU?
39
39
40
40
If you have an Application Gateway V1, [Migration from v1 to v2](./migrate-v1-v2.md) can be currently done in two stages:
41
41
- Stage 1: Migrate the configuration - Detailed instruction for Migrating the configuration can be found [here](./migrate-v1-v2.md#configuration-migration).
42
-
- 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).
42
+
- 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).
43
43
44
44
### Can Microsoft migrate this data for me?
45
45
@@ -62,9 +62,9 @@ Yes, see [Caveats/Limitations](./migrate-v1-v2.md#caveatslimitations).
62
62
63
63
### Does Application Gateway V2 support NTLM or Kerberos authentication?
64
64
65
-
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).
65
+
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).
66
66
67
-
### 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?
67
+
### 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?
68
68
69
69
Certificate Validation Behavior in Application Gateway
70
70
@@ -82,23 +82,23 @@ Yes.
82
82
83
83
### Does the Azure PowerShell script also switch over the traffic from my v1 gateway to the newly created v2 gateway?
84
84
85
-
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.
85
+
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.
86
86
87
87
### 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?
88
88
89
89
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.
90
90
91
91
### Can I create an Application Gateway V2 in the same subnet as an existing V1 gateway?
92
92
93
-
No, V1 and V2 gateways cannot 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.
93
+
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.
94
94
95
95
### I configured my v1 gateway to send logs to Azure storage. Does the script replicate this configuration for v2 as well?
96
96
97
97
No, the script doesn't replicate this configuration for v2. You must add the log configuration separately to the migrated v2 gateway.
98
98
99
99
### Does this script support certificate uploaded to Azure Key Vault?
100
100
101
-
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.
101
+
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.
102
102
103
103
### I ran into some issues with using this script. How can I get help?
0 commit comments