The fol­low­ing ASUG case study was authored in col­lab­o­ra­tion with Microsoft. It can be down­loaded in full here.

The Back­ground

Microsoft, like many oth­er enter­pris­es, runs on SAP. Lever­ag­ing its appli­ca­tions for finance, human resources, sup­ply chain, and oth­er areas of its $270 bil­lion glob­al busi­ness, Microsoft is heav­i­ly invest­ed in its SAP land­scape, reflect­ing the depth and breadth of a long­stand­ing part­ner­ship built on co-innovation.

“SAP is the core ecosys­tem ERP of Microsoft,” said Fred­er­ic Huet, a Part­ner Group Engi­neer­ing Man­ag­er and SAP Enter­prise Archi­tect at Microsoft, point­ing to the software’s role in every­thing from pay­roll and pro­cure­ment to large-scale com­merce and com­plex fed­er­al gov­ern­ment work.

Microsoft doesn’t man­age SAP through a tra­di­tion­al IT depart­ment. Instead, its Com­merce and Ecosys­tem team over­sees the land­scape, empha­siz­ing oper­a­tional inte­gra­tion over siloed infra­struc­ture. Huet has worked with SAP sys­tems for over 30 years, the last eight of which he has focused on guid­ing Microsoft’s SAP pro­gram. He over­sees the team that owns the platform’s archi­tec­ture and roadmap, aligned with Microsoft’s enter­prise strategy.

Microsoft began its dig­i­tal trans­for­ma­tion ear­ly, com­plet­ing the full migra­tion of its SAP infra­struc­ture to the Azure cloud in Feb­ru­ary 2018 — a time­line that now con­trasts with peers still plan­ning or ini­ti­at­ing their own cloud moves.

The core ECC instance, which has been live since late 1995, con­tin­ues to sup­port core finance, pay­roll for U.S. employ­ees, pro­fes­sion­al ser­vices, and sup­ply chain process­es for prod­uct lines like Xbox and Sur­face. That ECC sys­tem runs on MS-SQL, span­ning 110 ter­abytes uncom­pressed. It remains oper­a­tional but is now slat­ed for retirement. 

The SAP land­scape at Microsoft includes three pri­ma­ry pil­lars: ECC (the largest and most mature sys­tem), BRIM (a high-vol­ume com­merce engine), and the fed­er­al SAP envi­ron­ment (already oper­at­ing on S/4HANA with­in Azure Gov­ern­ment). Although each sys­tem dif­fers in scale and func­tion, they anchor Microsoft’s ERP back­bone together.

Microsoft’s SAP foot­print spans mul­ti­ple deploy­ment mod­els: lega­cy sys­tems on SQL, work­loads already migrat­ed to HANA, and SaaS solu­tions such as Ari­ba and Suc­cess­Fac­tors. All sys­tems are host­ed on Azure, with com­mer­cial work­loads in Azure Com­mer­cial and sen­si­tive gov­ern­ment envi­ron­ments in Azure Gov­ern­ment. Microsoft Dynam­ics is also omnipresent, as well as some lega­cy Ora­cle sys­tems from var­i­ous acqui­si­tions.
 

While abstrac­tion lay­ers and user inter­faces may obscure just how deeply embed­ded SAP and Microsoft are, the duo is inar­guably and exten­sive­ly con­nect­ed. ​“Every Microsoft user is actu­al­ly an SAP user,” not­ed Huet. ​“There is deep part­ner­ship and co-inno­va­tion between Microsoft and SAP, all the way back to the 90s.”

The Sit­u­a­tion

Microsoft’s SAP trans­for­ma­tion had to account for the size of its land­scape, the com­plex­i­ty of its sys­tems, and the need to keep oper­a­tions run­ning with­out dis­rup­tion. Two rep­re­sen­ta­tive projects, both of which went live in August of 2025, illus­trate the breadth of this effort: the migra­tion of Microsoft’s BRIM sys­tem from ECC to S/4HANA and the relo­ca­tion of its fed­er­al SAP instance already on S/4HANA — into a RISE-man­aged envi­ron­ment on Azure Government.

