An SAP system with 3,500 custom programs needs 3,500 decisions: keep, replace with standard, rebuild or retire. Even at only ten minutes per program, a first review takes around 580 hours. That can't be done by hand ahead of the fit-to-standard workshop, and after the workshop the real work only begins. Agents change that. They go through every recommendation, deliver the statistics, plan the implementation and carry out the packages the business has signed off.

Fit-to-standard and custom code

In the Explore phase of SAP Activate, business users and consultants walk through the standard processes in fit-to-standard workshops, one business area at a time. Whatever the standard doesn't cover goes into the backlog as a delta requirement.

That works well for a company implementing SAP for the first time. For a company coming from an SAP system that has grown over the years, though, the workshop often lacks an overview of what the company does differently today. It then comes from the key users' memory. Much of that deviation is recorded in the custom code, including things nobody thinks of in a workshop, and it becomes usable for the workshop once the code is mapped to business processes.

For each of these custom developments the same question comes up: does the standard cover this by now? With 3,500 programs, the workshop can't ask it for each one. In a system conversion the same question comes up in the custom code analysis.

Volume is the problem

An experienced consultant can assess a single program. The problem is the volume. 580 hours is a good three months full time for one person, and the system keeps changing in the meantime. So often only a selection makes it into the workshop, and the rest goes unchecked.

SAP provides part of this itself. Usage data from SCMON and SUSG shows what doesn't run, and the Custom Code Migration app shows what needs technical adjustment for SAP S/4HANA. The review builds on that. For each program, the question remains whether the standard now covers it and what in the system depends on it.

An agent can take this on. It goes through every recommendation, not just a sample, and repeats that after every new export. The result is statistics across all recommendations, which hardly ever exist when the work is done by hand.

Statistics across all recommendations

Made-up example: 3,500 recommendations split into retire 1,180, replace with standard 460, keep 820, rebuild 260 and open 780. 2,720 cases go to sign-off with evidence, 780 into the workshop. — A made-up example with 3,500 custom programs. By hand, a first review would take around 580 hours.

You can see at a glance where the work is. Programs with no usage in thirteen months and no callers are retirement candidates. SAP recommends measuring usage for six to eighteen months, including at least one year-end closing. Programs with a standard candidate backed by a source are replacement candidates. Whether a program that is in use and has no standard candidate is kept or rebuilt depends mainly on whether it builds on released interfaces or on modifications and unreleased SAP objects. That is the distinction SAP's clean core approach makes. These cases go to the business for sign-off with their sources. Only the cases where the answer is genuinely open go into the workshop: 780 instead of 3,500 in this example.

Broken down by process, the statistics become the basis for planning. They show which process has the most open cases and where the most can be retired.

Made-up example: the same split per process, from order-to-cash with 880 programs and 190 open cases to record-to-report with 400 programs and 85 open cases — The same made-up numbers per process. On the right, programs in total and how many of them are open. "Cross-process" covers programs not assigned to a single process.

Planning and execution with agents

This is where the real difference lies. The statistics are the basis; agents can take on the steps that follow as well.

Five steps: Sysparency analyses, an agent pre-sorts, the business signs off, an agent plans, an agent executes. After the next export the statistics show the progress. — The business decides; agents do the work before and after.

Pre-sort. The agent assesses every recommendation. For each standard candidate it states whether the facts support it, speak against it or something is still missing, and names the sources.
Sign off. The business confirms the clear cases; the workshop decides the open ones.
Plan. The agent proposes work packages per process. Connected programs go into the same package, and the order follows the dependencies, across process boundaries too.
Execute. Agents implement the signed-off packages in the development system through the SAP ADT MCP server, as in the migration of twelve Dynpro transactions on a trial system. Testing, transport and acceptance follow the usual process, and each package can be checked on its own.
Keep current. After every new export the agent goes through the recommendations again. The statistics then show what's done and what's new, even if the project runs for months.

An agent can pre-sort, plan and keep current today with the Sysparency MCP server, which opens the knowledge graph to it, and SAP's documentation MCP servers, and implement with the SAP ADT MCP server. The Sysparency MCP server works with any MCP-capable client, such as Claude, ChatGPT, Microsoft Copilot or Langdock, so you use whichever tool your company has approved. We are building the evaluation of standard candidates directly into the Sysparency report.

The agent has to understand the program in context

An agent finds the current SAP standard in the documentation. For its recommendations to hold up, though, it has to understand the custom development and how it fits into the system as a whole: who calls it, which other programs depend on it, which tables they share and whether it runs at all. Otherwise it might recommend a standard app for one program even though a dependent program can't be mapped to the standard. Conversely, one standard function sometimes replaces several custom developments at once, such as a menu, the reports it calls and the maintenance programs for the same tables.

Sysparency supplies that context. It doesn't just analyse individual programs, it analyses the whole system: process assignment, calls in both directions, tables, standard interfaces, usage, and the transactions and reports that exist in the customer's system. In a test with HR cases from one customer, the model used this context to name standard candidates an experienced HR consultant had in mind, such as transaction PT40 for the custom menu for time administrators.

This isn't limited to SAP: where a process also runs through applications in Java, .NET or COBOL, Sysparency analyses them too, and the agent sees that part as well.

What the workshop still decides

Whether a deviation is a competitive advantage, an obligation or just a gap from years ago isn't written in any code or documentation. Business users and consultants decide that in the workshop. The difference is that they no longer face 3,500 programs, only the cases where the answer is genuinely open, each with the sources from both sides.

We'd be glad to show you what this looks like for your system, based on an analysis of your custom code. Request a demo