Export (0) Print
Expand All

How Microsoft IT Architected and Redeployed a Business Critical Application to Windows Azure

Technical Case Study

Published: August 2011

The following content may no longer reflect Microsoft’s current position or infrastructure. This content should be viewed as reference documentation only, to inform IT business decisions within your own company or organization.

Microsoft IT identified a business-critical internal application, Business Case Web (BCWeb), for migration to the new Windows Azure platform to establish best practices and create reusable processes for future migrations. BCWeb had reliability and performance issues in its previous environment and met the criteria set for the pilot project. By using the Windows Azure platform, Microsoft IT migrated BCWeb to a more reliable, more scalable solution. Additionally, they also determined a number of best practices and reusable components to apply to future enterprise application migrations.


Download Technical Case Study, 353 KB, Microsoft Word Document 


Target Audience



IT Decision Maker, IT Implementer

Microsoft IT identified a complex, distributed application to migrate to the Windows Azure platform as a showcase project and to develop best practices for future migrations. The selected application, BCWeb, was an internal web-based suite of applications that was experiencing performance and reliability issues. Additionally, Microsoft IT wanted to migrate an enterprise–level application, and BCWeb fulfilled that need.

BCWeb was migrated to the Windows Azure platform, which resulted in increased performance and reliability. The application's integrity was improved, and secure and reliable integration with on-premises components was built into the new solution on Windows Azure. The migration project also resulted in key best practices and reusable components that Microsoft IT could leverage in future migrations.

  • Increased application performance and reliability.
  • No hardware maintenance is required on the Windows Azure platform.
  • Much of the original application reused, with some refactoring.
  • Reusable development components that can be leveraged in future migrations
  • Best practices derived from migration challenges and solutions.


BCWeb is an internal, web-based application that Microsoft employees use to create business cases for exemptions to product pricing. BCWeb has three distinct application components, with the core component providing an interface and underlying functionality that enables users to generate business cases for pricing exceptions. The Workflow Routing and Approval system (WRAP) is the second component, and it routes pricing-exception requests for approval within the Microsoft corporate infrastructure. Rapport, the third component, provides a user interface for the WRAP approval process. BCWeb has a user base of 2,500 internal Microsoft employees, and in 2010, employees used it to process approximately 27,000 pricing-exception requests.


Microsoft IT was searching for an application to showcase both the ease of migrating applications to the new Windows Azure™ platform, as well as the platform's extensive capabilities. Additionally, Microsoft IT planned to use the migration to develop best practices and reusable components that it could leverage in future migrations.

BCWeb Legacy Status

BCWeb was originally deployed in late 2007 as a primarily Microsoft Office SharePoint Server 2007–centric solution. Microsoft developed separate user interfaces for the production of business-case documents and for the management of the workflow and approval process. Transactional data for pricing exceptions was stored as individual documents within the SharePoint database as individual SharePoint documents.

Since its inception in 2007, BCWeb had undergone several important architectural changes, including the implementation of network load balancing (NLB) in 2009. Additionally, in 2009, Microsoft IT initiated a re-architecture project to increase application reliability, and then in 2010, migrated the storage component from SharePoint storage to a solution based on Microsoft SQL Server®.

Due to the nature of the information that employees access and use in BCWeb, the application was integrated with several on-premises components hosted on the Microsoft corporate network (corpnet). These components primarily provide access to external data that BCWeb functionality requires. Microsoft considers the information that BCWeb accesses and contains to be important business data, so Microsoft IT had to ensure that it was secured accordingly.

Figure 1. Legacy Architecture of BCWeb

Figure 1. Legacy Architecture of BCWeb

Performance and Reliability Issues

In 2008, Microsoft IT introduced a new pricing-exception type in BCWeb that caused an eight-fold increase in BCWeb traffic. This rapid traffic increase resulted in significant performance and reliability issues for BCWeb, because the existing application infrastructure could not handle the workload. The application was unstable, and even offline at times, during peak usage at month-end, quarter-end and year-end periods.

Despite attempts to alleviate these issues through load balancing, architectural changes, and data-storage changes, the performance and reliability of BCWeb were not adequate.

Choosing the Windows Azure Platform

