Checklist for Migrating Web Apps to App Service

This post has been republished via RSS; it originally appeared at: New blog articles in Microsoft Community Hub.

App Service continues to invest in migration tooling to allow customers to easily migrate their web apps to App Service. The current set of tools enable discovery, assessment, and migration of ASP. Net web app across various scenarios and scopes viz. standalone web app, single IIS server and even a datacenter. To read more about these migration tools please refer to ASP. Net web app Migration to Azure App Service using PowerShell Scripts.

 

To successfully migrate, and subsequently operate, an application workload in Azure App Service several qualifying prerequisites must be satisfied. Broadly there are three categories of pre-requisite checks to review and confirm which would not only enable successful migrations to Apps Service but also ensure that the application workload functions successfully after migration.

  • Architectural & Non-functional requirements: such as IT operations, network connectivity, regulatory or industry requirements, service level requirements, etc.
  • Runtime Environment - Configuration of the IIS service (ASP.NET) and Windows OS environment that host the application.
  • Application Code/Package - Requirements that the application program code must satisfy for it to perform and operate successfully in the target environment.

*** This blog article provides input on some of the common topics and possible guidance against those which would help you successfully migrate your ASP. Net web apps to App services and operate these web apps successfully post migration. Many of the topics and guidance provided in this blog are equally applicable when you are planning to migrate your web apps based on other languages and\or platforms as well like Java web apps. Please refer to Configure Java apps - Azure App Service and  Migrate Tomcat applications to Tomcat on Azure App Service for additional guidance.

 

*** It is strongly recommended to evaluate the App service landing zone accelerator which is an open-source collection of architectural guidance and reference implementation to accelerate deployment of Azure App Service at scale. The landing zones adhere to the architecture and best practices of the Cloud Adoption Framework. The architectural approach can be used as design guidance for greenfield implementation and as an assessment for brownfield customers already using App Service.

 

Architectural and Non-Functional Requirements Checklist

 

Topic

Guidance

Azure subscription that will host App Service Plan and other required services.

Subscriptions, licenses, accounts, and tenants for Microsoft's cloud offerings - Microsoft 365 Enterprise

The dependency graph of the application is known and documented, including databases and network storage, and all external services (such as other web applications) that the application relies on or that rely on this application, and can be assessed and migrated simultaneously, or components remain as-is without loss of connectivity or degradation of service.

Consider using the Application Insights on-prem agent to observe your ASP.NET application.  You can then view the Application Map to visualize and better understand how your application interacts with other components.

SLA requirements for Azure App Service and other Azure services the application may utilize

Licensing Documents (microsoft.com)

Requirement of advanced configuration for the application workload to adhere to regulatory compliances.

Azure compliance documentation

Generic Azure Networking and Connectivity requirements

 Consider these guidelines to ensure connection availability and improve reliability with Azure services https://learn.microsoft.com/en-us/azure/well-architected/resiliency/design-requirements#networking-and-connectivity-requirements

App Service Specific Networking and Connectivity Requirements

There are primarily two ways to achieve network isolation for your web applications in App Service

1)     You can migrate your web app to App service muti-tenant using currently available migration tools, but these tools currently don’t support migrating to existing App service plans. So as a post migration configuration activity you can utilize many networking features that enable apps to reach network-isolated resources or become network-isolated themselves. These features are enabled at the application level. Please refer to Networking features - Azure App Service

2)     The other option it to migrate your web app using currently available migration tools to an App Service Environment which is a single-tenant deployment of Azure App Service that runs on your virtual network. With an App Service Environment, no added configuration is required for the apps to be on a virtual network. The apps are deployed into a network-isolated environment that's already on a virtual network. If you really need a complete isolation story, you can also deploy your App Service Environment onto dedicated hardware. Please refer to App Service Environment overview - Azure App Service Environment

BCDR Requirements

App Services offers multiple features that support backup and restore for your web app. Please refer to Back up an app - Azure App Service

 

In addition to the regular backup and restore operations, most organizations have a business continuity plan to maintain availability of their applications during downtime and the preservation of their data in a regional disaster. For common BCDR strategies for web apps deployed to App Service please refer to Disaster recovery guide - Azure App Service

Security

The platform components of App Service, including Azure VMs, storage, network connections, web frameworks, management, and integration features, are actively secured and hardened. In addition to the App Service platform component security, it is highly recommended to secure your web app using guidance provided here Security - Azure App Service

 

