Frequently asked questions about Application Gateway V1 retirement

Application Gateway V1 is retired as of 28 April 2026.

This article answers commonly asked questions about the V1 retirement timeline, what to expect after retirement, and how to migrate from V1 to V2. For migration guidance, see Migrate Azure Application Gateway and Web Application Firewall from V1 to V2.

Common questions about V1 retirement

What happens to existing Application Gateway V1 resources after April 28, 2026?

After April 28, 2026, Microsoft will no longer support Application Gateway V1 resources. There's no service-level agreement (SLA) for customers who use this version. As Microsoft begins decommissioning the hardware that supports V1, traffic passing through V1 resources can't be guaranteed.

How does this migration plan affect my existing workloads that run on Application Gateway V1? What happens to my V1 application gateways if I don't migrate?

Until April 28, 2026, Microsoft supports existing Application Gateway V1 deployments. After April 28, 2026, Microsoft will no longer provide patches, support, or SLA coverage for active V1 resources. Workloads running on V1 face service disruption as Microsoft blocks the data path and deletes the resources. To prevent business impact, migrate the remaining V1 gateways as soon as possible.

Common questions about migration from V1 to V2

How do I migrate my application gateway V1 to V2?

If you have an Application Gateway V1 deployment, you can migrate from V1 to V2 in two stages:

• Stage 1: Migrate the configuration. For detailed instructions, see the migration guide.
• Stage 2: Migrate the client traffic. Migration of client traffic varies depending on your environment. See Public IP retention script and Traffic migration recommendations.

Can Microsoft migrate my data for me?

No, Microsoft can't migrate your data for you. You must migrate your data by using the self-serve options.

Application Gateway V1 is built on legacy components, and Azure deploys gateways in many ways. That's why your involvement is required for migration. By handling the migration yourself, you can plan the work during a maintenance window and help ensure minimal downtime for your applications.

How long does migration take?

The time required for migration depends on the complexity of your deployment. Plan for the migration to take up to a couple of months.

Are there any limitations with the Azure PowerShell script to migrate the configuration from V1 to V2?

Yes. See Caveats and limitations.

Does Application Gateway V2 support NTLM or Kerberos authentication?

Yes. Application Gateway V2 supports proxying requests with NTLM or Kerberos authentication. For more information, see Dedicated backend connection.

How are backend certificate behaviors different between Application Gateway V1 and V2?

Application Gateway V1 uses authentication certificates. This mechanism performs an exact match between the certificate configured on Application Gateway and the certificate from the backend server. V1 also supports default or fallback certificates if no Server Name Indication (SNI) is available during the TLS handshake.

By default, Application Gateway V2 performs a more comprehensive validation. It verifies the complete certificate chain and the subject name of the backend server certificate. For more information, see Backend TLS connection.

How should I manage the migration with the differences in behavior of backend certificate validations between V1 and V2?

When you migrate from V1 to V2, you might need to adjust your configuration because of the differences in certificate validation behavior. Use the backend HTTPS validation controls available in V2 to temporarily disable validation during migration.

Disable validation only as a temporary measure to facilitate migration. For production environments, re-enable full validation to maintain security.

Do this article and the Azure PowerShell script also apply to Azure Web Application Firewall?

Yes.

Does the Azure PowerShell script switch over the traffic from my V1 gateway to the newly created V2 gateway?

No, the Azure PowerShell script only migrates the configuration. You're responsible for, and in control of, actual traffic migration.

You can use the public IP retention script to retain the public IP from V1 in V2. This operation has a downtime of one to five minutes.

Is the new V2 gateway that the Azure PowerShell script creates sized appropriately to handle the traffic on 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 a V2 gateway 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 that you allocate sufficient IP address space.

I configured my V1 gateway to send logs to Azure Storage. Does the script replicate this configuration for V2?

No, the script doesn't replicate this configuration for V2. You must add the log configuration separately to the migrated V2 gateway.

Does the script support certificates uploaded to Azure Key Vault?

Yes, you can download the certificate from Azure Key Vault and provide it as input to the migration script. The enhanced cloning script automatically copies all the TLS/SSL certificates from V1 to the newly created V2 gateway.

I ran into some problems with the migration. How can I get help?

Post problems and questions about migration to Microsoft Q&A for Application Gateway, with the keyword V1Migration.

If you have a support contract, you can also open a support ticket. For more information about Azure support, see Azure support options.