Migration checklist when moving to Azure App Service

I have been continuously getting requests from customers, colleagues and partners around what to consider when migrating applications to Azure PaaS service but more specifically to the App Service.

This post tries to cover the majority of those cases and aims to provide a checklist and ready reckoner for customers/partners intending to migrate their existing applications to Azure App Service.

To start, let’s have a look at various considerations before you consider migrating your applications to Azure App Service

• Port Bindings – Azure App Service support port 80 for http and port 443 for HTTPS traffic. If you have sites using any other port after migration to Azure App Service, do remember that these are the only ports that will be used.
• Usage of assemblies in the GAC (Global Assembly Cache)- This is not supported. Consider bin placing the assemblies in the local bin.
• IIS5 Compatibility Mode– IIS5 Compatibility Mode is not supported. In Azure App Service each Web App and all the applications under it run in the same worker process with a specific set of application pool settings.
• IIS7+ Schema Compliance– One or more elements and/or attributes are being used which are not defined in Azure App Service IIS schema. Consider using XDT transforms.
• Single Application Pool Per Site- In Azure App Service each Web App and all the applications under it, run in the same application pool. In case you have applications with different application pool in IIS, consider establishing a single application pool with common settings or creating a separate Web App for each application.
• COM and COM+ components- Azure App Service does not allow the registration of COM components on the platform. If your site(s) or application(s) make use of any COM components, these would need to be rewritten in managed code and deployed with the site or application.
• ISAPI Extensions- Azure App Service can support the use of ISAPI Extensions, however, the DLL(s) need to be deployed with your site and registered via the web.config.

Once the above limitations have been taken into consideration, you will need to migrate your applications. The easiest form of migrating is through Azure App Service Migration Assistant. The Azure App Service Migration site and the tool can be utilized to migrate sites from Windows and Linux web servers to Azure App Service. As part of the migration the tool, this will create Web Apps and databases on Azure and publish content and publish your database.

This tool is available for both Windows server and Linux servers. The migration tool for Windows Server works either from the local machine or from a remote machine. It allows you to migrate sites from IIS running on Windows Server 2003 onwards.

Please refer to Windows Site Migration Tool for details.

The Linux site migration tool allows you to migrate sites from Linux web servers running Apache to the cloud. Only Apache is supported at this point in time.

Please refer to Linux Site Migration Tool for details.

Once you have decided to migrate, the following areas need to be considered for migrating applications to Azure App Service.

• On-premises integration – In case your applications are communicating with other applications which will not be migrated to Azure, you have to consider how the communication will happen when your application moves to Cloud. One solution is to enable the other application to communicate over the internet using REST. This may require changes in both the applications, not to mention the additional risk of exposing the server onto internet. Another approach would be to establish a secure connectivity to your on-premises server from Azure App Service, where your application is hosted. This can be done in any of the following ways depending on your requirement – Deploying your apps in an App Service Environment using an Isolated App Service Plan; enabling VNET integration with an Azure VNet , establish a Site to Site VPN between this Azure VNET and on-premises, and then enable routes between your App Service and the on-premises VM; and establishing hybrid connections. A detailed comparison of all the approaches would warrant a separate blog post.
• Authentication – When on-premises, you could be okay with no-authentication or windows authentication as there was mutual trust with AD. When you migrate to Azure you will need to enable authentication with Azure Active Directory. This means modifying some of your configuration to be able to authenticate your users via Azure AD. Complete details here on our documentation site.
• Session State – In an ideal case, you can make your application stateless in order to scale/switch at will. In case it is not possible, please have your session state configured to be persisted in Azure Redis Cache.
• File Persistence – Usually, websites might have a need for uploading files that need to be persisted. On Azure App Service, it is recommended to persist any files outside of the App Service into say something like a blob store. Modify the application to now use either the Azure Storage SDK or the REST APIs for saving and accessing files.
• App Settings/Connection Strings – There will be App Settings and Connection Strings that will change based on environment, whereas there will be somethings that will stay same. For the ones that change based on environment, also define them on the portal/template so that they can be overridden for different deployment slots.
• Logging –  If your logging framework is logging to files saved locally you will need to update them to either log it to Azure Diagnostics, or to a centralized blob store. You can also include Azure App Insights to get deeper insights into how your application is performing.
• Certificates – Certificates are not migrated directly. You will need to explicitly upload your certificates to be able to work on Azure. Details here in Bind SSL Certificate documentation. You can also purchase certificates directly from Azure. Details here in buy SSL cert documentation.
• Custom Domains – Custom domains can be associated to Azure Web Apps via a CNAME record change. You also need to update App Service to validate the DNS. Details here in map custom domain documentation.
• Email – Sending Emails requires an SMTP server. App Service does not provide you with the same and there is no way that you can configure it within App Service. While you can setup a SMTP server to send emails on Azure IaaS VMs, we do put in restrictions. We recommend using relay services to send email – ex: Office 365.
• LDAP Queries – In case you are building internal applications that are querying your LDAP store such as AD, those may not work on Azure App Service. Specifically, in case of Active Directory you can move AD to Azure AD and then use the graph APIs to make the necessary queries to Azure. For this, you will need to register your application with Azure AD to permit querying Directory Objects. Complete list of graph APIs are here.
• Shared/Linked Database queries – An application that has multiple databases needs to be given additional thought. If there are cross database queries, we will need to move the databases to Elastic Pools and then use Elastic Queries to query across the databases. If there is a linked database inside your database statements then this will not be permitted on Azure. This may require a re-architecture of the solution to avoid linked database queries.
• SQL Server features –  There are a number of server level features that are not supported on Azure SQL Database. There is a limited preview of SQL Managed Instance, but until then you may have to consider the following
  • SQL Agents – We see a number of databases having SQL Agents that would perform certain scheduled activities. Some functionality of this can be implemented via Elastic Jobs. For the remaining part, you would need to setup Web Jobs and/or Azure Functions.
  • SSIS – You can either go ahead and deploy SSIS on VMs or use Azure Data Factory to load/migrate data.
  • SSRS – You can deploy SSRS on VMs, use customized reporting in your application or use Power BI to generate intuitive reports.
  • SSAS – SSAS is available as a separate service called Azure Analysis Services.

Do note that all of the above solutions will require connecting to the Azure SQL Database over public DNS. You can ensure that the necessary sources are explicitly allowed connections via SQL Firewall.

• SQL Firewall – This is often overlooked, but you should provide explicit IP that will connect to the Azure SQL Database to enable connectivity. This includes client IPs that will manage using SSMS as well as Azure App Service.

Source: Azure Blog Feed