Azure App Service Environment (ASE) v3 Migration Guide

tamami.I Web Developer
5 min readJul 22, 2024

--

1. Scope of This Article

This article serves as a guide for migrating to the latest version of Azure App Service Environment (ASE) v3. It covers an overview of ASE v3, the background and necessity of the migration, the resources impacted, and the migration paths available. By understanding the ASE v3 migration process, you will be able to choose the most suitable migration method.

2. Background

The latest version of App Service Environment v3, which enhances speed, scalability, and VNet support, has been released. Consequently, the end of support for App Service Environment v1 and v2 is approaching.

Migrating to v3 not only ensures seamless operational efficiency and compliance but also allows you to leverage new features and potential cost savings.

In August 2021, Azure announced that [Azure Cloud Services (classic) will be retired on August 31, 2024](https://azure.microsoft.com/ja-jp/updates/cloud-services-retirement-announcement/). Since App Service Environment v1 and v2 run on Azure Cloud Services (classic), they will also be [retired simultaneously](https://azure.microsoft.com/ja-jp/updates/app-service-environment-v1-and-v2-retirement-announcement/). Therefore, if you are using App Service Environment v1 or v2, now is the last opportunity to consider migrating to App Service Environment v3.

3. Content

3.1. What is App Service Environment?

App Service Environment (ASE) is a part of the App Service offering that provides a dedicated environment for hosting Web Apps. ASE offers advanced security and scalability tailored to specific needs, making it ideal for enterprises and large-scale applications.

ASE is deployed within a dedicated Virtual Network (VNet), ensuring physical separation from other resources, which enhances data protection and security. It allows detailed traffic control through Network Security Groups (NSG) and User Defined Routes (UDR). One of ASE’s key features is its ability to be completely isolated from the internet. This isolation allows for the application of specific network policies and secure connection to on-premises networks. Additionally, ASE provides functionalities to restrict access from specific IP addresses and subnets. By using Azure Service Endpoints, direct communication with Azure resources is possible, enabling a more efficient network architecture. Consequently, applications hosted on ASE can achieve superior performance and security.

Thus, App Service Environment offers a high level of security, flexible network control, and a dedicated hosting environment, making it an optimal solution for enterprise-level applications.

3.2. Resources Affected by Migration to v3

When planning the migration to App Service Environment (ASE) v3, it is crucial to identify the affected resources and key considerations. Below is a summary of the main resources and points to consider during the migration process:

In summary, migrating to ASE v3 can affect various resources and settings. By identifying and addressing these key points beforehand, you can ensure a smooth transition.

3.3. Migration Paths

3.3.1. Comparison of Migration Methods to ASE v3

There are three primary methods for upgrading to App Service Environment (ASE) v3: two automated migration options and one manual migration option.

  • In-Place Migration: This automated process replaces the existing App Service Environment (ASE) with the new ASE v3 within the same subnet. For more details, refer to the article on In-Place Migration for ASE v3.
  • Side-by-Side Migration: This automated process involves creating a new ASE v3 in a different subnet from the existing environment and migrating the services. This method is particularly advantageous as it minimizes downtime during the migration period. For more details, refer to the article on Side-by-Side Migration for ASE v3.
  • Manual Migration: This method is chosen when automated migration options are not feasible or when custom requirements necessitate a flexible migration approach. It involves considerable manual intervention but offers detailed control over the migration process. For more information, refer to the article on Manual Migration Methods.

3.3.2. Migration Path Checklist for ASE v3

3.3.3. Migration Path Checklist for ASE v3

Listing all ASEs within a subscription

To list all ASEs within a subscription, execute the following command:

# List all ASEs within the subscription
az appservice ase list --output tablep

Output example:

DnsSuffix                                 HasLinuxWorkers    InternalLoadBalancingMode    IpsslAddressCount    Kind    Location    MaximumNumberOfMachines    MultiRoleCount    MultiSize       Name            ProvisioningState    ResourceGroup    Status    Suspended    ZoneRedundant
---------------------------------------- ----------------- --------------------------- ------------------- ------ ---------- ------------------------- ---------------- -------------- -------------- ------------------- --------------- -------- ----------- ---------------
examplease1.p.azurewebsites.net False None 2 ASEV2 East US 250 2 Standard_D1_V2 examplease1 Succeeded example-rg Ready False False
examplease2.appserviceenvironment.net False Web, Publishing 0 ASEV2 West US 250 2 Standard_D1_V2 examplease2 Succeeded example-rg Ready False False

Retrieving detailed ASE information

To retrieve detailed information about a specific ASE, execute the following command:

# Retrieve detailed information about a specific ASE
az appservice ase show --resource-group example-rg --name examplease1 --output json

Listing subnets within a virtual network

To list all subnets within a virtual network, execute the following command:

# List all subnets within a virtual network
az network vnet subnet list --resource-group example-rg --vnet-name example-vnet --output table

Output example:

AddressPrefix    Name                      PrivateEndpointNetworkPolicies    PrivateLinkServiceNetworkPolicies    ProvisioningState    ResourceGroup
--------------- ------------------------ -------------------------------- ----------------------------------- ------------------- ---------------
10.1.1.0/24 example-sample1-subnet Enabled Enabled Succeeded example-rg
10.1.2.0/24 example-sample2-subnet Enabled Enabled Succeeded example-rg

Checking for empty subnets

To check for empty subnets within the virtual network, execute the following command:

# Check for empty subnets
az network vnet subnet list --resource-group example-rg --vnet-name example-vnet --query "[?ipConfigurations == null]" --output table

Output example:

Name                      AddressPrefix    ProvisioningState    PrivateEndpointNetworkPolicies    PrivateLinkServiceNetworkPolicies    ResourceGroup
------------------------ --------------- ------------------- -------------------------------- ----------------------------------- ---------------
example-sample1-subnet 10.1.1.0/24 Succeeded Enabled Enabled example-rg
example-sample2-subnet 10.1.2.0/24 Succeeded Enabled Enabled example-rg

4. Conclusion

In this article, we have provided a detailed explanation of migrating to Azure App Service Environment (ASE) v3.We explained the basic features and benefits of ASE, followed by an overview of the background and necessity for migrating to v3. We summarized the resources affected by the migration and key considerations, and compared the three migration paths: in-place migration, side-by-side migration, and manual migration. We provided a checklist for each step of the migration process and illustrated specific verification methods and command examples.This has allowed you to identify the most suitable migration method for your environment and follow practical guidelines to ensure a smooth transition.

To access the Japanese version of this article, click here.

--

--

tamami.I Web Developer

Japanese Developer. Currently responsible for server-side and infrastructure of video distribution systems. Experienced in payment systems, POS, and e-commerce.