Infogain’s Comprehensive Guide to Migrating Existing Web Applications to Azure App Service

Moving an existing web site to Microsoft’s Azure Web Apps has never been easier.  But if you want to leverage the cloud scalability of Azure, there are several things to consider before you make the move.

1. Don’t Use In-Proc Session Management. In web development, it is very common to use sessions. Sessions are for local web servers which are not accessible outside of the server. Azure web apps are designed to be scaled out, meaning you will often have multiple instances running.  When running behind a load balancer, each request can be directed to any of the available instances which might not be the same one that holds the session state from the last request.  If your web app currently uses in-process session management, you’ll want to change that to save the session data external to the web app.

Alternate solution: Use distributed caching. Azure offers Redis Cache which is a managed caching service. Use Redis cache for more enterprise approach. Managed Cache and In Role cache are mainly for legacy approach. Redis is recommended. Learn how to use Redis Cache for ASP.NET Session here. 

2. Avoid Windows Authentication in SQL Server. Windows Authentication and SQL Server is very common in Line of Business Applications. This allows easy access and setup. You can leverage AD security groups to allow access to backend SQL Databases. This solves additional coding efforts while defining various levels of security and access to database. However, this may not work if you move your application to Azure in platform as a service mode.

Alternate solution: Use SQL Authentication wherever possible. If you move your database to Azure SQL Database then you have only SQL Authentication available. Also, you need to understand the limitations of Azure SQL Database and SQL Server (on-premises). Please refer to the official documentation here. An alternate solution could be to use WCF service with Azure Service Bus to connect the on-premise database.

3. Replace Windows Service. Often web applications use Windows Service to perform backend activities like cleaning up system or database job. In Azure, you have Windows Service when you have an application hosted in a VM (Infrastructure as a Service). But in most cases, this is not an elegant solution.

Alternate solution: The best approach is to take the CQRS pattern with Worker Role. Another option is to use Web Jobs with Web Apps. But avoid Web Jobs for large processing as it stays in the same machine where your Web App is. This might create bottlenecks for your web portal during long memory consuming activity. Learn more about Web Jobs here. If the processing is very large and needs a lot of computing resources, use Azure Batch.

4. File Upload to local. In many Web Applications, there is a file upload feature such as an image or a document. The immediate solution is to upload these files and keep them in a local web server folder. However, this is not a good design in distributed scenario.

Alternate solution: Use Azure Blob Storage.  Learn more about .NET API of Azure Blob here.

5. 3rd party component. Any 3rd party component which requires installation and should be in Global Assembly Cache (GAC) should be avoided. Otherwise you could go for Virtual Machine in IaaS mode.

Alternate solution: The only option of deploying it to Infrastructure as a Service. Otherwise you can also use Cloud Service and start-up task to deploy them. However, all the installers should have silent installation option.

6. Select right platform for right kind of application. If you need to move Web App as Lift and Shift mode, go for IaaS. Web Apps is the best choice over Cloud Service.

Alternate solution: There is simply not a one-size-fits-all solution. Select a platform based on your business needs.

7. Authentication and Authorization. When we move on-premises Web Applications to the cloud, the integrated Windows authentication goes away. Plan accordingly.

Alternate solution: Leverage Azure Active Directory as an immediate solution with Directory Sync. This, however, requires code changes as we need to use OAuth or SAML. This is the biggest road block in migration.  Learn how you can authenticate ASP.NET Web Application with Azure Active Directory here.

8. Don’t create the deployment slot for Web Load Test. Once you create a deployment slot, it creates the web app in the same virtual machine. Running Load Test would consume the shared CPU and RAM which is definitely a performance issue if you are running a live site.

Alternate solution: Create a separate Web App for testing.

9. Implement SSL. Implement SSL using a valid certificate from a recognized certificate authority. SSL is not something you think about on-premises, but you need to be mindful of security issues when moving to the public cloud.

Alternate solution: A valid certificate form CA and CNAME mapping with domain centric binding will ensure your authenticity. You can find the steps on how to implement SSL here.

10. Scale-out not Scale-up. Increasing the VM capacity does not guarantee the best performance. Select the distributed approach.

Alternate solution:  Use Auto Scaling if possible rather than waiting for things to break. Test, test and test until you are satisfied.

Migration consideration and methodology

Several things should be considered when moving an application to Microsoft Azure, including:

• Application compatibility: Analyze if the application is an architectural fit for Microsoft Azure before moving.
• External / internal dependencies: Check for external application dependencies and determine if they are accessible through Azure.
• Application class: Verify how the application is classified in the business. Business critical and LOB applications demand high availability.
• Application integration: Check whether the candidate application is integrated with other on-premise applications and shared services.
• Database compatibility: Analyze whether the existing database is the best fit to migrate to Azure.
• Application maintenance / management: Identify how the logs are maintained and where they are stored.
• Scalability / elasticity: Identify whether the application design supports scalability as Azure supports it.
• Compliance requirements: See if there are enterprise compliance and regulations that govern whether the data can be moved / stored outside the enterprise’s control.
• Cost: Verify whether the moving application is cost-effective for the enterprise.
• Security: Clarify whether the same level of security can be provided after migrating to Microsoft Azure in terms of data security, authentication and authorizations. 

Migration strategy / approach

UI analysis: Analyze if the UI interface can be migrated to Azure directly in the PaaS model.  Web applications and web services in non-cloud solutions can be mapped to Microsoft Azure web roles, while the non-web applications are kept on-premise. Re-engineering work is required to modify the existing web application code to use Windows.

Azure SDK: This ensures that it runs on Microsoft Azure as hosted Cloud services. In addition, if any third-party framework / class library that is not supported by Azure is used, the library may need some modifications or, will have to be re-written.

Infogain can help you with the migration process. Contact cloudservices@infogain.com.

Infogain (www.infogain.com) provides front-end, customer-facing technologies, processes and applications that lead to a more efficient and streamlined customer experience for enterprises in the US, Europe, the Middle East, Asia Pacific and India. Offering solutions for the high-tech, retail, insurance, healthcare and travel & hospitality verticals, Infogain specializes in areas such as software product engineering, digital service automation, cloud, mobility, testing and business intelligence & analytics. The company has 9 delivery centers and close to 4000 employees globally. Infogain has a customer retention rate of 90%+ over a five-year period.