Dead, Breaking or Compliant: How AI Agents Triage Custom ABAP for S/4HANA

Custom ABAP that nobody calls still gets migrated, tested, and paid for unless someone proves it is dead. That single fact drives more S/4HANA project overruns than almost any other technical issue. Teams spend weeks remediating code that has not run in production for three years. RISE with SAP S/4HANA migrations face this challenge acutely because the project timeline is tied to a contract rather than just an internal plan. Meanwhile, the programs that will actually break go undetected until cutover week.

AI-driven triage changes that equation. Instead of treating every custom program as a remediation candidate, SAP AI Solutions now classify each one before a developer touches it. So the result is a shorter scope, a faster migration, and a retirement list backed by evidence rather than gut feel.

Why Custom ABAP Becomes a Migration Liability

Most SAP landscapes carry between 5,000 and 50,000 custom ABAP objects. According to SAP, the average customer has roughly 3,000 custom programs that require some level of attention before moving to S/4HANA. A significant share of those programs are either dead, rarely called, or duplicates of standard functionality that S/4HANA already covers natively.

The problem is that nobody knows which is which without scanning. So teams default to remediating everything. That approach inflates budgets, extends timelines, and introduces risk by touching code that was stable and dormant.

The Hidden Cost of Migrating Dead Code

Dead code is not harmless. Every object that enters the remediation queue consumes developer hours, testing cycles, and transport slots. When a program has zero call records in the last 24 months, remediating it is pure waste. But without a structured scan, project managers have no way to separate the dead weight from the genuinely breaking programs.

Consider a mid-sized manufacturer running a 12,000-object custom estate. If 30 percent of those objects are dead, the team is looking at 3,600 programs that should never enter the remediation queue. At even a conservative estimate of four developer hours per object, that is over 14,000 hours of avoidable work. Multiply that by contractor rates, and the budget impact is significant enough to derail a business case.

This is where AI-driven triage earns its place in a migration plan.

How AI Agents Scan and Classify Custom ABAP for S/4HANA

AI-driven ABAP triage works in five steps: Scan, Triage, Rewrite, Review, and Prove. Each step produces a documented output, so nothing reaches a transport unreviewed. The process runs in minutes per program rather than weeks. This means a team can classify an entire custom code estate before the first developer writes a single line of remediated code.

Step 1: Scan

The scan phase pulls every custom ABAP object from the system and runs it through a static analysis engine. The engine checks for deprecated APIs, obsolete function modules, removed database tables, and syntax that S/4HANA no longer supports. It also pulls usage statistics from the system log. This allows it to flag programs with zero runtime calls over a defined lookback period.

This is not a manual code review. The scan runs automatically and produces a structured output for every object in scope. A typical enterprise scan covering 15,000 objects completes in hours, not weeks. That speed matters because it means the triage classification is available before the project team has committed to a remediation budget.

Step 2: Triage

Triage is where AI earns its value. Each program receives one of four classifications:

• Breaking: the code uses removed or incompatible APIs and will fail in S/4HANA without remediation.
• Degrading: the code runs but produces incorrect results because underlying data structures or business logic have changed.
• Compliant: the code is compatible with S/4HANA as written and needs no changes.
• Dead: the code has not been called in production within the lookback window and has no scheduled job or interface dependency.

The dead classification is the one that shrinks scope. A well-executed triage on a 10,000-object environment typically moves 20 to 40 percent of programs into the dead or compliant buckets. This is according to project data from SAP partners working on large enterprise migrations. That means developers focus only on the breaking and degrading programs, which is where the real risk lives.

Step 3: Rewrite

For breaking and degrading programs, the AI agent generates a remediated version. It replaces deprecated APIs with their S/4HANA equivalents and updates database access patterns to the new data model. It also flags any logic that requires a human decision before it can be rewritten safely. SAP’s overview of agentic AI for ABAP development provides additional context on how these capabilities are reshaping developer workflows.

