How Microsoft moved an SAP ECC billing system to S/4HANA private cloud

Vessels of the SAP mothership

Microsoft began using BRIM around 15 years ago, and the software grew steadily more important as more lines of business were onboarded. But lately it wasn't keeping up with the company's growth, according to van Honschooten.

"We realized we had some blockers remaining in ECC in our ability to process the amount of data and support the business scenarios we needed," she said. "Being able to keep up the scaling was really the thing that put us over the edge."

Another major benefit of migrating to S/4HANA would be the read performance of its HANA in-memory database, which is significantly faster than the ECC's SQL database. Month-end accounting processes that took eight hours on ECC had a cumulative effect on the high-volume, batch-oriented system but could be reduced to half an hour on S/4HANA.

"Some of our biggest jobs were getting progressively longer. And, because of the volumes we were putting through the system, we were having issues with meeting schedule times," she said.

Being able to pursue modern integration strategies and use AI to optimize processes were other strong reasons to migrate. Plus, new features are only available in the S/4HANA version of BRIM, according to van Honschooten. SAP's promise to end mainstream ECC support at the end of 2027 was another factor.

She said BRIM is the first "really big" system Microsoft has moved to S/4HANA. The company has been a major SAP customer since the 1990s and is undergoing a gradual, multi-phase migration from ECC.

Before BRIM, it had moved a much smaller system for master data governance and implemented one for its U.S. federal government business directly on S/4HANA, she said.

The company still has one large ECC system it has used for nearly 30 years for finance-centric processes, such as core financials, procure-to-pay and order-to-cash, as well as HR. 

"The mothership SAP system is still on ECC, and we have a multi-year project in the works to move that to S/4 as well, but it's a much harder job," van Honschooten said.

All the SAP systems run on Azure, Microsoft's public cloud.

Selective migration is no small task

After a couple false starts, Microsoft began discussing moving BRIM to S/4HANA around 2021 but put the project aside to work on a major credit-and-collections project. Serious planning with a small team began in 2024, and the full project team hit the ground running in February 2025.

Microsoft's team of around 50 SAP specialists was responsible for migrating the BRIM code, including refactoring and testing to ensure it ran correctly on S/4HANA. SNP Group, an IT consultancy, handled data migration, and a team from SAP's premium advisory service, MaxAttention, served as trusted advisors. Business leaders and partner engineering teams performed regression testing to ensure the new system functioned properly, according to van Honschooten.

Much of the work would be dedicated to moving BRIM's massive database. "The biggest tables in the system are over 12 billion rows," van Honschooten said. "We're adding millions of rows every day, and we're archiving millions of rows every day."

An initial assessment predicted downtime would last five days, which the business could not tolerate. "We were not going to be able to do the project unless we could fit it into a weekend," she said.

We were not going to be able to do the project unless we could fit it into a weekend.

So Microsoft and SNP brainstormed how to shrink the downtime window closer to the size of a typical window. They determined that taking the system down Friday afternoon U.S. Pacific time and getting back online by midday on Sunday would work because that's Monday morning in Manila, where Microsoft has a large offshore operation. The window was now down to 24 hours.

To get the data migration job itself to a manageable size, Microsoft chose SNP's Bluefield selective migration, which involves only moving certain data and processes to S/HANA. In contrast, the brownfield method moves everything with minimal changes, which means fewer decisions to make. But it has two major drawbacks: Outdated processes and redundant data typically move to the new system, and some of its advanced features aren't activated. SNP says Bluefield enables companies to leave behind inefficiencies and get the reliability and stability of a brownfield migration while modernizing on the new platform.

"Generally speaking, selective migration means you don't have to bring the whole system over," said SNP CTO Steele Arbeeny. "Maybe you have 10 years of history and you only want five, or you only have certain product lines that you want to migrate the data for." The result is an optimized system with a smaller footprint and lower costs, he said.

Steele Arbeeny

SNP's method and tools enabled a phased approach of pre-loading significant amounts of the most static data to the target system and then only moving the deltas -- data that changed while the migration was taking place -- on the go-live weekend, van Honschooten said.

She said the team didn't have to create complex data-conversion rules and instead relied on SNP and Microsoft data validation tools to make sure the deltas were 100% "on point" and the changes were captured accurately. It also used an SNP tool called Kyano Validate to validate trillions of fields after go-live.