The Windows Azure platform provides a hosted, location-independent environment for hosting applications and their supporting data and infrastructure. Microsoft administers hardware-implementation and maintenance in its data centers, through Microsoft cloud services, which enables customers to focus on their application development and deployment. Microsoft operates the Windows Azure platform at high availability and reliability, and benefits from the related economies of scale (cost savings from high volume operations) that it then passes to customers and partners.

In the case of BCWeb, many aspects of the application environment led the Microsoft IT team to choose Windows Azure as the target platform, including the ability to reuse significant amount of application code, increased application portability and the ability to automate considerable portions of the application migration.

The following attributes made BCWeb a good candidate to migrate to Windows Azure:

  • Developed using the .NET Framework
  • Hosted on Internet Information Services (IIS) servers
  • Uses SQL Server databases

Additionally, the team recognized that the Windows Azure platform includes several built-in scalability and high-availability qualities that would enable BCWeb to be both flexible and efficient in handling variable workloads and peak usage times.


Once Microsoft IT chose the Windows Azure platform, the team designed a solution that would ensure that the new BCWeb deployment would be useful as a migration showcase. The design also enabled BCWeb to take advantage of the benefits that the Windows Azure platform provides.

Design Goals

Microsoft IT identified several key design goals that the migration project should fulfill:

  • BCWeb, Rapport, and WRAP should be maintained as physically and logically separate applications to ensure the most flexible environment for future application development.
  • All network traffic should be encrypted end-to-end by using trusted certificates.
  • All Windows Communication Foundation (WCF) endpoints should be internal to the application, unless external exposure was absolutely necessary.
  • The new application infrastructure should remove any SharePoint dependencies.
  • Integration with, and dependency on on-premises components should be as efficient and replaceable as possible.
  • The application's architecture, once migrated to Windows Azure, should be scalable to handle usage peaks, without affecting application performance.
  • The application's architecture, once migrated to Windows Azure, should eliminate single points of failure that existed in the legacy application's architecture.

Design Collaboration

The Microsoft IT Volume Licensing group collaborated with Accenture, a global management consulting, technology services and outsourcing company, to design and implement the migration of BCWeb to Windows Azure. Accenture supports many internal Microsoft IT applications, including BCWeb, so they used assets and accelerators from their Azure practice group to increase the speed of the assessment and migration process.

Remapping the BCWeb Architecture to Windows Azure

Maintaining the design goal of separating the BCWeb component applications, Microsoft IT mapped each application, and its core components, to separate Windows Azure services and roles.

BCWeb Architecture

BCWeb was comprised of three core components: the web-based UI, background services, and data storage. The web-based UI was mapped directly to the Windows Azure Web role. The BCWeb services and background processes were split into two groups, and Microsoft IT mapped each to a Windows Azure Worker role. The WCF services were assigned to one Worker role, while the background processes and notification mechanisms were assigned to another Worker role. Finally, Microsoft IT mapped the SQL Server database components to Microsoft SQL Azure™.

Table 1. Mapping BCWeb Components to Windows Azure Roles

BCWeb Component

Windows Azure Component


Web role

WCF services

Worker role

Background processes

Worker role

SQL Server databases

SQL Azure

On-premises components

AppFabric ServiceBus

WRAP Architecture

Similar to BCWeb, WRAP's Worker roles also were split. One Worker role hosted the WCF services, such as the WRAP service and the workflow process, while the other Worker role contained notification and provisioning components. As with BCWeb, WRAP's SQL Server database components were mapped to SQL Azure.

Table 2. Mapping WRAP Components to Windows Azure Roles

WRAP Component

Windows Azure Component

WCF services

Worker role

Background processes

Worker role

SQL Server databases

SQL Azure

On-premises components

AppFabric ServiceBus

Rapport Architecture

Microsoft IT continued with the separation of the three main application components by establishing an additional Windows Service for Rapport. Rapport consisted of two roles, a Web role to host the UI and a Worker role to host the business logic and service components.

Table 3. Mapping Rapport Components to Windows Azure Roles

Rapport Component

Windows Azure Component

Rapport UI

Web role

Background processes

Worker role

Using Service Bus to Integrate On-Premises Components