The agent does not guess. When it encounters a deprecated function module that has a direct S/4HANA replacement, it substitutes it and documents the change. When the replacement requires a business rule decision, it raises a flag and routes the program to a developer with a specific question rather than a blank slate. That distinction matters because it keeps developers focused on judgment calls rather than mechanical substitutions.

Step 4: Review

Human review is not optional. The AI-generated rewrite is a starting point, not a finished product. A developer reviews each remediated program and confirms the logic is correct. They sign off before the object moves to testing. This step is faster than writing the remediation from scratch, but it is not skipped.

Teams that skip human review on AI-generated code create a different kind of risk. The agent may substitute the correct API but miss a downstream dependency that only a developer familiar with the business process would catch. So review is where that gap closes.

Step 5: Prove

The prove phase runs automated regression tests against the remediated code. It compares outputs from the legacy system against outputs from the S/4HANA environment. This confirms the program behaves identically. When results match, the object is cleared for transport. When they diverge, the discrepancy goes back to the developer with a diff report rather than a vague failure message.

This five-step process is what separates structured AI triage from ad hoc code scanning. Each step has a defined input, a defined output, and a clear owner.

What the Triage Results Mean for Project Planning

The triage output is not just a technical report. It is a project planning tool. Once every object has a classification, the project manager can build a remediation backlog that reflects actual risk rather than assumed scope.

Prioritising the Breaking Programs First

Breaking programs are the ones that will stop the system from running at all. They go to the top of the remediation queue. Within that group, the AI triage report ranks programs by call frequency. The team works on the most-used breaking programs before the rarely-called ones. A program that runs 200 times a day in the warehouse gets fixed before a program that runs once a quarter in a legacy report.

That prioritisation sounds obvious, but it rarely happens without structured data. When developers work from a flat list of flagged objects, they tend to pick the ones they know or the ones that look straightforward. So AI-generated prioritisation removes that bias.

Handling the Degrading Programs

Degrading programs are more dangerous than breaking ones in some ways. A breaking program fails visibly. A degrading program runs and produces wrong results. These wrong results may not surface until a finance team closes the period and finds the numbers do not reconcile.

SAP AI Integration tools flag degrading programs with a specific warning type. This ensures they do not get treated as compliant. The remediation approach for a degrading program often involves more business analysis than a breaking program does. The developer needs to understand what the correct output should be before rewriting the logic.

Retiring the Dead Code

Dead programs should not be migrated. But retiring them requires documentation. The triage report provides that documentation: the last call date, the calling program or job, and the classification rationale. That evidence supports the retirement decision in a change advisory board without requiring a developer to manually research each object.

For organisations moving to SAP S/4HANA Cloud, the retirement step is even more important. Cloud environments have tighter constraints on custom code volume. Arriving with a clean, documented estate rather than a full legacy footprint reduces both cost and ongoing maintenance burden.

The Role of AI Triage in a RISE with SAP S/4HANA Migration

Organisations moving through RISE with SAP S/4HANA face a specific challenge. The migration path includes a managed infrastructure transition alongside the technical upgrade. This means the project timeline is tied to a contract rather than just an internal plan. Delays in custom code remediation can push the go-live date past the contracted migration window, which has commercial consequences.

AI-driven triage compresses the custom code phase enough to protect that timeline. When the triage classification is complete before the remediation sprint begins, the team knows exactly how many developer weeks the breaking and degrading programs will require. That estimate is based on actual object counts and complexity scores, not on a percentage assumption applied to the total estate.

Connecting Triage to the Broader Migration Architecture

Custom code triage does not happen in isolation. It connects to the broader migration architecture through the transport system, the test environment, and the cutover plan. When the triage output feeds directly into the project's backlog tool, each classified object becomes a work item with a priority, an owner, and a definition of done.

That connection is what makes AI triage a project management asset rather than just a technical tool. The project manager can track remediation progress at the object level. They can identify bottlenecks before they affect the timeline and report scope changes to the steering committee with evidence.