Each sys­tem pre­sent­ed its own type of chal­lenge. BRIM under­pins Microsoft’s high-vol­ume sub­scrip­tion com­merce oper­a­tions, pro­cess­ing 92 ter­abytes of trans­ac­tion­al and finan­cial data. It sup­ports usage-based billing, col­lec­tions, and dis­pute res­o­lu­tion for busi­ness mod­els built on gran­u­lar, per-user mon­e­ti­za­tion. ​“If you think of con­sumer flows such as Xbox GamePass or indi­vid­ual Office sub­scrip­tion, you have a low dol­lar amount per trans­ac­tion with an incred­i­bly high vol­ume: we built a cus­tom com­merce fron­tend in Azure to man­age it, but all the detailed finan­cials of it flow to SAP in real time,” he noted.

This archi­tec­ture stands in con­trast to Microsoft’s lega­cy ECC sys­tem, which was designed to sup­port high-val­ue, low-fre­quen­cy trans­ac­tions such as enter­prise licens­ing. Togeth­er, the two plat­forms reflect a broad­er busi­ness mod­el shift from per­pet­u­al licens­ing to recur­ring sub­scrip­tions and require fun­da­men­tal­ly dif­fer­ent archi­tec­tur­al mod­els with­in SAP.

The BRIM migra­tion faced a strict down­time con­straint. Because it sup­ports live cus­tomer-fac­ing finan­cial trans­ac­tions, the sys­tem had to be tak­en offline for no more than a sin­gle week­end. All data need­ed to be migrat­ed, trans­formed, and val­i­dat­ed between the close of busi­ness Fri­day and Mon­day morn­ing in New Zealand time.

The effort was guid­ed by what Huet called a ​“deeply engi­neered and orches­trat­ed move to pro­vide almost zero busi­ness down­time, and zero risk” to mis­sion-crit­i­cal operations.

By con­trast, the fed­er­al SAP envi­ron­ment pre­sent­ed a dif­fer­ent cat­e­go­ry of chal­lenge: reg­u­la­to­ry com­pli­ance and inte­gra­tion com­plex­i­ty. The goal was to ​“lift and shift” the sys­tem into RISE while pre­serv­ing seam­less con­nec­tiv­i­ty with Microsoft’s broad­er ecosys­tem, includ­ing Dynam­ics CRM, NS2-host­ed SaaS plat­forms such as Con­cur, and fed­er­al report­ing systems.

This instance also includes Dassian’s SAP add-on, which is used for com­pli­ance with U.S. gov­ern­ment con­tracts. Although the SAP archi­tec­ture remained large­ly unchanged, the move to RISE pre­sent­ed an oppor­tu­ni­ty to opti­mize inte­gra­tions, secu­ri­ty, and oper­a­tions, deep­en­ing the coin­no­va­tion part­ner­ship between Microsoft and SAP in the process.

The goal of achiev­ing a clean core deploy­ment added addi­tion­al com­plex­i­ties to both projects. Microsoft’s lega­cy sys­tems con­tained sig­nif­i­cant vol­umes of cus­tom ABAP code and Z‑field enhance­ments that con­flict­ed with S/4HANA stan­dards. The move to RISE required the reme­di­a­tion or removal of any cus­tom enhance­ment not native­ly sup­port­ed with­in SAP’s sub­scrip­tion deliv­ery mod­el. On the BRIM side, Microsoft CoPi­lot assist­ed in port­ing over a mil­lion lines of ABAP code to the new standards.

