Microsoft has announced that Azure Application Gateway v1 will be retired on April 28, 2026. Users are encouraged to transition to Azure Application Gateway v2, the primary service moving forward. The new customers aren’t allowed to create v1 from July 1, 2023. However, existing V1 customers can continue creating resources until August 2024. Application Gateway V1 must be stopped before the deadline. Failure to migrate to Application Gateway V2 will result in a forced deletion. Those who have not migrated will be notified of the timeline for deletion and will be forcefully removed after that.
The newest Application Gateway SKU provides customers with various benefits and added features:
- Autoscaling allows your application gateway to adjust its capacity based on your traffic pattern, saving you money by not having to run it at peak capacity.
- Zone redundancy ensures your application gateway can withstand zonal failures, making it more resilient.
- The Static VIP feature guarantees that your endpoint address will stay the same throughout its lifecycle.
- With Header Rewrite, you can update HTTP request and response headers without touching your application code, enabling a variety of scenarios such as HSTS support, secure cookie handling, and cache control.
- Faster provisioning and configuration updates save you time, while improved performance reduces overall costs.
- It supports Azure Key vault, Azure AKS ingress controller, and private link usage.
To complete the migration process, you must transfer the configurations and redirect the application traffic. You have two options for the configuration migration: manually create the new application gateway v2 SKU or utilize Azure scripts to automate the setup process. You must take action and choose one of these options to ensure a successful migration.
Option 1: Manual steps.
To proceed, customers can create a new application gateway resource and its associated WAF rules, IP address, and other settings. At the same time, customers can migrate independently by manually configuring new V2 gateways with the same setup as their V1 gateways.
Disadvantages: The process can be challenging, lengthy, and susceptible to mistakes because of the multiple configuration touchpoints involved.
Option 2: Automated script.
The PowerShell script needs some inputs to copy the configuration from a V1 gateway to a new V2 gateway. The process is seamless, and the V2 gateway will be created automatically. The script can be downloaded from the PowerShell Gallery.
The Azure PowerShell script creates a new v2 gateway with an appropriate size to handle the traffic on your existing v1 gateway. Auto-scaling is turned off by default, but you can enable Auto-Scaling when you run the script. The script doesn’t replicate the configurations of sending logs to Azure storage for v2. You must add the log configuration separately to the migrated v2 gateway. The script creates a subnet for you if it doesn’t exist, and if it exists, it will use the existing one (make sure the subnet is either empty, contains only V2 Gateway, if any, and has enough available IPs).
The ultimate responsibility of transitioning traffic to a new application gateway lies solely with the customer. The simple verification steps for the migration should be as below:
- Login into the Azure portal.
- Verify that the application gateway and WAF are created as intended.
- Migrate DNS configuration to the new public IP address.
I trust you have successfully understood the steps in migrating the Azure Application Gateway v2 SKU from its previous version.
Santhosh has over 15 years of experience in the IT organization. Working as a Cloud Infrastructure Architect and has a wide range of expertise in Microsoft technologies, with a specialization in public & private cloud services for enterprise customers. My varied background includes work in cloud computing, virtualization, storage, networks, automation and DevOps.