Building a Custom Code Centre of Excellence Around AI Triage

For organisations with large custom estates, a single migration is not the end of the story. Custom code grows back. New programs get written, old ones get modified, and within two years of go-live, the estate starts accumulating technical debt again.

A Centre of Excellence built around AI triage prevents that accumulation from becoming a future migration liability. The triage process runs continuously rather than as a one-time pre-migration exercise. New custom objects are scanned at creation and classified against the current S/4HANA standard. They are flagged if they introduce patterns that will cause problems at the next upgrade.

Governance That Scales With the Estate

Governance is the part that most organisations underinvest in after go-live. The triage tooling is in place, but nobody owns the process of reviewing the output. A Centre of Excellence assigns that ownership explicitly: a named team reviews the triage dashboard on a defined cadence. They retire dead objects on a schedule and escalate breaking patterns to the development team before they accumulate.

That governance model works for any industry. Whether the organisation operates in manufacturing, financial services, or SAP for Healthcare Providers, the principle is the same: custom code that is not actively governed becomes a migration liability at the next upgrade cycle.

Frequently Asked Questions

Q. What is AI-driven ABAP triage and how does it differ from a standard code scan?

A. AI-driven ABAP triage is the automated process of classifying every custom ABAP object in an SAP system as breaking, degrading, compliant, or dead before remediation begins. A standard code scan flags syntax errors and deprecated APIs, but it does not prioritise objects by business risk or usage frequency. AI triage adds that layer of intelligence. This allows project teams to work on the right programs in the right order.

Q. How long does it take to triage a large custom ABAP estate?

A. A scan covering 10,000 to 15,000 objects typically completes within hours using automated tooling. The classification output is available before the remediation sprint begins. This means the project team can build an accurate backlog without waiting weeks for a manual assessment. The speed advantage is most visible on large enterprise estates where manual review would take months.

Q. Can AI-generated ABAP rewrites be used without human review?

A. No. AI-generated rewrites are a starting point, not a finished product. A developer must review each remediated program to confirm the logic is correct and that no downstream dependencies were missed. Skipping human review introduces a different category of risk. The agent may substitute the correct API while missing a business rule that only a developer familiar with the process would catch.

Q. How does AI triage support a migration to SAP S/4HANA Cloud?

A. SAP S/4HANA Cloud environments have tighter constraints on custom code volume than on-premise systems. Arriving with a clean, documented estate reduces both cost and ongoing maintenance. AI triage identifies dead and compliant objects before migration. This ensures the organisation does not carry unnecessary code into the cloud environment. The retirement documentation produced by the triage report also supports the change advisory process.

Q. What role does 2iSolutions play in AI-driven ABAP triage for S/4HANA migrations?

A. 2iSolutions supports enterprise SAP migrations by providing the technical and functional expertise needed to act on triage results, not just generate them. That includes staffing the developer review step, connecting triage output to the project backlog, and building the governance model that prevents technical debt from accumulating after go-live. The combination of tooling and experienced consultants is what turns a triage report into a completed migration.

How Accurate Triage Data Protects Your Migration Budget

Custom code remediation is one of the most consistently underestimated costs in an S/4HANA migration. Teams that start with a full estate and no classification data end up padding their estimates to cover the unknown. This inflates the business case and makes the project harder to approve.

Accurate triage data removes that uncertainty. When the project manager can show the steering committee exactly how many breaking programs exist, how many are dead, and how many are already compliant, the remediation budget becomes a calculation rather than a guess. That precision also makes it easier to phase the migration. The team knows which programs must be remediated before go-live and which can be addressed in a post-migration sprint.

2iSolutions works with organisations at this exact stage: after the triage output is available but before the remediation sprint begins. That is the point where scope decisions have the most impact on cost and timeline. Getting the classification right, building the backlog correctly, and assigning the right developers to the right objects is where a migration either stays on track or starts to slip.