Huet empha­sized that the most unpre­dictable risks sur­faced not in the SAP envi­ron­ment itself but at the edges: ​“It’s not what’s mov­ing that’s the prob­lem; it’s what’s stay­ing.” He explained that in most trans­for­ma­tions, the tech­ni­cal upgrade is man­age­able, but the inte­gra­tions, depen­den­cies, and reg­u­la­to­ry bound­aries require the most attention.

The Ini­tia­tive

For the BRIM migra­tion, ear­ly esti­mates showed that a tra­di­tion­al migra­tion approach would require at least a full week of down­time. Even the ini­tial Blue­field mod­el yield­ed a three-day cutover win­dow, which still exceed­ed tol­er­a­ble lim­its. ​“Our entire actu­al data migra­tion, cor­rec­tion, realign­ment, and every­thing has to hap­pen in a short win­dow of 20 hours,” not­ed Huet.

These con­straints prompt­ed Microsoft to find new ways to cut down­time with­out com­pro­mis­ing data integri­ty or busi­ness con­ti­nu­ity. Microsoft chose a Blue­field migra­tion approach that enabled selec­tive data trans­for­ma­tion with min­i­mal dis­rup­tion. The com­pa­ny part­nered with SNP — described by Huet as ​“the 800-pound goril­la of Blue­field” — to co-devel­op tools that could meet an aggres­sive­ly com­pressed timeline.

Microsoft also deployed its inter­nal­ly devel­oped AI copi­lots to sup­port code reme­di­a­tion. These copi­lots oper­at­ed direct­ly with­in ABAP envi­ron­ments, offer­ing sug­gest­ed refac­tor­ing options that devel­op­ers man­u­al­ly reviewed and val­i­dat­ed. ​“We don’t do autopi­lot, we do copi­lot,” said Huet. The approach sup­port­ed reusabil­i­ty and doc­u­men­ta­tion: ​“Every­thing we build, when we do those things, we actu­al­ly pub­lish,” he added. ​“Every bit of solu­tion that we build for that work, we share on GitHub.”

The sec­ond ini­tia­tive focused on Microsoft’s U.S. fed­er­al SAP instance, which was already run­ning on S/4HANA in Azure Gov­ern­ment and being migrat­ed into a RISE-man­aged envi­ron­ment. This tran­si­tion, exe­cut­ed entire­ly in-house, brought with it a dif­fer­ent cat­e­go­ry of com­plex­i­ty: inte­gra­tion man­age­ment, reg­u­la­to­ry com­pli­ance, and hyper­scaler governance.

The shift to RISE enabled Microsoft to strate­gi­cal­ly redesign and strength­en hun­dreds of exter­nal con­nec­tions — includ­ing NS2-host­ed SaaS plat­forms like Con­cur, fed­er­al com­pli­ance mod­ules like Dass­ian, and cus­tom CRM appli­ca­tions run­ning on Dynam­ics. Microsoft part­nered close­ly with SAP to engi­neer a solu­tion that would ben­e­fit all oth­er Azure cus­tomers, and beyond, from the orig­i­nal VNet Peer­ing with Pri­vateLink to the sup­port of Microsoft Sen­tinel with­in RISE and BTP, just to name a few.

These capa­bil­i­ties now extend beyond Microsoft’s envi­ron­ment, enabling inte­gra­tion across RISE, Azure, and BTP landscapes.

Through­out the ini­tia­tive, Microsoft remained com­mit­ted to avoid­ing cus­tom excep­tions. ​“If it’s some­thing that is unique to me, then that’s a prob­lem,” explained Huet. Every enhance­ment was designed to be stan­dard­ized, sup­port­able, and exten­si­ble across SAP’s broad­er cus­tomer ecosys­tem. ​“We always want to deliv­er a ref­er­ence mod­el, a show­case and how-to roadmap for any of our joint cus­tomers to embrace and follow.”

The Results

Microsoft’s dual-track SAP trans­for­ma­tion has deliv­ered mea­sur­able tech­ni­cal and oper­a­tional gains — par­tic­u­lar­ly in reduc­ing migra­tion win­dows, accel­er­at­ing Clean Core reme­di­a­tion, and estab­lish­ing repeat­able mod­els for enter­prise-scale modernization.

