Factors to Consider before Deploying Application on Web Role

One of the first project real time assignment which we encountered during our Azure journey was moving Classic ASP website into Azure Platform with minimal or no code changes.  It was a kind of nightmare as our estimations got royally screwed and developers ended spending day and nights fixing all those classical session and COM integration related issues. However moving Classic ASP website to Azure might be an rare exception (refer my friend Girish's blog to understand more about this), i am going to list out factors which we need to consider while moving an Existing or new websites and web applications written using ASP.NET, MVC, Razor, or other .NET Framework technologies.

Distributed session state and output caching must be handled differently in an Azure Web Role from the typical process on-premises. You cannot use the ASP.NET State Server or the SQL Session State Provider. Instead, you configure an instance of the Windows Azure Cache Service and configure your application to use this, or use a third-party solution that saves data in Azure Storage instead.

 You must decide how you will store and access the data that the application uses. For simplicity, if an existing application uses a SQL database, you can upload the data into SQL Azure and access it in the same way as you would an on-premises SQL Server database. However, you may decide to use Azure Storage Tables or Blobs instead, which can prove less expensive but do not provide the same capabilities or performance as SQL Azure.

You cannot access the underlying operating system in the same way as you can when running code on a physical machine or in a VM Role. This prevents you from using COM components, accessing some system logs, and interacting with some operating system services.

If you depend on Windows authentication or use Active Directory for authorization (such as setting permissions on website folders and resources) you must rework the application to use ASP.NET Forms authentication and authorization, claims-based authentication, or a suitable custom implementation. Windows Azure Access Control Service (ACS) and Windows Identity Foundation (WIF) make it easy to implement federated claims-based authentication and authorization, and single sign-on. 

Unlike a web application running locally in IIS, changes to the Web.config file for a web application are not automatically applied at runtime. Instead you can place the settings in the Azure service configuration file so that changes are applied when you upload a new version of this file.

There is no local SMTP server for sending emails, though you can open port 25 for your Azure deployment and use an external email server.

You can configure a virtual NTFS volume to use in a similar way to a hard disk drive, but consider using other approaches such as Azure Blob storage for images, resources, and downloadable files. You can maximize the user experience and reduce load on your application by locating images, resources, and downloadable files on the Windows Azure Content Delivery Network (CDN).