"We split the migration into an uptime portion, where the system's still running, but we're migrating all inactive data from previous years -- data that's not going to change," Arbeeny explained. "We bring that all over while the system is running, and then we take our downtime event and just do that catch-up period where we bring over anything that's changed during the uptime portion of the migration."

Around half the downtime window was taken up by SNP's data migration, while Microsoft used the other half to verify the system was correct by starting and stopping processes, for example.

Arbeeny said the size of the system, volume of transactions and narrow downtime window required by the global nature of BRIM's operations created a need for additional infrastructure, hardware and capacity to pump the data through within the downtime window and "get the elephant through the eye of the needle."

Full-scale mock migrations were conducted in a sandbox identical to the production environment, and SNP maintained a "dual landscape" as a safeguard throughout the process, according to its website.

As for migrating BRIM itself, van Honschooten said a challenge arose from changes in how bank accounts are managed in ECC vs. S/4HANA.

"If you've got a custom field that is implemented the old way, an in-place conversion on a 10-billion-row table is incredibly hard to do," she said. "It's much easier to do it in a blank table and then do a migration into it." That meant custom fields had to be re-implemented in the new system.

The team also fixed several currencies to comply with the three-letter ISO currency codes used in S/4HANA.

How the move has benefitted Microsoft

After going live in August 2025, once it was clear the new BRIM system was stable, the team began addressing a laundry list of improvements.

"Post-conversion, we were able to do some pretty big things, which were fairly quick wins," van Honschooten said.

One was re-jiggering the batch schedule so data processing could run faster and the company could "de-risk" month-end accounting. Another was renovating the interfaces to data services by moving away from older SAP technology that used web services and remote function call (RFC) technology. As a result, integration with Microsoft's front-end systems is "much more performant," she said.

The migration also facilitated improvements to the Microsoft Dynamics 365 ERP system that the company uses as a front end to its credit and collections operations. It can now embed the SAP Fiori UX framework directly in Dynamics 365, which van Honschooten called a huge accelerator for lower-volume collections formerly requiring "swivel chair" integration that saw workers manually copying data from the old SAP UX to the new one.

Arbeeny noted the cascading benefits of faster data processing. "When your night batch takes 12 hours and you get it down to four, many opportunities become available for other things you can do," he said. "It's underpinned by the innovation in the technical stack as well as in the application layer. With that extra capacity, you can do more with the same level of infrastructure, and that opens the door for agentic."

Enabling Agentic AI

Van Honschooten said her team is, indeed, working on agentic AI, specifically for cash applications and collections where incoming customer payments must be matched with invoices.

The matching rate in the cash apps transformation, which started two years ago on ECC, has skyrocketed from 30% to around 85% on S/4HANA. The company is also implementing a smart dunning process that provides a better understanding of individual customers instead of following a fixed schedule. Agentic AI helps automate the inbound emails and other collections processes run through Dynamics 365.

"We're systematically going through all our workflows in that space and determining how we can better reduce the amount of people we need to be able to respond to customer inquiries and predictively understand when a customer is going to dispute an invoice so we can take action before the dispute gets raised," she said. Days sales outstanding (DSO) metrics should improve by getting more customers to pay on time.

'Cleaner core' approach to cloud ERP

SAP and many of its partners have been promoting a "clean core" methodology that calls for keeping the core of an ERP system focused on standard business processes and free of customization. But Arbeeny was adamant that Microsoft needed to move BRIM to private-cloud S/4HANA rather than the public-cloud version, which tends to strictly enforce clean-core rules.

He called clean core an oversimplification, saying some of Microsoft's customizations are mission-critical and that cleaner core is a more realistic term. "We can get better, but the reality that you're going to eliminate all those customizations that are mission-critical is really unrealistic," he said. "They're there for a reason. You built them because they make you who you are."

Van Honschooten clarified that the ECC to S/4HANA project was not about trying to re-implement all the customizations. Nevertheless, SNP's Bluefield approach to data migration enabled targeted improvements that move the company closer to a cleaner-core environment. She cited re-implementing custom fields to clean-core standards as an example.

She advised organizations planning a similar data migration to keep it simple and to not try to do too much. And leave plenty of room in the schedule for mock migrations. "We learned so much and got better and better each time. We ended up having a pretty clean conversion at the end of the day because we were able to practice it."

David Essex is an industry editor who creates in-depth content on enterprise applications, emerging technology and market trends for several Informa TechTarget websites.