BCWeb also relied on on-premises components to provide access to information hosted outside of the BCWeb application infrastructure. To adequately integrate these components with the Windows Azure infrastructure, Microsoft IT employed the Windows Azure AppFabric Service Bus, which enables developers to build distributed applications on the Windows Azure platform.

The Service Bus provides secure messaging and connectivity capabilities. This enables developers to use various communication and messaging protocols and patterns in their cloud-based applications, to communicate with on-premises resources without having to worry about delivery assurance, reliable messaging, and distribution scale.

The Service Bus also solves issues that relate to on-premises resources and distributed applications, by:

  • Connecting applications based on Windows Azure with on-premises applications and databases.
  • Exposing applications and services through firewalls, network address translation (NAT) gateways, and other problematic network boundaries.
  • Exposing communication endpoints easily, and supporting multiple connection options.

Using Service Bus for BCWeb

In the BCWeb architecture, Service Bus integrates with two key on-premises resources:

Architecting the Windows Azure Platform for Resiliency

A key aspect of the project's design goals was to provide an application that was scalable in performance and resilient in the case of single or multiple component failure. Fortunately for Microsoft IT, the Windows Azure platform natively supports architecture components that can fulfill both of these requirements.

For the critical aspects of the two applications, like the UI and the core WCF components, the team implemented multiple instances of the associated Windows Azure roles. This enables the respective roles to use multiple instances of a role that are running concurrently to maintain performance by providing more application resources, or to provide continued services should a component of the application within any instance fail. The team also planned to build a component hosted within Windows Azure that would monitor process health and ensure instances were recycled if the component encountered issues. This approach removed several single points of failure that existed in the previous version of BCWeb.

Key Implementation Tasks

During the migration, Microsoft IT encountered challenges that required alteration of the project's design approach or the migration implementation.

Refactoring Application Code

Several parts of BCWeb's application code needed to be refactored for Windows Azure. Most of the refactoring was specific to Windows Azure architecture, but a significant refactoring task was based on refactoring for Microsoft .NET Framework requirements.

The majority of the original BCWeb application was developed primarily by using the Microsoft .NET Framework 2.0. To take full advantage of the Windows Azure platform, the development team refactored that code and upgraded the application to the Microsoft .NET Framework 4.0.

Ensuring End-to-End Data Protection

BCWeb contains important business information that Microsoft IT wanted to protect. Therefore, to host the application fully on Windows Azure, Microsoft IT had to secure the endpoints for accessing the application. However, the distributed architecture of BCWeb provided a slightly different challenge. Microsoft IT had to protect the data moving in and out of the application—from the end user's web browser to database storage to integrated on-premises components.

The migration team implemented WCF message encryption in all possible places within the architecture, as well as Secure Sockets Layer (SSL) encryption from the web browser to the application components, and from the Windows Azure components to the SQL Azure databases.

Migrating Application Data

For the initial data-migration process, Microsoft IT had to move a large amount of data to the Windows Azure platform. The development team moved approximately 20 gigabytes (GB) of data to the Windows Azure platform in less than six hours by using a combination of SQL Server Integration Services (SSIS) packages and Bulk Copy Program (BCP), which is a utility for moving large amounts of database information in and out of SQL Server. One key aspect of migration procedure that Microsoft implemented was retry logic in its code. Connections to SQL Azure opened by long-running tasks are closed after one minute, which means that a process could not depend on an open connection when it began.

Ongoing Movement of Application Data

The Windows Azure platform hosts the primary Online Transaction Processing (OLTP) functionality of BCWeb databases. However, the data-warehouse databases are hosted on-premises so they can be accessed correctly by external applications and processes. As a result, Microsoft IT had to ensure that the transactional data was exported to the on-premises data-warehouse database regularly. To accomplish this, Microsoft IT implemented SSIS to extract, transform, and load the data based on SQL Azure to the on-premises databases.

Synchronizing SQL Azure Data

In the legacy version of BCWeb, BCWeb and WRAP worked together to provide data from SQL Server databases for search and reporting services. Additionally, the legacy database structure contained several elements that were used for reporting purposes and integration with outside data sources.

