Walgreens Boots Alliance moves a mountain of SAP assets to Azure in a key modernization move

A sprawling datacenter footprint slows growth

Like many global corporations, WBA relies on the SAP platform to manage its inventory and supply chain efficiently and to provide vital business intelligence. WBA operates retail stores as Walgreens, Boots, and other brands in North America, South America, the United Kingdom, and Europe. It also runs a number of pharmaceutical manufacturing, wholesale, and distribution companies and has partnerships in Thailand, the Middle East, and China. The business was running on a global patchwork of huge, on-premises datacenters that featured a legacy of monolithic architectures and customizations.

As one of the largest retail pharmacies in the world, WBA runs vast amounts of store data through its business systems in countless small transactions—a classic online transaction processing (OLTP) workflow. The data is used for everything from streamlining the supply chain to workforce management. SAP technology ties the front, middle, and back office processes together.

But the big systems were aging and anything but flexible. “We were spending a fortune to expand and maintain our datacenter hardware, but it wasn’t enough. We needed to move to the cloud to support the digital transformation that we envisioned,” notes Dan Regalado, Vice President of Global Technology Transformation and Strategic Partnerships for Walgreens Boots Alliance Technology Team.

SAP S/4HANA is at the center of the Walgreens digital transformation. This enterprise application connects Walgreens to its customers with support for real-time transactions, such as entering sales orders in the system, managing inventory, and handling accounts receivable.

Because of its long-standing relationship with Microsoft, WBA looked to Azure for a solution that would scale up to the company’s worldwide retail chain. Recently Microsoft and SAP partnered to simplify digital transformation for their customers. The Embrace program includes industry roadmaps designed to streamline a company’s journey to SAP S/4HANA in the cloud, an effort that typically takes months of careful planning.

When the migration team was assembled, it included specialists from WBA, SAP, Microsoft, Accenture, Tata Consultancy Services (TCS), and other partners. “It was a massive team effort,” explains Regalado. “One day on site, I realized that I couldn’t tell who was from which company. Everyone worked together seamlessly.”

The task was complex, and the SAP migration team had a narrow window. “We were granted less than 20 hours of downtime to move almost 100 terabytes of data from our datacenter in the Chicago area to our new Azure datacenter. We needed meticulous planning,” Regalado notes.

Three keys to a massive scale-out: Memory, CPU, and disk size

Everyone on the migration team knew that the solution on Azure would require a lot of servers. As far as Microsoft and SAP knew, no other enterprise in any industry hosted such a large SAP implementation. In terms of terabytes of data, the project was the biggest migration ever of an SAP infrastructure from on-premises to Azure.

To estimate the size of the Azure infrastructure, three key performance indicators (KPIs) come into play: memory, CPU, and disk size. Memory is usually the main consideration in sizing an SAP HANA database infrastructure on Azure. SAP HANA is an in-memory database, meaning that it stores essentially all data—including both master and transactional data—in main memory. Given WBA’s 100-TB footprint, the largest available virtual machines weren’t big enough to handle the database but were more than capable of running the application tier and its shared services.

SAP HANA needs a lot of compute power to ensure nimble response times for the analytical applications and to support parallel processing, both of which require more capacity than traditional databases. As for disk size, SAP HANA needs room to write all that data to disk, including a full image of all the business data along with everything else it needs in case of a system shutdown.

To address these three KPIs, the migration team chose SAP HANA on Azure (Large Instances). This solution provides purpose-built servers in Azure datacenters that are designed specifically for SAP HANA. These bare-metal instances are dedicated to one customer’s SAP HANA workload and are certified to meet SAP HANA Tailored Data Center Integration (TDI) requirements.

“We used compute as the metric,” says Wade Graham, a Microsoft managing account director. “It was a crazy metric but the only one we had at the time for such a complex migration."

A high-availability, scale-out architecture

The topology on Azure includes multiple nodes in a scale-out configuration that is replicated in a secondary (standby) region to support disaster recovery. A typical transaction might start with a user on-premises who executes a sales order request through the SAP Fiori interface of SAP S/4HANA. The request flows across a high-speed Azure ExpressRoute gateway to the highly available SAP Central Services component. Then it goes through the SAP application servers running on virtual machines with a high memory-to-CPU ratio that offer a 99.95-percent uptime service-level agreement.

The application tier sends requests to SAP HANA, where in-memory data is persisted to high-performance Azure managed disks. The in-memory SAP HANA data is replicated to the disaster recovery region asynchronously using SAP HANA system replication and the high-speed Azure backbone network.

In this architecture, performance comes from the underlying bare-metal hardware. Azure offers a range of server sizes, but WBA needed big. SAP HANA runs on an Azure S576m CPU, a server optimized for mission-critical transactional workloads, including SAP S/4HANA in OLTP scenarios. Twelve CPUs are used for a total of 288 cores (24 cores per Intel Xeon E7-8890 v4 processor) with 12 TB of memory and 28 TB of storage.

This option is available in a design called Revision 4. Unveiled in July 2019, Revision 4 SAP HANA on Azure (Large Instances) are deployed in Azure datacenters in close physical proximity to the Azure virtual machines running the SAP application servers. This proximity boosts application performance.

“The applications are in constant communication with the SAP HANA database,” explains Erwin van Vroenhoven, Vice President of OneIT WBA Retail Programs. “Network latency can be an issue, but Revision 4 rolled out in time for us to get the best performance—even better than we had on-premises.”

This architecture uses both virtual and physical networks. The virtual network is part of Azure infrastructure as a service (IaaS) and connects to a discrete SAP HANA on Azure (Large Instances) physical network through ExpressRoute circuits. A cross-premises gateway connects the workloads in the Azure virtual network to WBA’s on-premises sites.

This architecture makes the most of the security controls provided at every level—from the Azure platform to the application and data layers running on the Linux operating system (both SUSE and Red Hat were used). To restrict network traffic, network security groups control incoming, outgoing, and intra-subnet traffic. For infrastructure security, data is encrypted in transit and at rest.

Always prepared

To support business continuity and disaster recovery, the architecture features a primary (active) site in one Azure region and a secondary site in another Azure region. The company runs four SAP HANA instances in each region—two primary and two standby units for each production system. This configuration guarantees “four nines” system availability—99.99 percent. Asynchronous data replication from primary to secondary supports the company’s zero Recovery Point Objective (RPO).

In the application tier, Azure Site Recovery supports replication, failover, and recovery. In the event of a disaster, Site Recovery brings the application servers and SAP Central Services back online based on the metadata and snapshots it stores in its vault.

Next steps

When the SAP system on Azure went live, it was an immediate success. “We shut the system down on a Saturday night, moved the data, and then we opened it up for business Sunday morning,” says Regalado. “We had been hitting capacity in our servers on-premises, but when we moved to Azure, both memory and CPU were at the minimum, which gives us the needed room continue our rollout. We were very happy with the outcome.”

The company is cutting huge costs by decommissioning the servers on-premises that it no longer needs. Azure is more cost-effective, because the company pays only for the capacity it uses.

“The end goal eventually is to get out of managing our own datacenters and move the majority of our compute to Azure,” says van Vroenhoven.“ Until then, the team continues to work closely with Microsoft to optimize the deployment and use Azure resources efficiently.

Although the rollout had to be postponed because of WBA’s role in fighting COVID-19, the new platform currently supports more than 1,600 stores and 7,000 users, with plans to scale out to as many as 9,000 more stores. The improvements in performance and scale are already translating to better business insights for the company and smoother inventory tracking for stores, which means customers get the products and services they want.

As Regalado says, “It’s all about happy customers.”