Migrating the Microsoft Hong Kong Company Store to Windows Azure Simplifies Maintenance and Decreases Costs
Published: June 2011
The Microsoft IT organization migrated an internal line-of-business application to Windows Azure™ to save costs, increase availability of the application, and learn about using the platform. The experience and lessons learned have provided valuable input for future migration project plans.
Article, Microsoft Word file, 112 KB
Products & Technology
Members of software development teams
Microsoft IT delivers and manages agile solutions that provide location-specific business capability requirements that global solutions do not provide. As part of the larger Microsoft IT organization, Field IT also participates in the early adoption of new and emerging Microsoft products and services. This article explains how the organization completed migration of a local line-of-business application to Windows Azure, the knowledge that the team captured during migration, and the benefits that have accrued following the project’s completion.
One of the benefits of being a Microsoft employee is the ability to purchase certain Microsoft products at a reduced price. The Microsoft Hong Kong Company Store is an application that supports the local employee purchase program for the Hong Kong subsidiary. It provides product catalog details, order processing, and notification functionality. The Microsoft Hong Kong Company Store opens for business 2 weeks in every 2 months. This cyclical usage pattern makes it an ideal candidate for the Azure platform because it can take advantage of one of the key characteristics of cloud computing – elasticity: the ability to easily scale resources out and back to match changing demand patterns. The application is small in scale, has a simple design, and has approximately 27,000 lines of code. The database size is 250 MB and contains 30 stored procedures.
Building the Business Case and Planning the Project
Before starting the Microsoft Hong Kong Company Store migration project, Field IT analyzed its portfolio of applications. This analysis included segmenting the portfolio into various categories of applications based on business criticality of the processes that each application supports, classification of the data that each application utilizes, complexity of the existing solution, size of the solution, and capabilities and limitations of the new platform. Based on the analysis, Field IT defined a sequence for migration opportunities. Field IT identified the Hong Kong Company Store as an early migration candidate because it was small in scale, was not business critical, and there was good financial justification for migration.
Following the initial high-level analysis, Field IT conducted a more detailed analysis for the first group of potential projects. Field IT used tools available from the Windows Azure website (http://microsoft.com/windowsazure) to assist with estimating the cost of the migration effort and future Azure hosting charges. Field IT used existing hosting charges in combination with the Azure estimates to provide a comparison of costs between on-premises hosting and cloud hosting.
Any adoption of new technology has some element of risk, and the business case that Field IT built for the migration project included both the list of risks and the management plan for each identified risk. To help the business stakeholders better understand the risks and opportunities that Field IT presented in the business case, the kickoff meeting started with an overview of cloud computing, the Azure environment, the MSIT adoption strategy, and the approach for this specific project.
Software projects at Microsoft follow a standard methodology with well-defined roles and responsibilities. The move to cloud computing and Azure hosting has an impact on some controls, roles, and responsibilities, and MSIT is updating the methodology to take account of these nuances. However, the core of the methodology and its controls remain intact, and Field IT followed them throughout the project.
Redesigning for Azure Hosting
Microsoft Hong Kong Company Store data is classified as Low Business Impact (LBI). LBI data is typically data that is already in the public domain. If the data is compromised and someone establishes unauthorized access, this breach would not have any significant impact on Microsoft’s ability to continue doing business. Following the security guidelines of Microsoft IT, LBI applications can be hosted on Windows Azure and Microsoft SQL Azure™. Considering the size of the application, data classification, and security guidelines, Field IT chose a full public cloud deployment for the migration project.
Field IT identified the following areas to make the application ready to be migrated to the Azure platform.
Authentication via ADFS
When the Hong Kong Company Store application was hosted on premises, it used Microsoft Windows® authentication, validating against the Microsoft corporate Active Directory (AD). Employees could only connect to the application when the computer was connected to the Microsoft corporate network.
The Azure hosted solution uses Microsoft Active Directory® Federation Services (ADFS) to implement 1st-level authentication. The user can still connect to the application from within the corporate network. The application captures Windows credentials and sends them to ADFS for validation. Windows Identity Foundation (WIF) validates these credentials with the help of ADFS (residing in the Microsoft corporate network). Valid users are redirected to the application with a valid security token. This process is also known as claims-based authentication.
When a user tries to access the application from outside of the Microsoft corporate network, the user will be presented with a login page to enter the AD credentials manually. WIF and ADFS (again residing within the Microsoft corporate network) then validate the credentials.
Using Azure Storage Tables for Session State Management
Azure Web Roles are stateless and cannot load balance Web Roles with session affinity.
An organization can choose between the following ways of adding session state management to their applications to address the stateless nature of Azure Web Roles:
Using SQL Azure Database and a Custom Session provider for SQL Azure.
Using customized ASPProvider dlls to save session data into Window Azure Storage
For this migration project, Field IT used the second approach. It performed the following steps to configure the ASPProvider dll:
Add customized ASPProvider dll reference into Web Role project in Microsoft Visual Studio®.
Modify the web config file to change session management to out of proc by adding the custom provider (ASPProvider DLL), and capture the session details in Azure storage.
Outgoing Email Using Exchange Server DLLs via on-Premises Exchange Server
Emails cannot be sent from an SMTP server hosted on Windows Azure because the platform does not currently support that functionality.
An organization can adopt either of the following ways to send emails from an application via Windows Azure:
Use Exchange Server DLLs to pass messages to an Exchange Server that then recreates and sends the emails.
Populate an Azure Storage Queue with the email content (recipients, subject, body, etc.) and deploy a service that continuously polls the queue and transmits the email information to an on-premises SMTP server.
Field IT adopted the first option for this migration project. This option does not require any additional on-premises server and could be implemented with minor code changes. The second option would have required on-premises servers to host the service to relay emails using on-premises hosted SMTP servers and also would have increased the cost of ownership because of increase in usage of Azure storage.
Storage of Product Images in BLOB Storage
The original Microsoft Hong Kong Company Store application maintained product image files in a local folder on the web server. Maintaining the files in a local folder of a Web Role is a risk because of the stateless nature of the Azure Virtual Machines (VMs). If a VM crashes for any reason, Azure brings up a new VM and automatically deploys the application on to it. Any steps that have been performed after the automatic deployment are not part of the deployment; therefore the product images, if they were stored and maintained in a local folder, would be lost.
To avoid this scenario, the new solution stores image files in Azure storage binary large objects (BLOBs ). The Web Role reads the image files from the BLOB dynamically for presentation in the user interface (UI). With the files available in common Azure storage, additional Azure instances can be created to handle increased traffic and each instance can access the same BLOB storage.
Error Logging and Storage of Error Logs in BLOB Storage
Error logging is as important on Windows Azure as it is on any other platform.
Field IT created a reusable service/component for error logging that can be used across other applications also. The service collects logging information from the application and saves it to BLOB storage for later retrieval by support and analysis team members. Because BLOB storage is persistent, it is be possible to view the log information, even if the virtual machine that the application is hosted from is offline or no longer exists.
Excel File Processing
Administrators can use a Microsoft Excel® import feature to upload product details. Excel processing happens synchronously in the application: The application updates the data in the database as soon as the application administrator uploads the Excel file.
The project team used Microsoft Office Open XML to implement the Excel processing feature. Once the Excel file is processed, the file is stored in Azure storage as a backup and also to ensure that it is available for all VM instances of the application.
Tool to Manage Azure Storage
Field IT created a custom tool to provide a simple interface for administrators to manage the files and content saved in the Azure storage. Administrators use this tool to upload new images, delete images, update images, and preview the images. Support staff also uses the tool to download and preview error logs as a first step to troubleshoot any issue.
Deploying the Application on the Azure Platform
The Windows Azure portal allows developers and/or support personnel to deploy the application with the click of a button. Support professionals can log in to the internet hosted Azure portal from anywhere to deploy the application. No special skills or software are required to complete the deployment.
In an on-premises solution, a production support team has to manually handle requirements like server configuration and load balancing. This effort requires special skills and planning, in addition to downtime of the server and application while the deployment is taking place. However, the same features and settings are part of the Azure platform and can be set just by changing some configuration values without considerable downtime. Configuration details required for a deployment are settings related to number of instances, storage locations, and certificate thumbprints. With an application such as the Microsoft Hong Kong Company Store that has variable usage patterns, the ability to increase or decrease the number of instances with a change to a single configuration value means that the environment can be sized and resized as needed, rather than sizing for peak loads.
By using the Azure portal, Field IT administrators can easily manage certificates required for the application to use a secure data transport layer via SSL (secure sockets layer or “https”) and ADFS authentication. Field IT administrators upload the certificate into Windows Azure portal initially to use it. When the certificate expires, they upload the renewed certificate without affecting the application.
Database deployment can be done in two ways in SQL Azure.
Using SQL Management portal or using batch file setup as it is done in an on-premises scenario.
Using the Database Manager for SQL Azure (formerly known as Project Houston https://manage-sgp.cloudapp.net/), which is a web-based SQL Azure database management portal where you can execute stored procedures and required scripts to deploy the database objects. This same portal can also be used to query the database and perform many other operations on the database. This tool does not need any software to be installed nor will any Firewall rule settings affect the access. This portal can be accessed from anywhere.
The migration has enabled the removal of the typical application infrastructure support tasks from in-house IT, because these are all provided as part of the Azure service and covered in the Azure Service Level Agreement (SLA). To date, the system has been reliable—Field IT has experienced no infrastructure-related issues.
Managing ongoing general maintenance has become much easier. There is no longer a need to schedule hardware-related maintenance tasks. In addition, ongoing hosting and maintenance costs have decreased by about 50%.
End users can now access the system from anywhere and from any type of device that has browser support, which provides greater convenience and increased user satisfaction.
Lessons Learned and Best Practices
Important lessons that Field IT learned from the migration project include:
Migrating existing applications to Azure hosting is not a difficult exercise.
Cost reductions are real and achieved from day 1.
It is likely that there will be a need for redesign and refactoring of code as described in the Redesigning for Azure Hosting section.
These and other lessons have led to the following best practices:
Spend time in advance to prepare for stakeholder and business owner conversations. This ensures that all stakeholders have a common understanding of the expected benefits and risks and instills a sense of confidence in IT’s ability to deliver value.
Spend time up front getting a deep understanding of cloud computing and share the appropriate level of knowledge with stakeholders to facilitate an open and honest conversation.
In building a business case for the project, include the cost of redesigning and refactoring code, together with estimated hosting charges.
Engage early with all IT roles, work through the challenges together, and be prepared to adjust plans and decisions if necessary. This effort will help minimize the impact of the migration on the support organization.
Identify functions that will be required by multiple applications and design and build them in a way that they can be deployed as common services where possible. Examples from this project include session state management, email handling, error logging, and storage functions as described in the Redesigning for Azure Hosting section.
Migration to the Windows Azure platform has resulted in a 50% reduction in hosting and maintenance costs.
The move required some redevelopment work, but Field IT took opportunities to build reusable components that will reduce the cost associated with future application migrations.
Migration to the Windows Azure platform improved the user experience by making the application available from both inside and outside of the corporate network.
Products & Technologies
Microsoft Active Directory Federation Service (ADFS)
Microsoft ASP .Net 4.0
Microsoft Exchange Server
Microsoft Open XML
Microsoft SQL Azure
Microsoft Visual Studio
Microsoft Windows Azure
Microsoft Windows Azure Storage
For More Information
For more information about Microsoft products or services, call the Microsoft Sales Information Center at (800) 426-9400. In Canada, call the Microsoft Canada information Centre at (800) 563-9048. Outside the 50 United States and Canada, please contact your local Microsoft subsidiary. To access information through the World Wide Web, go to:
This document is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS SUMMARY. Microsoft, Active Directory, Excel, SQL Azure, Visual Studio, Windows, and Windows Azure are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries. The names of actual companies and products mentioned herein may be the trademarks of their respective owners.