how much of a challenge is it to port a asp.net application to azure?

Question

I have a partly developed asp.net application, but now the client wants it to be developed in azure. How much of the existing code can be used in developing the application

Answer 1

Azure now supports Web Sites as a deployment type. Basically this allows you to publish any standard Asp.net (and other supported like PHP etc) application to Azure and have it as a scalable server. See this article http://blog.ntotten.com/2012/06/07/10-things-about-windows-azure-web-sites/

Many of the benefits of Azure without having to introduce Azure specific code/Project to your existing application.

Also this question here What is the difference between an Azure Web Site and an Azure Web Role

Answer 2

It should be very easy to port your application to Azure--especially if you're using a SQL back-end. The code could run almost without modification. You'll need to create an Azure installation package for the project and configuration file.

If your application makes use of persistent storage (other than SQL Server), you may have to rework that code somewhat. However, the platform now has drive storage, which simulates a file system, so this should be fairly easy.

Another issue to watch out for is web.config. If you make heavy use of this for runtime customization, you'll have to rework that too. You can't deploy single files to your application in Azure, so the recommended approach is to migrate these sort of settings to the Azure config file.

The hardest thing you're likely to encounter is external applications. If your app relies on launching other processes, then this will require some serious redesign.

Answer 3

For an asp.net application, you can certainly port that to Azure. Your core logic will port in a relatively straightforward manner, and you'll gain the many benefits Azure has to offer. With the June 2010 release, you'll also have .NET 4 support, along with IntelliTrace for debugging.

However, as you begin to plan your Azure migration, there are several considerations you'll need to think about (none of them insurmountable, and several relatively simple to deal with):

• You have to deal with ASP.NET Session State management across your web role instances (which isn't supported out of the box, except for inproc). You'll also have to set up and use the role and membership providers (see here for more detail). EDIT: You now have access to both AppFabric Cache for session state as well as SQL Azure, part of the Universal Providers included with the Windows Azure SDK+Tools.
• You have to examine your SQL backend for incompatibilities with SQL Azure (such as scheduled jobs,since there's no SQL Agent support). SQL Azure differences are documented here. You'll also need to consider the SQL Azure size limit of 50GB, which might require you to offload content to Azure blob storage. EDIT: You can run your SQL Server database through the SQL Azure Migration Wizard for compatibility-testing.
• You need to configure logging and diagnostics, preferably with Trace output, so that you can retrieve this data remotely.
• You need to think about how you'll monitor and scale your application. All information you might need for scaling is available to you (performance counters, queue lengths, etc.). Check out WASABI - the auto-scale application block, part of Enterprise Library. You can also subscribe to a service such as AzureWatch.
• You'll need to think about caching, as there's currently no out-of-the-box caching implementation that runs across instances of your web role which is now provided as a service. Read details here, as well as an FAQ here.
• Do you need SMTP support? If so, there are details you should read about here. SendGrid recently announced a free-tier promotion for Windows Azure.
• Are you hosting WCF services as well? If so, check out this site for further details (specifically the Known Issues).

So: yes, there are some things you need to concern yourself with, but Azure is a great platform for hosting an asp.net application and you should strongly consider it.