Runtime Environment Checklist

 

Topic

Guidance

Supported Source Environment

·        The server is operating in one of the supported source environments (VMWare, Hyper-V, Physical Server)

·        The server has remote access enabled via RDP, hypervisor API's or relevant providers management APIs.

·        The server operating system is Windows Server 2008R2 or later.

·        The server has a minimum PowerShell v5.1 installed.

·        The server has the "Web Server" (IIS) windows feature, including the IIS Management Console

·        The IIS service is currently operating without errors. These could indicate an invalid configuration that will not allow the assessment stage or subsequent migration to succeed.

·

*** Some of these prerequisites are a requirement for currently available migration tooling for App service

Ports

App service allows traffic only over standard ports i.e., 80\443. If your web app uses non-standard ports, then after migration to App Service all the app traffic will be available only on port 80\443.

 

In this scenario if your app has inbounded or outbound dependencies then you will be required to make appropriate port changes so that these dependencies are able to successfully communicate with the App Service web app over port 80\443. Please refer to https://github.com/Azure/App-Service-Migration-Assistant/wiki/Readiness-Checks#port-bindings

Application Pool

Azure App Service applications currently support a single IIS application pool per App Service Application.  If your existing web app uses multiple application pools please refer to remediation guidance here https://github.com/Azure/App-Service-Migration-Assistant/wiki/Readiness-Checks#application-pools

ISAPI Filters

ISAPI filters enable custom behavior for an IIS server or site. ISAPI filters are commonly used by add-on or 3rd party products that extend IIS. It is possible that some of these ISAPI filters could be supported in an Azure App Service application, but this would need to be evaluated and handled on a case-by-case basis.

Azure App Service can support the use of ISAPI Filters, however, the ISAPI DLL must be deployed with your site and registered via web.config. 

 

If your web app has a strong dependency on ISAPI filters you may consider deploying your web app to App Service using Windows Containers,

Application Pool Identity

Azure App Service applications are hosted in an IIS worker process that runs in a system managed account associated with the application pool. This is also the default identity used by on-premises installations of IIS.

 

If your existing web app is configured to run as the identity of a custom Windows account, as the Local System account, or as the Network Service account, then the site must be changed to ApplicationPoolIdentity before it can be migrated. Please refer to https://github. /Azure/App-Service-Migration-Assistant/wiki/Readiness-Checks#application-pool-identity

 

It is important to note that you may be using custom windows account for “Application Pool Identity” to enable your web app to communicate with other services like a Database. If the use case for using custom windows account is related to communicating with a SQL server Database, then you can connect your App service web app with an Azure SQL database using Managed System Identity or by impersonating on behalf of the signed-in user. The assumption here is that your on-premises database is also migrated to Azure SQL database.

 

Please refer to Tutorial: Access data with managed identity - Azure App Service and Tutorial - Web app accesses SQL Database as the user - Azure App Service

Config File

Azure App Service applications are hosted using a preconfigured IIS applicationhost.config file that is built using the selected options for the application.

If the machine that will be migrated depends on configuration options that exist in the IIS applicationhost.config file but are applied at a different level using Location Tags. Any such Location Tag entries must be removed from the applicationhost.config file before the site can be migrated. Please refer to https://github.com/Azure/App-Service-Migration-Assistant/wiki/Readiness-Checks#location-tags

Certificates

If the site to be migrated is listening for encrypted HTTPS requests and HTTPS is detected, the site can be migrated - but if a custom TLS certificate is desired, you will need to install the certificate in App Services separately after migration has completed.

 

Please refer to Add and manage TLS/SSL certificates - Azure App Service for guidance on adding digital security certificates to your web app after its migrated to App Service

Authentication

On-premises installations of IIS support several different authentication types, including Windows Authentication, Basic Authentication, Client Certificate Authentication and more.

Azure App Service applications support a different set of authentication types explained here Authentication and authorization - Azure App Service

 

One of the very common scenarios for on-premises ASP.Net web app is to use integrated windows auth. App service does not support integrated windows auth as-is but the same can be achieved by federating their on-premises Active Directory and then switch to using Azure Active Directory by following techniques explained here Authentication and authorization - Azure App Service and Configure authentication in an Azure Web App by using Azure Active Directory B2C

 

There is another common scenario where in on-premises ASP.Net web apps are connected to Microsoft SQL Server as the backend database. If you decide to migrate your web app to App Service and Microsoft SQL server database to Azure SQL, you can connect these using Managed System Identity or by impersonating on behalf of the signed-in user.

 

