This post should really be title: “how we (could have) migrated ScrumWall to Azure in less than 20 minutes”. But I’ll come on to that later.

I’ve been speaking about Azure at a number of events recently. As part of the talks, I have given a quick overview of the developer portal for Azure and the Visual Studio tools. I’ve wrapped this up in a demo using our ScrumWall product (http://scrumwall.cloudapp.net).

Winding back time conveniently to about a year ago, I explain how we could have migrated ScrumWall to Azure in less than 20 minutes. I then go on to highlight some of the additional requirements that would be required to enable this to be managed, supported and maintained in production.

The Demo

The majority of functionality provided by ScrumWall is contained in a Silverlight application. There are a number of WCF services to provide data to this application and some fairly basic ASP.NET pages. There are also a couple of HTTP handlers to manage the authentication, which is provide by Microsoft Live ID.

Overall ScrumWall contains a reasonable number of different components and is a good “test” candidate to migrate to Azure.

Step 1: Creating the SQL Azure Database

Using the “Generate Script” option to script the whole database (including the triggers used for audit) produces something very close to the SQL needed e.g. for the Story table the following SQL is generated:

CREATE TABLE [dbo].[Story](
    [StoryId] <removed_for_clarity>
 CONSTRAINT [PK_Story] PRIMARY KEY CLUSTERED 
(
    [StoryId] ASC
)WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, IGNORE_DUP_KEY = OFF,
 ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]
) ON [PRIMARY]
GO

This can be modified as follow to make is SQL Azure compatible:

CREATE TABLE [dbo].[Story](
    [StoryId] <removed_for_clarity>
 CONSTRAINT [PK_Story] PRIMARY KEY CLUSTERED 
(
    [StoryId] ASC
)
)
GO

Any data that needs to be migrated can be scripted (as this is a small application).

Step 2: Update the web.config

The existing connection string is simply replace with a new one, ensuring that encrypt is set to true:

<add name="ScrumwallConnectionString"
    connectionString="Data Source=v2wqed1zpx.database.windows.net;
Initial Catalog=ScrumWall; User ID=scrumwall@v2wqed1zpx;Password=password;
Trusted_Connection=false;Encrypt=true;"
    providerName="System.Data.SqlClient" />

Step 3: Creating a Cloud Project

To migrate the ASP.NET application project to Azure, first I add a new Windows Azure Cloud Service project with no Web or Worker roles. Then by using the option to add a Web Role project from the solution, I can associate the existing ASP.NET project with the Cloud Service project.

Testing this locally in the Development Fabric means using a different port, port 81 for my machine. In order to ensure that Live ID redirects my authenticated users back to the correct place I need to create a new Live Services application ID (https://live.azure.com/). I have used the “domain” of “azure.machine.local” and the return URL “http://azure.machine.local:81/LiveAuthHandler.ashx”. Next I add an entry into to my hosts file, a mapping of host name “azure.machine.local” to 127.0.0.1. Last, the web.config is updated with the new application ID and secret:

    <add key="wll_appid" value="0000000044028C05"/>
    <add key="wll_secret" value="x1x1x1x1x1x1x1x1x1x1x1"/>

I can now run the application on my local Development Fabric.

Step 4: Deploying to Azure

The migration is nearly finished. However, before I can publish this application to Azure, I need to create another Live Services application ID for the final domain “scrumwall.cloudapp.net” and once more update the web.config.

The application can now be published to Windows Azure and deployed. To ensure that the Windows Azure application can connect to SQL Azure, tick the Allow Microsoft Services access to this server.

All of these steps including running the newly migrated project by clicking the http://scrumwall.cloudapp.net can be completed in less than 20 minutes!

The Real World

Now in the real world, there are a significant number of real world questions that you need to ask before migrating an application to Azure, for a fuller list check out this book: http://www.dotnetsolutions.co.uk/blog/archive/2009/11/04/“thinking-of-delivering-solutions-on-the-windows-azure-platform”-book-now-published/.

For ScrumWall there are three areas in particular that we chose to address as part of our real migration of ScrumWall to Azure:

1. Management of configuration values, in particular the Live Services application ID. This is discussed here: http://www.dotnetsolutions.co.uk/blog/archive/2009/04/23/moving-scrumwall-to-the-windows-azure-platform-part-3-windows-live/
2. Use of Windows Azure Table storage in preference to SQL Azure. This is discussed in another previous blog: http://www.dotnetsolutions.co.uk/blog/archive/2009/02/24/moving-scrumwall-to-the-windows-azure-platform-(part-1-the-data)/
3. Access to logging and diagnostic information. This has been significantly improved from the early CTP for v1 of Windows Azure and has been well covered elsewhere, for instance: http://blogs.msdn.com/windowsazure/archive/2009/12/01/introducing-windows-azure-diagnostics.aspx

The Big Demo Challenge

On a side note, one of the biggest challenges for the demo was actually connecting to SQL Azure from SQL Server Management Studio. Often firewalls will block port 1433/1434 outbound and this a major hassle to get changed, especially for a 20 minute demo. For more information on one approach to resolve this issue see my next blog post.