IT transformation is more than a one-time migration of applications to the cloud; it’s an ongoing process of adapting your application’s architecture to best take advantage of new and rapidly evolving services and features being released by providers like Microsoft® Azure® .

IT transformation journey of a fictitious company, Mercurial Footwear, as it first adopts Microsoft Azure Infrastructure-as-a-Service and then gradually evolves its architecture to better take advantage of the Platform-as-a-Service (PaaS) features most relevant to its business needs. The various stages of this transformation — from a simple lift-and-shift to the cloud to leveraging cutting-edge technologies like containers and serverless computing — are typical of the transformation process that we help our customers navigate at Rackspace.

In this scenario, Mercurial Footwear runs a four-tiered warehouse management application in its own U.S.-based data center, comprising web, Active Directory® (AD), logic and storage tiers. Part of this environment is a Windows® application; part is a Linux® application.


Mercurial Footwear has two organizations within its business that need to utilize this application to manage inventory, ordering and shipping: the inside sales group, and the inventory and manufacturing group.

The first step in Mercurial Footwear’s IT transformation journey is simply to get its warehouse management application out of its data center and into the cloud.


Once inside the Azure public cloud, we’ve created four discrete networks: one for identity, one for the web tier, one for the API tier and one for the data tier. In each of these areas, we’ve spun up some VMs of the appropriate size, either Windows or Linux VMs, based on our previous on-premises implementation. One thing to note is that we can wrap these VMs in a “scale set” to increase or decrease the number of VMs based on the load the application is currently experiencing. This creates immediate value to the application beyond what’s available running the application on-premises.

In Phase 2,we’re starting to transform Mercurial’s application into something that looks a little more “cloudy.” We now swap out some of its VMs in each tier for various Platform-as-a-Service (PaaS) offerings, where possible.


It starts with the identity tier. We’ve replaced the VMs running Azure Active Directory service. Now we’re allowing the Azure Active Directory service to handle identity and access management as opposed to managing VMs.

This provides significant value for a few reasons. First, Mercurial no longer has to worry as much about scale; it’s now partly Microsoft’s responsibility to help ensure the application is available, responsive, backed up, patched, and secure. Secondly, it takes a lot of work off Mercurial’s plate — two fewer VMs that need to be patched, managed and monitored. This change also is a significant shift in how it is being charged by Microsoft: from a flat VM charge to one that is more “transactional.”

In the web tier, instead of using VMs, we’re now using the Azure Web Apps service. This allows Mercurial to deploy web code into a service instead of a server and lean on Microsoft to handle scaling. Like before, this removes all the old work of maintaining, monitoring and patching servers.

The API layer is using the same Web Apps technology. We’ve also made another change from a service perspective at the data tier, which provides similar benefits. Rather than using VMs running SQL server, we’re now relying on the Azure SQL Database-as-a-Service (DBaaS).

However, you may notice that we did leave one remaining VM running SQL in the data tier. This is because not all Mercurial Footwear’s data can be moved fast and easily. As in the previous phase, we use SQL Server replication as required for data synchronization.

In Phase 3, we’ve added Azure Functions into the API layer — an incredibly powerful tool that enables Mercurial Footwear to begin leveraging a serverless architecture.

Azure Functions takes the code that had been embedded in the Azure website and makes it into a completely reusable code snippet that can be used anywhere in the application stack. Azure Functions is highly performant and cost-effective, and you can use almost any language to code to it, including .NET, Node.js, C Sharp, and F Sharp, among many others. Mercurial could also potentially use Azure Functions for the Linux logic layer, depending on the language it uses or its willingness to convert.

We’ve also replaced its remaining VMs in the web tier and data tier with additional Azure Web Apps and Azure SQL, respectively. In some cases, Linux data VMs may still be required depending on the databases in use.

By now, the modernization process has truly transformed Mercurial Footwear’s IT capabilities and added significant business value to the company. No longer is the IT staff focused on managing, updating and monitoring VMs; since Azure is now responsible for many of their old duties, they are now focused instead on building new functionality and capabilities. These new capabilities have given Mercurial a strategic advantage over its competitors and aided it in growing into a truly a global business.

In Phase 4, the proliferation of Azure Functions means we need to use containers for better manageability. These containers center on specific aspects of the application as well as technology — we’re now able to manage inventory, orders and shipping.

We’ve created Docker containers for those running .NET, Node.js or PHP, and we’ve implemented more Azure Functions in that layer as well. Containers give us “boundaries” as well as portability. We’ve also expanded the data layer to include both Redis and CosmoDB in addition to Azure SQL.

Finally, we’ve expanded Mercurial’s setup on the identity server side because it now has many different applications which it has moved to Azure and which may or may not use Active Directory as their authentication store. With so many different endpoints coming in, this change adds more capabilities for us to have a true identity service for our application and for our customer.

In order to ensure the right data goes to the right application stack, we would utilize Global Network Services. These network services interrogate the source of the request to see where the customers are coming from and ensure their data stays where it’s supposed to. It effectively acts as a traffic cop, allowing data into the Azure public cloud or into a single-tenant Azure Stack based on the laws or regulations the company is trying to meet.

Microsoft Azure is the only cloud that has the capability of running an Azure-based application in both a public hyper-scale cloud and a single-tenant version.

This is just one example of what the IT transformation process might look like for a company leveraging Microsoft Azure. Even when you start simple, always keep your desired end state in mind, and remember that the process of modernization is iterative.

It should be reiterated that “the cloud” is not a destination, but an ongoing process of constantly evolving your application to take advantage of advances in the native capabilities of your chosen cloud.

To read full download the whitepaper:
Step-By-Step Cloud Evolution with Microsoft Azure