Revert to Standard: Achievable Destination or North Star?

I have been spending a lot of time lately in conversations with SAP customers and partners around the concept of "Revert to Standard" in the context of their upcoming S/4HANA transformation project. It is the question that comes up more than any other: "How do I get rid of my customizations and Revert to Standard?" — Here is the truth: unless you are going Greenfield, the more I dig into it, the more I think we might be using the wrong words.

Let me explain what I mean.

Maybe We Should Be Talking About Repository Simplification

"Revert to Standard" implies going back to something, as if the standard was always the right answer and customization was a mistake. But for most organizations that went live on R/3 in the late 1990s, the standard genuinely could not do what the business needed. Customization wasn't negligence, It was one of the reasons customers chose to implement SAP in the first place. SAP and its ABAP development foundation provided customers the flexibility to address functional gaps with customization.

Maybe it is time to change the framing. Perhaps we should take all of the terms we have been using lately like Revert To standard, Clean Core and reframe it as repository simplification - a deliberate, evidence-based effort to reduce your custom footprint, retire what no longer serves a purpose, migrate where SAP standard now genuinely covers the need, and modernize what must stay custom so it works with SAP's architecture instead of around it.

That distinction matters a lot when you are setting expectations for your SAP program. "Revert to Standard" sounds like a destination. Repository simplification describes a direction and a discipline that is a more honest conversation to have.

A Real Scenario

Picture a manufacturing company going live on SAP R/3 in 1998. The project team identifies that the sales order header table doesn't capture the customer-specific data needed to drive their order fulfillment process. So the functional consultant whips up a functional spec, hands it off to the development team, who add their technical spec to the project document repository, and an eager ABAP developer fresh out of the academy adds five custom fields to VBAK through an append structure. Documented. Approved. Two weeks of work.

Fast forward to 2026, and those five fields have been busy.

They show up in the custom order confirmation form that gets emailed to customers. They feed the daily sales extract into the data warehouse. A pricing routine reads one of them to determine discount eligibility. A workflow uses two of them to route high-priority orders to a special fulfillment team. A custom report runs every morning that filters and aggregates against three of them. The EDI interface that sends order acknowledgements to the customer's procurement system includes all five.

Nobody planned this. Nobody drew a dependency map. The implementation team was simply do what it does best, satisfying customer requirements. It grew organically because those five fields captured something real and valuable, and smart developers kept building on them.

This is the actual shape of technical debt for almost all SAP enterprise customers. It is not a pile of bad code. It is a web of reasonable decisions made one at a time across nearly thirty years.

SAP Gets There — But Only Partially

Fast forward, and it is 2026. That customer is now prepping for S/4HANA transformation, and a functional consultant stumbles upon a Simplification that sounds encouraging. SAP now delivers standard fields that cover two of the original five requirements. The functionality arrived around the 2020 release.

This is exactly what a good Revert to Standard analysis is supposed to surface. Two fields can go. Replaced by a standard. That is a real win.

Not so fast.

Those two fields don't disappear from the landscape by changing a field definition. They disappear from every downstream system that consumed them. The order confirmation form needs to be updated. The data warehouse mapping needs to change. The BADI logic needs to be rewritten. The EDI interface needs a new mapping. And the historical data — millions of sales order records going back to 1998 — either needs to be migrated to the new standard fields or your reporting logic needs to handle two parallel data structures for historical versus current records.

Now extend that scenario out across your entire application. Is this really what you signed up for when you are just looking to get that support deadline off your back?

The remaining three fields have no standard equivalent. They capture genuinely business-specific logic that SAP has never addressed because it reflects how this company specifically operates. These fields are staying. They should stay. They are earning their maintenance cost.

But those three fields still need everything that references them reviewed, modernized, and brought forward. The VOFM routine should move to a clean core extension pattern. The custom report should be rebuilt against a CDS view. The workflow routing logic should migrate to SAP Build Process Automation.

None of that is "reverting to standard." That is simplification — and it is still real, valuable work, but complexity and timing must really be considered.

For five fields added in 1998, the outcome is: two replaced, three retained and simplified, with a data migration workstream, a form update, an interface re-mapping, and a downstream systems review attached. Now multiply that story across hundreds of custom objects in a typical landscape.

Why an LLM Alone Cannot Solve This

There is a lot of enthusiasm right now about using large language models and AI Assistants to solve exactly this kind of problem. You will see people building solutions using the buzzwords, showing slick demos of one of the big LLMs wrapped up in a chat window with maybe a couple of tools to make it seems like it knows ABAP code and SAP. But does it truly understand the full context of the spiderweb of development impacted and how to address transformation at a broader level to ensure that process doesn't break?

It doesn't. Not at the level of precision that makes transformation decisions trustworthy.

Here are the key questions I would want you to ask before relying on any AI-assisted approach:

• Does the tool actually know what SAP standard delivers today — at the field level, the API level, the extensibility framework level — or is it reasoning from general knowledge and making confident-sounding guesses?
• Can it trace the downstream impact of a custom field across every object that touches it, or does it analyze objects in isolation?
• When it recommends replacing a customization with standard functionality, can it show you exactly which standard field, which CDS view, which Fiori app it is mapping to — or is it giving you a plausible-sounding answer?
• Are you confident the data it is reasoning from is current? SAP releases continuously. A comparison surface that was accurate twelve months ago is already stale.

An LLM can read ABAP code. It can summarize what a program does. It can identify patterns. There is even some promise coming in the development assistance space for ABAP developers. These are useful capabilities. But the core challenge in repository simplification is not reading the code — it is mapping that code against a precise, structured, continuously maintained knowledge base of what SAP standard actually delivers today, and tracing the full dependency chain when you make a change.

When the question is "Does S/4HANA 2023 include a native field that covers what ZVBAK-ZCUST_PRIORITY is doing?" the answer doesn't come from reasoning. It comes from a structured representation of SAP's data model that has been built, validated, and maintained as a data asset. An LLM that hallucinates a field name doesn't just give you a wrong answer; it sends your team down a path that costs real time and real money to unwind.

The Data Foundation Is Everything

At smartShift, we have spent years building the data infrastructure that makes repository simplification trustworthy at scale. That means a platform understands the entire repository. A platform that can read every custom object and understand precisely what it does. It means a a solutions supported with the proper understanding of the SAP application context. It means confidence scoring that distinguishes between a valid technical recommendation you can act on immediately and one that needs a human to validate decision-making first.

As with any newer innovation in this space, there is a lot of market noise right now. New entrants, independent tools, and no shortage of AI-powered promises. Before you commit to an approach, make sure you have clear answers to what data is actually powering the recommendations and how current that data is.

"Revert to Standard" as a direction is exactly right. As a deliverable without that foundation underneath it, it is a setup for disappointment.

I am always interested in conversations with people who are working through these questions. If your organization is approaching an S/4HANA transformation and you want to talk through what a real repository simplification program looks like, reach out.