-
Notifications
You must be signed in to change notification settings - Fork 60
Readiness Checks
Azure App Service applications are hosted on a worker machine behind a load balancing front end router. The front end is a shared resource that is not associated with a particular tenant. The front-end load balancer listens for standard HTTP traffic on TCP port 80, and for encrypted HTTPS traffic on TCP port 443. It does not listen on other TCP ports.
This check examines the bindings on the site to be migrated and verifies that it is not listening on TCP ports other than 80 and 443. It will be necessary to configure the site to listen only on these ports before it can be migrated.
- Remove any ports other than 80/443.
- For more information in changing these settings for IIS see How to change the TCP port for IIS services.
Azure App Service applications support both non-encrypted HTTP requests, and encrypted HTTPS requests.
This check examines the bindings on the site to be migrated and verifies that it does not host 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.
- Remove any non-HTTP protocol bindings
- For more information in changing these settings for IIS see:
- How to change the TCP port for IIS services.
- Remove-IISSiteBinding
- How to add binding information to a site
This check examines the site to be migrated to see if it is listening for encrypted HTTPS requests. If HTTPS is detected, the site can be migrated - but if a custom TLS certificate is desired, the user will be alerted that it needs to be installed separately after migration has completed.
- No action required prior to migration.
- Optional recommended steps:
- For information on configuring certificates after migration see Bind certificate to app.
Azure App Service applications are hosted using a preconfigured IIS applicationhost.config file that is built using the selected options for the application.
This check examines the machine to be migrated to see if it 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.
Generally, these entries can be moved to either the site's root web.config file, or to a web.config file associated with the specific application to which they apply. Once they've been moved to one of these locations, they can be migrated to Azure App Service with the site content.
- Remove the location tags
- For more information see Location Tags.
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.
This check examines the site to be migrated for ISAPI filters. If any filters are detected, they must to be removed before the site can be migrated.
- Remove ISAPI filters
- For further information on modifying ISAPI filters see How to add an ISAPI filter.
Azure App Service applications currently support a single IIS application pool per App Service Application.
This check examines the site to be migrated for sites that use multiple applications hosted in separate application pools. It will be necessary to configure the site to be migrated to use a single application pool before it can be migrated.
- Move the workloads to a single application pool and remove additional application pools.
- A common scenario where this might be configured is a site requiring multiple versions of the .NET framework. Currently this is not a supported configuration.
- Separate Azure app service application would need to be created for each of the frameworks.
- For further information see How to configure the application pool for an existing site or application.
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.
This check examines the application pool associated with the site to be migrated to ensure that it is configured to run as ApplicationPoolIndentity. If the site to be migrated 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.
- Set the Application pool to run as ApplicationPoolIdentity.
- For further information see Configuring IIS Application Pool Identities.
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.
This check examines the site to be modified to determine which authentication types are in use. If authentication types other than Anonymous Authentication are detected, it will be necessary to change the authentication types to Anonymous Authentication before the site can be migrated. After the migration is complete, it will be possible to configure the site using one of the Azure App Service supported authentication types.
- Enable anonymous authentication.
- For further information on configuring these settings see Anonymous Authentication.
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. While application settings declared in web.config files will work with Azure App Services, they are considered to be obsolete. Azure App Services provides direct support for application settings through the portal.
This check examines the site to be migrated for application settings declared in web.config files. If found, they will not prevent the site from migrating, but a recommendation will be made to move the settings from the web.config file to the Azure Portal after migration is complete.
- No action required prior to migration.
- Optional recommended steps:
- After Migration any application settings declared in the web.config file should be configured in the azure portal.
- See Configure apps in Azure App Service.
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.
This setting examines the site being migrated for connection strings in web.config files. If detected, the user will be offered the option of either manually managing database migration to Azure or continuing to use the on-premises database via Hybrid Connections. If the user opts to use Hybrid Connections, the migration assistant will automatically set them up and configure them for use.
Note that it is possible for web applications to interact with databases in different ways that do not necessarily use connection strings. While these databases can be supported with the same options as above, they will not be automatically detected during migration.
- Manually migrate database and setup connection or setup hybrid connection.
- For more information see Migrate your MySQL database to Azure Database for MySQL using dump and restore.
Checks if PHP handlers are configured for the site. Support for PHP using Windows framework on App Service will be ending as outlined on the PHP on App Service page. Support will continue for PHP on App Service using Linux, however automatic migration with Migration Assistant from IIS to App Service does not currently convert from Windows to Linux, so we do not recommend this type of migration.
- Verify if PHP is in use by the site - if not, then may ignore this warning
- If PHP is in use by the site, then we do not recommend migrating with the migration assistant - please consider using alternate options, such as separately creating a Linux-based App Service PHP app and uploading content using a deployment option like such as by using FTP.
Checks if the site is using frameworks not currently supported for automatic migration. Allows ASP.NET, and PHP. (In future builds ASP.NET Core, NodeJS, Java, and Python will be supported).
- Verify the desired framework version for your web app.
- If framework versions are not in use, remove them.
- If the frameworks are in use on the system, then your web app then migration is not currently possible with the migration assistant.
This error occurs when IIS returns an error when being scanned by the app service migration assistant. This typically indicates an error within the configuration for the web app on the host machine
- Review logs on the host machine to determine the errors being encountered by the web app.
Azure App Services stores the root content for a site in a fixed home directory D:\home\site\wwwroot . When an application is migrated, 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 Assistant will configure the correct paths for the virtual directories and migrate their content.
App service migration assistant does not support migration of applications with Virtual directories on UNC shares.
Azure App Service supports running both Windows containers and Linux containers, however the Migration Assistant at this time will only set up configuration for Linux containers during a migration. Please see Run a custom Windows container in Azure for how to set up a Windows container in App Service without Migration Assistant.
Defined container volume configuration will not be used when the image is started on Azure App Service. If the application will not work correctly without this specific configuration it may not be a good candidate to lift-and-shift without some extra verifications.
Azure App Service will expose the first defined TCP port in the image configuration for HTTP traffic when it starts the container. If there are no defined exposed ports, then the container will not be able to receive web traffic.
- Modify the image configuration and re-launch the container with an exposed TCP port before re-running the Migration Assistant. Confirm that clients of the container site still work as expected.
Azure App Service will expose the first defined TCP port in the image configuration for HTTP traffic when it starts the container. In order to determine if the container is configured to handle HTTP requests, the Migration Assistant attempts to make a generic GET request using that port. As the request is generic, and expected behavior may be to reject this type of generic request, the response code does not need to be a successful HTTP response code. This check does not confirm that a container site is functionally working, simply that it can respond to HTTP requests.
Azure App Service currently has built-in support for Java versions 1.8 and 11 running on Tomcat. Alternate versions may still be run on App Service using your own container (https://azure.microsoft.com/en-us/services/app-service/containers/).
Checks for existing .war or ability to create a deployable .war file. If an application is based on an existing .war file, this is what will be published as the app content. If there is not an existing .war file the tool will look for and use the jar executable from a java installation to create a .war. The tool looks for the jar executable under the bin directory of the path specified by the JDK_HOME environment variable, or, if that environment variable is not found, in the JAVA_HOME location.
Azure App Service only allows incoming requests on ports 80 and 443. If other ports are used for incoming requests on the pre-migration site, then clients making requests to the application will have to update the port used in their requests in order to work with the migrated site.
Please check out this link for more information: https://docs.microsoft.com/en-us/azure/developer/java/migration/migrate-tomcat-to-tomcat-app-service#determine-whether-memoryrealm-is-used
Please check out this link for more information: https://docs.microsoft.com/en-us/azure/developer/java/migration/migrate-tomcat-to-tomcat-app-service#determine-whether-tomcat-clustering-is-used
Please check out this link for more information: https://docs.microsoft.com/en-us/azure/app-service/configure-language-java?pivots=platform-linux#use-redis-as-a-session-cache-with-tomcat