Please refer to Tutorial: Access data with managed identity - Azure App Service and Tutorial - Web app accesses SQL Database as the user - Azure App Service

Protocols

Azure App Service applications support both non-encrypted HTTP requests, and encrypted HTTPS requests.

 

If the bindings on the existing site use non-HTTP protocols, such as the net.tcp protocol used by Windows Communication Foundation, It will be necessary to remove any non-HTTP bindings from the site before it can be migrated. Please refer to https://github.com/Azure/App-Service-Migration-Assistant/wiki/Readiness-Checks#protocols

Application Settings

ASP.NET supports declaration of application settings in web.config files. These settings are specific to the application and will vary from application to application. These application settings declared in web.config files will work with Azure App Services, but please note that App Service provides direct support for application settings through the portal. By moving these application specific settings to App Service, you can modify their values in the portal without requiring full redeployment of the code. Please refer to https://learn.microsoft.com/en-us/azure/app-service/configure-common?tabs=portal#configure-app-settings

 

Application settings are always encrypted when stored (encrypted-at-rest).

 

Azure Key Vault is a service that provides centralized secrets management, with full control over access policies and audit history. You can also work with secrets (application settings) from Azure Key Vault in your App Service web app without requiring any code changes. Please refer to Use Key Vault references - Azure App Service

Connection Strings

Azure App Services supports a number of different database options, including support for Azure based databases, migration from on-premises databases to Azure hosted databases, or support for on-premises databases through Hybrid Connections.

 

For ASP.NET developers, setting connection strings in App Service are like setting them in <connectionStrings> in Web.config, but the values can also be set in App Service. Remember that the connection strings defined in App Service override the ones in Web.config. Please refer to https://learn.microsoft.com/en-us/azure/app-service/configure-common?tabs=portal#configure-connection-strings

 

Azure Key Vault is a service that provides centralized secrets management, with full control over access policies and audit history. You can also work with secrets (connection strings) from Azure Key Vault in your App Service web app without requiring any code changes. Please refer to Use Key Vault references - Azure App Service

Staging Environments

It is a common practice to have separate deployment environments for your web applications ex: test\staging\production.

 

In App Service deployment slots are live apps with their own host names. Once you have migrated your web app to Azure App Service, you can use a separate deployment slot instead of the default production slot. App content and configurations elements can be swapped between two deployment slots, including the production slot.

Deploying your application to a non-production slot has the following benefits:

  • You can validate app changes in a staging deployment slot before swapping it with the production slot.
  • Deploying an app to a slot first and swapping it into production makes sure that all instances of the slot are warmed up before being swapped into production. This eliminates downtime when you deploy your app. The traffic redirection is seamless, and no requests are dropped because of swap operations. You can automate this entire workflow by configuring auto swap when pre-swap validation isn't needed.
  • After a swap, the slot with previously staged app now has the previous production app. If the changes swapped into the production slot aren't as you expect, you can perform the same swap immediately to get your "last known good site" back.

 

Please refer to Set up staging environments - Azure App Service

Logging

You may be using Application logging to debug your existing web application.

 

Azure provides built-in diagnostics to assist with debugging an App Service app. App service built-in diagnostics supports applications logging web server logging, detailed error messages, failed request tracing and deployment logging.

 

Using the Azure portal, you can easily enable diagnostic logging and add instrumentation to your application, as well as access the information logged by Azure. Please refer to Enable diagnostics logging - Azure App Service.

 

In addition to built-in logging support, you can also utilize App Service diagnostics, which is an intelligent and interactive experience to help you troubleshoot your app with no configuration required. If you do run into issues with your app, App Service diagnostics points out what’s wrong to guide you to the right information to troubleshoot and resolve the issue more easily and quickly. Please refer to Diagnostics and solve tool - Azure App Service

HTTP Logging module in web.config

The HTTP logging module is locked on Azure App Service and modifying the setting in web.config <httpLogging dontLog="true" /> will result in a 500 error. So, evaluate the usage of the HTTPLogging module for your web app and if it’s not required you may delete this config section in web.config.

 

App service provides multiple options for enabling web app logging please refer to the above-mentioned logging topic for guidance.

Application Request Routing

If your existing app is using Application Request Routing to route some requests to other services then please refer to Using Azure Web Site as a reverse proxy - RuslanY Blog for guidance.

