During Windows azure migration, there are various concerns which crop up regarding storage, dependencies, session states etc.

Following are the major concerns which needs to be addressed, and a plan charted out prior to migration.

1. Storage

Windows azure migration would require complete application data migration, and this is a primary concern for many who are contemplating a move to Windows Azure. Depending on the need of the application, there are various options presented in the Windows Azure environment. If an application requires full SQL Server functionality, Azure Virtual Machines (VMs) are the ideal solution. Azure provides built in data services in the form of SQL Server relational storage and non-relational data storage services; using Tables, Blobs and Queues.

More here

Local Storage

In a Windows Azure Web or Worker Role VM, the application has access to read and write to the local storage. However, given the stateless nature of VM instances in Azure, local storage is transient. Therefore the data that needs to be persisted must be stored outside the VM instance.

Data on the local drive is not synced with the drives of other VM instances of the application.

Therefore, new instances (added for capacity or restoration of failed VMs) will not have access to data persisted to local storage. Data on the local drive does not survive if an application deployed is subsequently deleted from Azure, and then later re-deployed. If the application does depend on the local drive for durable storage, you will need to plan for moving that data to either Windows Azure Storage or Windows Azure SQL Database.

Windows Azure SQL Database (formally known as SQL Azure)

SQL Database service offers a subset of SQL Server’s features and functionalities and hence some features of our application database may not be present in SQL Database. Analysis Services, Replication, Service Broker, DB Chaining and DB Mail are some of the features not currently provided as services on the Windows Azure platform. Hence,in planning a migration you will need to investigate where your application makes use of unsupported features.

Windows Azure Storage

As described in Local Storage above, if the application makes use of the local file system for durable data then moving that data to Windows Azure storage is our recommended practice. You should store static content such as script files, CSS style sheets, videos and images in blob storage. These static files can be served directly by the web server in the application’s VM.  However, by moving them to blob storage, they are served to the users directly by the Windows Azure Storage service. Employing blog storage helps in reducing the load on the web server and also enabling us to later take advantage of Windows Azure’s Content Delivery Network (CDN).

2. Dependency

Windows Azure environment does not include 3rd party frameworks/libraries such as MS Enterprise library or MVC framework. So if the application depends on other components then you must add those to the applications deployment service package.

Before you build and package your application, verify the following:

      • The Copy Local property is set to True for each referenced assembly in your project that is not part of the Windows Azure SDK or the .NET Framework, if you are using Visual Studio. If you are not using Visual Studio, you must specify the locations for referenced assemblies when you call CSPack. For more information about using CSPack, refer here.
    • The web.config file does not reference any unused assemblies in the compilation element, and all references point to assemblies that are either part of the .NET Framework or the Windows Azure SDK, or that have their Copy Local property set to True in Visual Studio, or that are included in the application package by running CSPack
  • The Build Action of every .cshtml file is set to Content. This ensures that the files will appear correctly in the package and allows other referenced files to appear in the package

More here

3. Session State

Windows azure migration results in a common concern regarding session state. With Windows Azure Web Roles supporting full IIS, the inclination to fall back to tried and tested methods of storing session in-proc, out-proc and in SQL Server is very tempting. Butsince the Windows Azure load-balancer does a round robin routing of the instances and there are no sticky sessions in Windows Azure, you can’t use in-proc session storage. Moreover, a VM instance can get recycled due to a host or guest upgrade apart from the regular code upgrades.

It is recommended to use the following ways to store sessions in Windows Azure web roles

      • Table Storage with the Table Storage Provider
      • SQL Azure with ASP.Net Universal Provider
      • Windows Azure Cache with Dedicated Cache Role

More here

4. Make configurations via. ServiceConfiguration.clouc.cscfg

In Windows Azure, the web.config file is deployed as a part of the service deployment package. Due to the stateless nature of the VM instances in which the application’s config file resides, changes to the web.config file on running instance will render the application to not work properly. This is because these changes wouldn’t be synchronized across all of the instances of the role and wouldn’t be available to the new instances. Changes to the web.config file require a new deployment service package to be created, and a new deployment to be pushed to Windows Azure. To effectually configure we recommend you migrate the application configuration settings to hosted service’s ServiceConfiguration.cloud.cscfg file in the Windows Azure deployment project.

More here

5. Authentication

An application migration to Windows Azure would require that the authentication process still function seamlessly. Windows Authentication is not available “out of the box