In SQL Azure, the previously used data-movement processes were refactored into SQL Azure Data Sync, which enables creating and scheduling regular synchronizations between SQL Azure and SQL Server or other SQL Azure databases. SQL Azure Data Sync can be used with Microsoft SQL Server 2005 SP2 or newer versions.

Ensuring Reliable Integration with On-Premises Components

Rather than build integration mechanisms into each individual on-premises component, the development team chose to implement an on-premises active/passive Windows Server® 2008 R2 failover server cluster. This cluster would act as a gateway between on-premises components and components on Windows Azure, and host those objects that were required to interact with on-premises components. Furthermore, the majority of communication between the on-premises components and BCWeb on Windows Azure would be routed through the Windows Azure AppFabric Service Bus to the gateway cluster. This approach consolidated communications and ensured the use of the fewest endpoints possible within the application architecture.

One of the most important components involved was Microsoft's business information contained in SAP. BCWeb needed a reliable way to maintain synchronization with SAP data and also to be made aware of changes within SAP that would affect BCWeb functionality. Therefore, the development team created a lightweight service on the gateway server that would provide notification to the components on Windows Azure if any changes were made to the SAP data.

Final Solution Architecture

Figure 2. Architecture for BCWeb on Windows Azure

Figure 2. Architecture for BCWeb on Windows Azure


There were several benefits that resulted from the successful migration of BCWeb to the Windows Azure platform, both from an application perspective and in best practices that Microsoft IT determined during the migration.

Application Benefits

  • Increased performance and stability. The development team leveraged built-in Windows Azure components to increase performance and reliability. Multiple role instances in Windows Azure enabled BCWeb to scale according to performance demands, while providing redundancy to protect against single points of failure within the application architecture.
  • Cost savings. BCWeb hosted on Windows Azure can now utilize the Windows Azure distributed cloud architecture. This means that no hardware must be purchased or maintained, as the BCWeb application is stored at a Windows Azure data center.
  • Code refactoring savings. Much of the original application code from the previous version of BCWeb was reused or slightly refactored for use in the Windows Azure version.
  • Reusable components. The development team created several different components to enable BCWeb to function properly on the Windows Azure platform. Many of these components can now be reused with minimal refactoring in other Windows Azure migrations.

Best Practices

Microsoft IT gained several best practices when migrating BCWeb to Windows Azure, and these can be used for future distributed application migrations to Windows Azure. The new best practices include:

  • Prepare for refactoring for on-premises integration. When migrating a distributed application to Windows Azure, developers should be prepared to refactor their code or create new code to enable communication between Windows Azure and on-premises components.
  • Plan for multiple communication and encryption methods. When migrating business data to Windows Azure, multiple communication and encryption methods may be required, depending on the on-premises components.
  • Remember to build retry logic into code for endpoints and SQL Azure access to ensure success of process-based tasks.
  • Use built-in Windows Azure component redundancy for performance and reliability. Windows Azure multi-instance roles enable developers to implement a more robust application platform.
  • Create components for monitoring, if centralized monitoring is required. When working with a distributed application, developers will need to develop monitoring components to accurately monitor and maintain system health in an automated and centralized manner.


Working with a distributed application brought many challenges to the migration process, but the flexibility of the Windows Azure development platform allowed Microsoft IT to migrate the application while maintaining design goals.

Migrating BCWeb to Windows Azure provided the application with the stability and flexibility that it lacked in its legacy architecture. Microsoft IT gained numerous best practices for distributed migration that will be used in future implementations.

Products & Technologies

  • Windows Azure Web role
  • Windows Azure Worker role
  • Windows Azure AppFabric
  • SQL Azure
  • SQL Azure Data Sync
  • Microsoft SQL Server 2008 R2
  • Microsoft Visual Studio® 2010
  • Windows Azure SDK 1.4

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 Order Centre at (800) 933-4750. Outside the 50 United States and Canada, please contact your local Microsoft subsidiary. To access information via the World Wide Web, go to:



© 2011 Microsoft Corporation. All rights reserved.

Microsoft, Windows, and Windows Server 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.

This document is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS SUMMARY.

Was this page helpful?
(1500 characters remaining)
Thank you for your feedback
© 2015 Microsoft