Monitoring

It is a common scenario to monitor your web app for availability, performance, and operations.

 

Azure App Service provides several monitoring options for monitoring resources for availability, performance, and operation. Options such as Diagnostic Settings, Application Insights, Log stream, Metrics, Quotas and alerts, and Activity logs.

 

You can utilize most of these monitoring capabilities for your migrated web apps without making code changes.

 

Please refer to Monitoring overview - Azure App Service

Scaling

Horizontal and vertical scaling for a web app is a common requirement   address sudden increase in HTTP traffic.

 

Generally, you will add a greater number of servers\VM’s or upgrade existing servers\VM’s to scale your existing web app. This approach may work fine in scenarios where in HTTP traffic is predictable and hardware is ordered\available when needed. In this approach full web app deployment and configuration may be required as well. All these actions lead to greater time lag and require additional investments while addressing scaling requirements for your web app.

 

App Service allows you to easily scale up and scale out and these actions don't require you to change your code or redeploy your application.

 

  • Scale up: Get more CPU, memory, disk space, and extra features.
  • Scale out: Increase the number of VM instances that run your app. You can scale out to as many as 30 instances, depending on your pricing tier.

The scale settings take only seconds to apply and affect all apps in your App Service plan. Please refer to Scale up features and capacities - Azure App Service

 

App Service allows different scale out options:

  • Manual scaling which allows you to add more instances to your plan just by moving the slider.
  • Automatic scaling is a simple “cruise mode” scale out technique that adjusts the number of running instances of your application based on incoming HTTP requests. This ensures that your web applications can handle varying levels of traffic without having to configure scaling rules.
  • Autoscale capability allows you to scale out your web applications using more advanced techniques like rules based on standard metrics ex. CPU percentage, Memory percentage etc... Autoscale also allows you to scale your web app based on a repeat schedule.

Please note that, if your web app depends on the use of In Proc state management then this may impact scale out for your web app because it limits the possibility of spreading the load over other instances.

 

It is highly recommended to externalize your app session management using the guidance provided under Session Management and Caching topic below.

Operational Excellence

A DevOps methodology provides a greater return on investment for application teams in the cloud. IaC is a key tenet of DevOps.

 

We have recently published guidance regarding “reliable web app patterns for .Net” which provides guidance on operational excellence

 

You can also automate deployment for your web apps to App service using App Service GitHub actions.

 

It is also recommended to review repeatable infrastructure guidance to standardize infra deployment required for your web applications.

Secure communication and WAF

It is highly recommended to secure communications between App service web apps and other Azure services using private endpoints.

 

Similarly, you should protect web applications with a web application firewall. The web application firewall provides a level protection against common security attacks and botnets.

 

We have recently published guidance regarding “reliable web app patterns for .Net” which provides guidance on secure communications and web application firewalls

Zone Redundancy

Your App Service plans can be deployed across availability zones (AZ) to help you achieve resiliency and reliability for your business-critical workloads. This architecture is also known as zone-redundancy.

 

When you configure to be zone-redundant, the platform automatically spreads the instances of the Azure App Service plan across three zones in the selected region. This means that the minimum App Service Plan instance count will always be three. If you specify a capacity larger than three, and the number of instances is divisible by three, the instances are spread evenly. Otherwise, instance counts beyond 3*N are spread across the remaining one or two zones.

 

Please refer to Migrate Azure App Service to availability zone support

Cost Optimization and Right size resources for different environment

Cost optimization principles balance business goals with budget justification to create a cost-effective web application. Cost optimization is about reducing unnecessary expenses and improving operational efficiency.

 

Another way to optimize costs is by right sizing your production and non-production environments using Azure Dev\Test pricing and Azure Reservations or an Azure Savings plan.

 

Please refer to https://learn.microsoft.com/en-us/azure/architecture/reference-architectures/reliable-web-app/dotnet/apply-pattern#rightsize-resources-for-each-environment

 

Application Code/Package Checklist

 

All Azure App Service Web Apps run in a secure environment called a sandbox. Each app runs inside its own sandbox, isolating its execution from other instances on the same machine as well as providing an additional degree of security and privacy which would otherwise not be available.

*** It is highly recommended to review App service sandbox guidance here https://github.com/projectkudu/kudu/wiki/Azure-Web-App-sandbox

 

Topic

Guidance

Virtual Directory\Filesystem

It is a common practice to store web app content under site root or on the mounted virtual directories.

 

