Migrate to App Service Environment v3
Note
The App Service Environment v3 migration feature is now available for a set of supported environment configurations in certain regions. Consider that feature which provides an automated migration path to App Service Environment v3.
If you're currently using App Service Environment v1 or v2, you have the opportunity to migrate your workloads to App Service Environment v3. App Service Environment v3 has advantages and feature differences that provide enhanced support for your workloads and can reduce overall costs. Consider using the migration feature if your environment falls into one of the supported scenarios. If your environment isn't currently supported by the migration feature, you can wait for support if your scenario is listed in the upcoming supported scenarios. Otherwise, you can choose to use one of the manual migration options given in this article.
If your App Service Environment won't be supported for migration with the migration feature, you must use one of the manual methods to migrate to App Service Environment v3.
Prerequisites
Scenario: An existing app running on an App Service Environment v1 or App Service Environment v2 and you need that app to run on an App Service Environment v3.
For any migration method that doesn't use the migration feature, you'll need to create the App Service Environment v3 and a new subnet using the method of your choice. There are feature differences between App Service Environment v1/v2 and App Service Environment v3 as well as networking changes that will involve new (and for internet-facing environments, additional) IP addresses. You'll need to update any infrastructure that relies on these IPs.
Note that multiple App Service Environments can't exist in a single subnet. If you need to use your existing subnet for your new App Service Environment v3, you'll need to delete the existing App Service Environment before you create a new one. For this scenario, the recommended migration method is to back up your apps and then restore them in the new environment after it gets created and configured. There will be application downtime during this process because of the time it takes to delete the old environment, create the new App Service Environment v3, configure any infrastructure and connected resources to work with the new environment, and deploy your apps onto the new environment.
Checklist before migrating apps
- Create an App Service Environment v3
- After creating the new environment, update any networking dependencies with the IP addresses associated with the new environment
- Plan for downtime (if applicable)
- Decide on a process for recreating your apps in your new environment
Isolated v2 App Service plans
App Service Environment v3 uses Isolated v2 App Service plans that are priced and sized differently than those from Isolated plans. Review the SKU details to understand how you're new environment will need to be sized and scaled to ensure appropriate capacity. There's no difference in how you create App Service plans for App Service Environment v3 compared to previous versions.
Back up and restore
The back up and restore feature allows you to keep your app configuration, file content, and database connected to your app when migrating to your new environment. Make sure you review the details of this feature.
Important
You must configure custom backups for your apps in order to restore them to an App Service Environment v3. Automatic backup doesn't support restoration on different App Service Environment versions. For more information on custom backups, see Automatic vs custom backups.
You can select a custom backup and restore it to an App Service in your App Service Environment v3. You must create the App Service you will restore to before restoring the app. You can choose to restore the backup to the production slot, an existing slot, or a newly created slot that you can create during the restoration process.
| Benefits | Limitations |
|---|---|
| Quick - should only take 5-10 minutes per app | Support is limited to certain database types |
| Multiple apps can be restored at the same time (restoration needs to be configured for each app individually) | Old and new environments as well as supporting resources (for example apps, databases, storage accounts, and containers) must all be in the same subscription |
| In-app MySQL databases are automatically backed up without any configuration | Backups can be up to 10 GB of app and database content, up to 4 GB of which can be the database backup. If the backup size exceeds this limit, you get an error. |
| Can restore the app to a snapshot of a previous state | Using a firewall enabled storage account as the destination for your backups isn't supported |
| Can integrate with Azure Traffic Manager and Azure Application Gateway to distribute traffic across old and new environments | Using a private endpoint enabled storage account for backup and restore isn't supported |
| Can create empty web apps to restore to in your new environment before you start restoring to speed up the process | Only supports custom backups |
Clone your app to an App Service Environment v3
Cloning your apps is another feature that can be used to get your Windows apps onto your App Service Environment v3. There are limitations with cloning apps. These limitations are the same as those for the App Service Backup feature, see Back up an app in Azure App Service.
Note
Cloning apps is supported on Windows App Service only.
This solution is recommended for users that are using Windows App Service and can't migrate using the migration feature. You'll need to set up your new App Service Environment v3 before cloning any apps. Cloning an app can take up to 30 minutes to complete. Cloning can be done using PowerShell as described in the documentation or using the Azure portal.
To clone an app using the Azure portal, navigate to your existing App Service and select Clone App under Development Tools. Fill in the required fields using the details for your new App Service Environment v3.
- Select an existing or create a new Resource Group.
- Give your app a Name. This name can be the same as the old app, but note the site's default URL using the new environment will be different. You'll need to update any custom DNS or connected resources to point to the new URL.
- Use your App Service Environment v3 name for Region.
- Choose whether or not to clone your deployment source.
- You can use an existing Windows App Service plan from your new environment if you created one already, or create a new one. The available Windows App Service plans in your new App Service Environment v3, if any, will be listed in the dropdown.
- Modify SKU and size as needed using one of the Isolated v2 options if creating a new App Service plan. Note App Service Environment v3 uses Isolated v2 plans, which have more memory and CPU per corresponding instance size compared to the Isolated plan. For more information, see App Service Environment v3 SKU details.
| Benefits | Limitations |
|---|---|
| Can be automated using PowerShell | Only supported on Windows App Service |
| Multiple apps can be cloned at the same time (cloning needs to be configured for each app individually or using a script) | Support is limited to certain database types |
| Can integrate with Azure Traffic Manager and Azure Application Gateway to distribute traffic across old and new environments | Old and new environments as well as supporting resources (for example apps, databases, storage accounts, and containers) must all be in the same subscription |
Manually create your apps on an App Service Environment v3
If the above feature doesn't support your apps or you're looking to take a more manual route, you have the option of deploying your apps following the same process you used for your existing App Service Environment. You don't need to make updates when you deploy your apps to your new environment.
You can export Azure Resource Manager (ARM) templates of your existing apps, App Service plans, and any other supported resources and deploy them in or with your new environment. To export a template for just your app, navigate to your App Service and go to Export template under Automation.
You can also export templates for multiple resources directly from your resource group by going to your resource group, selecting the resources you want a template for, and then selecting Export template.
The following initial changes to your Azure Resource Manager templates are required to get your apps onto your App Service Environment v3:
Update SKU parameters for App Service plan to an Isolated v2 plan:
"type": "Microsoft.Web/serverfarms", "apiVersion": "2021-02-01", "name": "[parameters('serverfarm_name')]", "location": "East US", "sku": { "name": "I1v2", "tier": "IsolatedV2", "size": "I1v2", "family": "Iv2", "capacity": 1 },Update App Service plan (serverfarm) parameter the app is to be deployed into to the plan associated with the App Service Environment v3
Update hosting environment profile (hostingEnvironmentProfile) parameter to the new App Service Environment v3 resource ID
An Azure Resource Manager template export includes all properties exposed by the resource providers for the given resources. Remove all non-required properties such as those which point to the domain of the old app. For example, you
sitesresource could be simplified to the following sample:"type": "Microsoft.Web/sites", "apiVersion": "2021-02-01", "name": "[parameters('site_name')]", "location": "East US", "dependsOn": [ "[resourceId('Microsoft.Web/serverfarms', parameters('serverfarm_name'))]" ], "properties": { "serverFarmId": "[resourceId('Microsoft.Web/serverfarms', parameters('serverfarm_name'))]", "siteConfig": { "linuxFxVersion": "NODE|14-lts" }, "hostingEnvironmentProfile": { "id": "[parameters('hostingEnvironments_externalid')]" } }
Other changes may be required depending on how your app is configured.
Azure Resource Manager templates can be deployed using multiple methods including using the Azure portal, Azure CLI, or PowerShell.
Guidance for manual migration
The migration feature automates the migration to App Service Environment v3 and at the same time transfers all of your apps to the new environment. There's about one hour of downtime during this migration. If you're in a position where you can't have any downtime, the recommendation is to use one of the manual options to recreate your apps in an App Service Environment v3.
You can distribute traffic between your old and new environment using an Application Gateway. If you're using an Internal Load Balancer (ILB) App Service Environment, see the considerations and create an Azure Application Gateway with an extra backend pool to distribute traffic between your environments. For internet facing App Service Environments, see these considerations. You can also use services like Azure Front Door, Azure Content Delivery Network (CDN), and Azure Traffic Manager to distribute traffic between environments. Using these services allows for testing of your new environment in a controlled manner and allows you to move to your new environment at your own pace.
Once your migration and any testing with your new environment is complete, delete your old App Service Environment, the apps that are on it, and any supporting resources that you no longer need. You'll continue to be charged for any resources that haven't been deleted.
Frequently asked questions
- Will I experience downtime during the migration?
Downtime is dependent on your migration process. If you have a different App Service Environment that you can point traffic to while you migrate or if you can use a different subnet to create your new environment, you won't have downtime. However, if you must use the same subnet, there will be downtime resulting from the time it takes to delete the old environment, create the App Service Environment v3, create the new App Service plans, re-create the apps, and update any resources that need to know about the new IP addresses. - Do I need to change anything about my apps to get them to run on App Service Environment v3?
No, apps that run on App Service Environment v1 and v2 shouldn't need any modifications to run on App Service Environment v3. - What if my App Service Environment has a custom domain suffix?
The migration feature supports this migration scenario. You can migrate using a manual method if you don't want to use the migration feature. You can configure your custom domain suffix when creating your App Service Environment v3 or any time after that. - What if my App Service Environment is zone pinned?
Zone pinning isn't a supported feature on App Service Environment v3. - What properties of my App Service Environment will change?
You'll now be on App Service Environment v3 so be sure to review the features and feature differences compared to previous versions. For ILB App Service Environment, you'll keep the same ILB IP address. For internet facing App Service Environment, the public IP address and the outbound IP address will change. Note for internet facing App Service Environment, previously there was a single IP for both inbound and outbound. For App Service Environment v3, they're separate. For more information, see App Service Environment v3 networking. - Is backup and restore supported for moving apps from App Service Environment v2 to v3? The back up and restore feature supports restoring apps between App Service Environment versions as long as a custom backup is used for the restoration. Automatic backup doesn't support restoration to different App Service Environment versions.
- What will happen to my App Service Environment v1/v2 resources after 31 August 2024?
After 31 August 2024, if you haven't migrated to App Service Environment v3, your App Service Environment v1/v2s and the apps deployed in them will no longer be available. App Service Environment v1/v2 is hosted on App Service scale units running on Cloud Services (classic) architecture that will be retired on 31 August 2024. Because of this, App Service Environment v1/v2 will no longer be available after that date. Migrate to App Service Environment v3 to keep your apps running or save or back up any resources or data that you need to maintain.
Next steps
Feedback
Submit and view feedback for