Orig­i­nal­ly expect­ed to take a full week, the BRIM migra­tion was done in the reduced time of only 20 hours of down­time for a 92-ter­abyte sys­tem. That time­line was pos­si­ble thanks to a set of tight­ly coor­di­nat­ed tech­ni­cal steps.

For instance, Azure’s flex­i­bil­i­ty allowed the team to spin up tem­po­rary appli­ca­tion servers to run migra­tion process­es in par­al­lel. SQL extract opti­miza­tions and schema-aware caching reduced data­base load times. Seam­less end­point switch­ing main­tained con­ti­nu­ity for users, allow­ing SAP trans­ac­tions to pro­ceed unin­ter­rupt­ed through­out the migra­tion window.

The fed­er­al RISE migra­tion, which involved shift­ing to S/4HANA with­in Azure Gov­ern­ment in August of 2025, demon­strat­ed what can be pos­si­ble even in the most sig­nif­i­cant­ly reg­u­lat­ed envi­ron­ments. Microsoft’s teams achieved a secure, com­pli­ant shift to S/4HANA while keep­ing oper­a­tions intact and align­ing hun­dreds of inte­gra­tions and cloud secu­ri­ty requirements.

The ini­tia­tive has also cre­at­ed last­ing val­ue: Microsoft’s automa­tion and copi­lot frame­works are now reused across mul­ti­ple SAP sys­tems, accel­er­at­ing mod­ern­iza­tion and allow­ing devel­op­ers to upskill. Co-inno­va­tion with SAP con­tin­ues to inform future tools and best prac­tices for clean-core trans­for­ma­tion at scale.

With the BRIM sys­tem now live on S/4HANA and being read­ied for its RISE tran­si­tion, Microsoft has estab­lished a mod­el for mod­ern­iz­ing large, busi­ness-crit­i­cal SAP land­scapes while main­tain­ing per­for­mance, com­pli­ance, and busi­ness con­ti­nu­ity. Addi­tion­al ECC sys­tems are queued for phased mod­ern­iza­tion over the com­ing years.

Lessons Learned

Across both the BRIM migra­tion and the fed­er­al RISE tran­si­tion, a con­sis­tent theme emerged: the com­plex­i­ty of ERP mod­ern­iza­tion lies less in the sys­tems being trans­formed than in the ecosys­tems they oper­ate within.

In the RISE project espe­cial­ly, the core les­son was that the real risk lies not in what moves but in what stays. ​“It’s not what’s mov­ing that’s the prob­lem, it’s what’s stay­ing,” said Huet. He likened the trans­for­ma­tion to heart surgery: ​“You’re relo­cat­ing your heart just out­side of your body,” he not­ed, high­light­ing the often-under­es­ti­mat­ed effort required to mod­ern­ize deeply inter­con­nect­ed sys­tems with­out ser­vice disruption.

Rather than imple­ment cus­tom excep­tions, the team focused on build­ing solu­tions that oth­ers could use, not tai­lor­ing the plat­form to Microsoft alone. Every enhance­ment was designed for reuse, exten­si­bil­i­ty, and align­ment with SAP’s broad­er deliv­ery model.

Huet not­ed that the copi­lots weren’t just reme­di­a­tion tools; they also helped devel­op­ers learn on the job by exper­i­ment­ing and trou­bleshoot­ing with­in live envi­ron­ments. In-con­text train­ing, he empha­sized, pro­duced far more effec­tive results than abstract coursework.

Final­ly, Huet sum­ma­rized the company’s long-term trans­for­ma­tion mind­set in five words: ​“The job is nev­er done.” Each migra­tion informed the next, with mea­sur­able improve­ments in speed, resilience, and cost effi­cien­cy build­ing over time.