The following ASUG case study was authored in collaboration with Microsoft. It can be downloaded in full here.
The Background
Microsoft, like many other enterprises, runs on SAP. Leveraging its applications for finance, human resources, supply chain, and other areas of its $270 billion global business, Microsoft is heavily invested in its SAP landscape, reflecting the depth and breadth of a longstanding partnership built on co-innovation.
“SAP is the core ecosystem ERP of Microsoft,” said Frederic Huet, a Partner Group Engineering Manager and SAP Enterprise Architect at Microsoft, pointing to the software’s role in everything from payroll and procurement to large-scale commerce and complex federal government work.
Microsoft doesn’t manage SAP through a traditional IT department. Instead, its Commerce and Ecosystem team oversees the landscape, emphasizing operational integration over siloed infrastructure. Huet has worked with SAP systems for over 30 years, the last eight of which he has focused on guiding Microsoft’s SAP program. He oversees the team that owns the platform’s architecture and roadmap, aligned with Microsoft’s enterprise strategy.
Microsoft began its digital transformation early, completing the full migration of its SAP infrastructure to the Azure cloud in February 2018 — a timeline that now contrasts with peers still planning or initiating their own cloud moves.
The core ECC instance, which has been live since late 1995, continues to support core finance, payroll for U.S. employees, professional services, and supply chain processes for product lines like Xbox and Surface. That ECC system runs on MS-SQL, spanning 110 terabytes uncompressed. It remains operational but is now slated for retirement.
The SAP landscape at Microsoft includes three primary pillars: ECC (the largest and most mature system), BRIM (a high-volume commerce engine), and the federal SAP environment (already operating on S/4HANA within Azure Government). Although each system differs in scale and function, they anchor Microsoft’s ERP backbone together.
Microsoft’s SAP footprint spans multiple deployment models: legacy systems on SQL, workloads already migrated to HANA, and SaaS solutions such as Ariba and SuccessFactors. All systems are hosted on Azure, with commercial workloads in Azure Commercial and sensitive government environments in Azure Government. Microsoft Dynamics is also omnipresent, as well as some legacy Oracle systems from various acquisitions.
While abstraction layers and user interfaces may obscure just how deeply embedded SAP and Microsoft are, the duo is inarguably and extensively connected. “Every Microsoft user is actually an SAP user,” noted Huet. “There is deep partnership and co-innovation between Microsoft and SAP, all the way back to the 90s.”
The Situation
Microsoft’s SAP transformation had to account for the size of its landscape, the complexity of its systems, and the need to keep operations running without disruption. Two representative projects, both of which went live in August of 2025, illustrate the breadth of this effort: the migration of Microsoft’s BRIM system from ECC to S/4HANA and the relocation of its federal SAP instance already on S/4HANA—into a RISE-managed environment on Azure Government.
Each system presented its own type of challenge. BRIM underpins Microsoft’s high-volume subscription commerce operations, processing 92 terabytes of transactional and financial data. It supports usage-based billing, collections, and dispute resolution for business models built on granular, per-user monetization. “If you think of consumer flows such as Xbox GamePass or individual Office subscription, you have a low dollar amount per transaction with an incredibly high volume: we built a custom commerce frontend in Azure to manage it, but all the detailed financials of it flow to SAP in real time,” he noted.
This architecture stands in contrast to Microsoft’s legacy ECC system, which was designed to support high-value, low-frequency transactions such as enterprise licensing. Together, the two platforms reflect a broader business model shift from perpetual licensing to recurring subscriptions and require fundamentally different architectural models within SAP.
The BRIM migration faced a strict downtime constraint. Because it supports live customer-facing financial transactions, the system had to be taken offline for no more than a single weekend. All data needed to be migrated, transformed, and validated between the close of business Friday and Monday morning in New Zealand time.
The effort was guided by what Huet called a “deeply engineered and orchestrated move to provide almost zero business downtime, and zero risk” to mission-critical operations.
By contrast, the federal SAP environment presented a different category of challenge: regulatory compliance and integration complexity. The goal was to “lift and shift” the system into RISE while preserving seamless connectivity with Microsoft’s broader ecosystem, including Dynamics CRM, NS2-hosted SaaS platforms such as Concur, and federal reporting systems.
This instance also includes Dassian’s SAP add-on, which is used for compliance with U.S. government contracts. Although the SAP architecture remained largely unchanged, the move to RISE presented an opportunity to optimize integrations, security, and operations, deepening the coinnovation partnership between Microsoft and SAP in the process.
The goal of achieving a clean core deployment added additional complexities to both projects. Microsoft’s legacy systems contained significant volumes of custom ABAP code and Z-field enhancements that conflicted with S/4HANA standards. The move to RISE required the remediation or removal of any custom enhancement not natively supported within SAP’s subscription delivery model. On the BRIM side, Microsoft CoPilot assisted in porting over a million lines of ABAP code to the new
standards.
Huet emphasized that the most unpredictable risks surfaced not in the SAP environment itself but at the edges: “It’s not what’s moving that’s the problem; it’s what’s staying.” He explained that in most transformations, the technical upgrade is manageable, but the integrations, dependencies, and regulatory boundaries require the most attention.
The Initiative
For the BRIM migration, early estimates showed that a traditional migration approach would require at least a full week of downtime. Even the initial Bluefield model yielded a three-day cutover window, which still exceeded tolerable limits. “Our entire actual data migration, correction, realignment, and everything has to happen in a short window of 20 hours,” noted Huet.
These constraints prompted Microsoft to find new ways to cut downtime without compromising data integrity or business continuity. Microsoft chose a Bluefield migration approach that enabled selective data transformation with minimal disruption. The company partnered with SNP—described by Huet as “the 800-pound gorilla of Bluefield”—to co-develop tools that could meet an aggressively compressed timeline.
Microsoft also deployed its internally developed AI copilots to support code remediation. These copilots operated directly within ABAP environments, offering suggested refactoring options that developers manually reviewed and validated. “We don’t do autopilot, we do copilot,” said Huet. The approach supported reusability and documentation: “Everything we build, when we do those things, we actually publish,” he added. “Every bit of solution that we build for that work, we share on GitHub.”
The second initiative focused on Microsoft’s U.S. federal SAP instance, which was already running on S/4HANA in Azure Government and being migrated into a RISE-managed environment. This transition, executed entirely in-house, brought with it a different category of complexity: integration management, regulatory compliance, and hyperscaler governance.
The shift to RISE enabled Microsoft to strategically redesign and strengthen hundreds of external connections — including NS2-hosted SaaS platforms like Concur, federal compliance modules like Dassian, and custom CRM applications running on Dynamics. Microsoft partnered closely with SAP to engineer a solution that would benefit all other Azure customers, and beyond, from the original VNet Peering with PrivateLink to the support of Microsoft Sentinel within RISE and BTP, just to name a few.
These capabilities now extend beyond Microsoft’s environment, enabling integration across RISE, Azure, and BTP landscapes.
Throughout the initiative, Microsoft remained committed to avoiding custom exceptions. “If it’s something that is unique to me, then that’s a problem,” explained Huet. Every enhancement was designed to be standardized, supportable, and extensible across SAP’s broader customer ecosystem. “We always want to deliver a reference model, a showcase and how-to roadmap for any of our joint customers to embrace and follow.”
The Results
Microsoft’s dual-track SAP transformation has delivered measurable technical and operational gains — particularly in reducing migration windows, accelerating Clean Core remediation, and establishing repeatable models for enterprise-scale modernization.
Originally expected to take a full week, the BRIM migration was done in the reduced time of only 20 hours of downtime for a 92-terabyte system. That timeline was possible thanks to a set of tightly coordinated technical steps.
For instance, Azure’s flexibility allowed the team to spin up temporary application servers to run migration processes in parallel. SQL extract optimizations and schema-aware caching reduced database load times. Seamless endpoint switching maintained continuity for users, allowing SAP transactions to proceed uninterrupted throughout the migration window.
The federal RISE migration, which involved shifting to S/4HANA within Azure Government in August of 2025, demonstrated what can be possible even in the most significantly regulated environments. Microsoft’s teams achieved a secure, compliant shift to S/4HANA while keeping operations intact and aligning hundreds of integrations and cloud security requirements.
The initiative has also created lasting value: Microsoft’s automation and copilot frameworks are now reused across multiple SAP systems, accelerating modernization and allowing developers to upskill. Co-innovation with SAP continues to inform future tools and best practices for clean-core transformation at scale.
With the BRIM system now live on S/4HANA and being readied for its RISE transition, Microsoft has established a model for modernizing large, business-critical SAP landscapes while maintaining performance, compliance, and business continuity. Additional ECC systems are queued for phased modernization over the coming years.
Lessons Learned
Across both the BRIM migration and the federal RISE transition, a consistent theme emerged: the complexity of ERP modernization lies less in the systems being transformed than in the ecosystems they operate within.
In the RISE project especially, the core lesson was that the real risk lies not in what moves but in what stays. “It’s not what’s moving that’s the problem, it’s what’s staying,” said Huet. He likened the transformation to heart surgery: “You’re relocating your heart just outside of your body,” he noted, highlighting the often-underestimated effort required to modernize deeply interconnected systems without service disruption.
Rather than implement custom exceptions, the team focused on building solutions that others could use, not tailoring the platform to Microsoft alone. Every enhancement was designed for reuse, extensibility, and alignment with SAP’s broader delivery model.
Huet noted that the copilots weren’t just remediation tools; they also helped developers learn on the job by experimenting and troubleshooting within live environments. In-context training, he emphasized, produced far more effective results than abstract coursework.
Finally, Huet summarized the company’s long-term transformation mindset in five words: “The job is never done.” Each migration informed the next, with measurable improvements in speed, resilience, and cost efficiency building over time.