Most conversations about SAP modernization focus on the big-ticket items: the move to S/4HANA, the cloud migration roadmap, the CI/CD pipeline everyone wants but few have fully built. SAP system refresh rarely makes that list. Instead, system refreshes are treated as plumbing: necessary, unglamorous, and easy to defer until they become a crisis.
One organization’s experience shows why that’s a mistake. After completing a major SAP S/4HANA transformation, a large U.S. specialty beauty retailer, with well over 1,000 stores across multiple countries, found that its ability to refresh QA environments quickly had become the real constraint on how fast the business could deliver change.
As the retailer’s IT director for performance, automation and QA put it during a session at SAP Sapphire 2026, the problem wasn’t a lack of ambition. It was that refreshing a production-like environment for testing had become too slow, too manual, and too expensive to do as often as the business needed.
This is the story of how the retailer turned that bottleneck into a competitive advantage and why automation, not just better tooling, is what actually made it possible.
A process too slow to repeat
Like most SAP shops running at scale, the retailer doesn’t operate with a single QA environment. Between ongoing production support and active projects, the IT director said the company can have up to five separate QA systems running at once — each one needing production-like data to be useful.
The trouble was the refresh process itself. It was entirely manual, pulling in Basis, security, and QA teams to export and restore RFC destinations, SM59 configurations, and non-production users by hand. The IT director described the practical effect plainly: when a process takes that much coordinated effort, you likely don’t repeat it often. The retailer was refreshing some environments as infrequently as once a year, far too slow for a company that, as the IT director described it, adds more than 100 new retail items every week and processes thousands of e-commerce orders a minute, each one generating its own SAP order and IDOC.
The result was a familiar trade-off: stale, unrepresentative test data, and QA teams stuck waiting on environment readiness instead of testing.
Proving the savings, not just the automation
What’s notable about the retailer’s approach is the discipline behind it. The IT director was explicit that automation for its own sake wasn’t the goal — and that his team was held to a higher bar by leadership: “I didn’t want us to just say, ‘Oh, it’s an automated process that now is taking less time.’ … We had to prove this to our leadership… what are you really saving from this?”
That meant defining success around measurable dimensions, starting with duration and effort. Anything that didn’t move those numbers wasn’t worth doing. It’s a useful discipline for any team evaluating automation investments.
Why the application layer needs its own automation
Working with an implementation partner, the retailer recognized that database-level tooling alone couldn’t solve the whole problem. A refresh also leaves a great deal of work inside the SAP application layer, and that work needs its own automation. Avantra handles that SAP application-layer work: the pre- and post-refresh steps that happen inside SAP itself.
That distinction matters more than it might first appear. As the IT director explained, database-level tools can’t validate whether an SAP system is actually usable after a refresh: “You need a tool that can actually go in the SAP application layer and run transactions or RFCs to verify it. So that’s why we use Avantra.”
Connectivity tests, RFC destination restoration, SM59 configuration recovery, and user re-provisioning for non-production systems all require operating inside SAP itself, work that previously fell entirely on the Basis and security teams, every single refresh, by hand.
Database-level tooling can’t do that pre- and post-refresh application work. Automating it is what turned a fragmented, people-dependent process into an orchestrated one.
The results: Speed and effort moving together
The numbers the retailer brought back to leadership were the kind that justify the investment on their own. These are the figures as presented in the session, and they reflect the refresh program as a whole, not any single tool:
- Refresh duration: 15 days → 5 days (a 67% reduction)
- Manual labor: 80 hours → 20 hours per refresh (a 75% reduction)
- Automation coverage: approximately 85% of the SAP refresh lifecycle
In the IT director’s own words: “We actually went from a 15-day duration down to five… and from 80 hours of actual labor down to 20 hours per refresh.” He was also clear that this isn’t the ceiling. With further automation, he believes refresh duration could come down further still.
But the metric that may matter most isn’t any single number, it’s what speed unlocks. Faster refreshes mean refreshes can happen more often, which changes what’s possible for the business. “Once we reduce the time down to five days instead of 15 days, we can start refreshing more of our environments more often,” the IT director noted, pointing to a real example where a team wanted a fresh environment specifically to test year-end close, something that simply wasn’t feasible under the old once-a-year cadence.
Beyond the spreadsheet: A different way of working
The deeper impact went beyond operations; it changed how skilled teams spend their time. Rather than reducing headcount, the retailer redirected expert effort away from repetitive, manual execution and toward higher-value work: continuous improvement, faster response to ad hoc requests, and better-governed, fresher data for QA and UAT.
That combination of speed and freed-up expertise is what turns a refresh project into a repeatable capability.
From Refresh-as-a-Project to Refresh-as-a-Service
Perhaps the most important shift the retailer made was conceptual. When a refresh takes 15 days and consumes 80 hours of skilled labor, it can only be justified and funded as a project. That keeps refreshes rare, which keeps test data stale, which keeps QA slower than the business needs it to be.
The IT director laid out where the team wants to go next: “If we can just make refresh again as simple as entering a ticket and it’s done… maybe even better, you release a change to QA environment and as part of that process, we actually provision you an environment right away from production and have it up and ready with your change over.”
That’s the real destination: refresh-as-a-service rather than refresh-as-a-project, with the request, execution, and readiness validation all automated end to end, ideally integrated with CI/CD and ServiceNow. The retailer isn’t there yet. With roughly 85% of the refresh lifecycle automated, a goal of automating the rest, and plans to extend the model from two environments to all five and into applications beyond SAP, the path is clear.
The takeaway
System refreshes will never be the headline of a transformation roadmap. But as this retailer’s experience shows, they quietly determine how fast everything else can move. A manual, once-a-year refresh process doesn’t just cost labor and time — it caps release velocity, QA confidence, and the business’s ability to test the scenarios that actually matter.
Automating the application-layer work that SAP refreshes demand, not just the database copy, but the RFCs, the connectivity validation, the user restoration, is what lets speed and quality scale together instead of trading off against each other. That’s the difference between treating refreshes as an occasional project and treating environment readiness as a continuous, automated operational capability.
If you want to learn more, contact an Avantra expert for a discussion and demo. We’d love to show you how Avantra smooths System Refreshes and more for teams managing complex SAP operations.
To see how Avantra automates SAP operations across on-premises, Cloud ERP Private and BTP, visit the platform page or talk to one of our SAP experts.