Azure App Services stores the root content for a site in a fixed home directory D:\home\site\wwwroot. If you use currently available migration tools, the content under the site root is copied to the home directory on the Azure App Service worker role machine. If there are virtual directories defined on the site to be migrated, the migration tools will configure the correct paths for the virtual directories and migrate their content.

 

*** Current migration tools do not support migration of applications with Virtual directories on UNC shares and content size for migration is limited to 2GB.

 

Additionally, App service also supports mounting Azure Storage Files as a network share. For App service windows we have recently released capability to map these already mounted local file shares as a virtual directory for your web app in App Service. To configure the virtual directory, in the Azure portal (App service) left navigation click Configuration > Path Mappings > New Virtual Application or Directory. Set the Physical path to the Mount path defined on the Azure Storage mount and the virtual path is the one that you will use to access ex: https://mywebapp.azurewebsites.net/virtualpathname

 

Please refer to Mount Azure Storage as a local share - Azure App Service

 

You can also access this virtual path programmatically using standard .Net programming techniques ex: Server.MapPath("~/virtualpathname/");

 

You can also use azcopy tool to move your on premises data to Azure Storage file share mounted for your web app using the guidance provided here Tutorial: Migrate on-premises data to Azure Storage with AzCopy

Registry

App services does not allow web apps to perform write operations to the Windows registry. If your existing web app depends on registry access than consider App Service using Windows Containers

Host Process

Your application should not interact with any running host process outside of the parent IIS worker process tree. This includes accessing a foreign process indirectly using the network stack and loopback address (localhost or 127.0.0.1) or Named Pipes or accepting connections from a foreign process using the same.

Network socket & Interface

Your application should not create network sockets of any type other than TCP. Similarly, your application should not access the host's network interfaces directly or attempt to control how network traffic is routed.

 

Consider using a rich set of networking capabilities App service offers for your web app instead.

Restricted Outgoing ports

Due to App Service sandbox model regardless of address, applications cannot connect to anywhere using ports 445, 137, 138, and 139. In other words, even if connecting to a non-private IP address or the address of a virtual network, connections to ports 445, 137, 138, and 139 are not permitted.

 

If your requirement is to mount file shares for your web app in App service then consider using Mount Azure Storage as a local share - Azure App Service  

Session Management and Caching

If your existing web app depends on sticky session, then App service allows enabling “ARR Affinity”. ARR Affinity (Application Request Routing) sets an affinity cookie, which is used to redirect users to the same node that handled their previous requests.

 

Also note that storing session state in memory can result in losing session state when there's a problem with the application. It also limits the possibility of spreading the load over other instances. It is advisable to externalize your application session state ex: Cache ASP.NET Session State Provider

GAC Deployment\MSI\COM

If your existing web app depends on GAC deployment and or your web apps depends on functionalities which require custom assemblies consider App Service using Windows Containers, which enables usage of the GAC, COM components, MSIs, full access to .NET FX APIs, DirectX, and more.

Reliability

A reliable web application is one that is both resilient and available. Resiliency is the ability of the system to recover from failures and continue to function. The goal of resiliency is to return the application to a fully functioning state after a failure occurs. Availability is a measure of whether your users can access your web application when they need to. You should use the Retry and Circuit Breaker patterns as critical first steps toward improving application reliability. These design patterns introduce self-healing qualities and help your application maximize the reliability features of the cloud.  Pay particular attention to your application’s startup code (for example, your project’s startup.cs, deferred initialization of services in your IoC container, etc.).  While not required for a successful migration, you’ll gain full advantage of App Service’s horizontal scaling features by ensuring that your application can start reliably.

 

Please refer to https://learn.microsoft.com/en-us/azure/architecture/reference-architectures/reliable-web-app/dotnet/apply-pattern#reliability

Win32k.sys (User32/GDI32) Restrictions

The App service sandbox prevents almost all the Win32k.sys APIs from being called, which practically means that most of User32/GDI32 system calls are blocked.

 

If your existing web app requires PDF generation functionality, then consider using guidance here https://github.com/projectkudu/kudu/wiki/Azure-Web-App-sandbox#win32ksys-user32gdi32-restrictions

 

Alternatively consider App Service using Windows Containers to overcome these restrictions and even use third party PDF libraries

 

Leave a Reply

Your email address will not be published. Required fields are marked *

*

This site uses Akismet to reduce spam. Learn how your comment data is processed.