SAP System Analysis with AI Agents in 2026

Disclaimer: This is a technical exploration, not consulting advice. Every SAP system is different. I haven't built a finished product — I'm mapping out what's technically possible.

Every S/4HANA migration starts with the same question: What's actually in our system?

Custom code, customizing, transports, interfaces, batch jobs — someone has to inventory all of it before you can plan the migration. That "someone" is usually a consultant opening Eclipse, clicking through packages, running checks, and exporting results to Excel. It works, but it's slow.

I've been looking into a different approach: using SAP's own APIs to let an AI agent do the scanning.

SAP Has a REST API Most People Don't Use

ABAP Development Tools (ADT) is SAP's Eclipse-based development environment for ABAP programming. Under the hood, it communicates with the SAP backend entirely via a REST API. The base URL is straightforward:

https://your-sap-host:port/sap/bc/adt/

Everything Eclipse does — browsing objects, reading source code, running checks, managing transports — goes through this API. That means anything Eclipse can do, a script can do too.

There's even an open-source TypeScript library (abap-adt-api by Marcello Urbani) that wraps most of these endpoints in a clean interface. It was built for the VS Code ABAP Remote Filesystem extension, but it works for any programmatic access.

What's Actually Accessible

I went through the library's source code to map out what's exposed. This is what an agent could read:

Custom Code Inventory

searchObject — find all Z* and Y* objects across the system
nodeContents — navigate the package structure
objectTypes — classify objects (reports, classes, function modules, interfaces)
getObjectSource — read the actual ABAP source code

Quality Analysis

createAtcRun / atcWorklists — run and retrieve ABAP Test Cockpit checks remotely
syntaxCheck / syntaxCheckCDS — check syntax for ABAP and CDS views
usageReferences — find where each object is used (or not used — dead code detection)
runUnitTest / unitTestEvaluation — execute and evaluate unit tests

Transport Landscape

transportInfo / userTransports — see all transports per user
transportConfigurations — understand the system landscape (Dev/QA/Prod routes)

Data Dictionary

ddicElement / ddicRepositoryAccess — read table structures, data elements, domains

Performance

tracesList / tracesDbAccess — analyze database access patterns and performance traces

System Info

systemUsers — list active users on the system
gitRepos — check abapGit repository status

On top of that, OData gives you access to the configuration tables that ADT doesn't expose — organizational structures (T001), number ranges (NRIV), RFC destinations (RFCDES), batch job configurations, authorization roles, and the SAP Data Dictionary tables (DD03L, DD04T, DD05S) that describe every field in every table.

ATC: The Core of Any Migration Analysis

The ABAP Test Cockpit (ATC) is SAP's built-in tool for static code analysis. It scans ABAP custom code against a set of check variants and reports findings — think of it as a linter for ABAP, but with SAP-specific rules including S/4HANA compatibility checks. It checks custom code for:

S/4HANA compatibility — deprecated table accesses, removed function modules, incompatible APIs
Performance issues — inefficient SELECT statements, missing indexes
Security risks — SQL injection patterns, missing authority checks

Anyone migrating to S/4HANA runs ATC. It's essentially mandatory.

The interesting part: ATC is fully remote-controllable through ADT. An agent can start a check run (createAtcRun), wait for it to complete, and pull all findings (atcWorklists) — without anyone opening Eclipse.

That's where the LLM comes in. Instead of a human scrolling through hundreds or thousands of ATC findings, an LLM can read them all, classify by severity and business impact, and produce a summary that's actually readable for someone who isn't an ABAP developer.

What a Scan Workflow Could Look Like

Phase 1: Discovery (~30 min)
├── Search all custom objects (Z*, Y*)
├── Map package structure
├── Classify by object type
├── Read transport landscape
├── Pull interface list (RFC destinations)
└── Count: X programs, Y tables, Z function modules

Phase 2: Quality Analysis (~1-2 hours)
├── Run ATC with S/4HANA check variant
├── Pull all findings
├── Check for dead code (objects with no usage references)
├── Run unit tests where available
└── Analyze DB access patterns

Phase 3: AI Assessment (~15 min)
├── LLM reads all findings with S/4HANA context
├── Classifies risk per package (red/yellow/green)
├── Identifies top critical findings
├── Suggests migration sequence
└── Produces executive summary

The total runtime depends on system size, but for a typical Mittelstand system with a few thousand custom objects, we're talking hours — not weeks.

System Comparison

Run the same scan on two systems — say production and sandbox — and you get an automatic delta:

Objects that exist only in one system (missed transports?)
Objects that differ between systems (drift)
Configuration differences (different number of company codes, different customizing)

For companies with multiple SAP instances across locations, this answers the question every CIO asks before a consolidation: "How different are our systems, really?"

What This Doesn't Do

Let me be honest about the limitations:

No business process analysis — the agent reads technical artifacts, not business requirements
No functional assessment — deciding which customizing to keep or rethink requires domain expertise
No migration execution — this is analysis, not implementation
No guarantee of completeness — if ADT services aren't activated or certain ICF nodes are blocked, the scan will be incomplete

The agent gives you the technical fact base. What you do with those facts still requires human judgment.

Prerequisites

This doesn't work on every SAP system:

SAP NetWeaver 7.40+ (for the ADT REST API)
ICF service /sap/bc/adt activated — many systems have this for Eclipse users already
OData Gateway active — usually present if Fiori is in use
A service user with read access to the repository and ATC
Network access to the SAP system

Most systems running NetWeaver 7.50+ already have everything in place.

Why This Matters Now

Two things are converging: SAP is pushing the S/4HANA migration deadline, and LLMs have gotten good enough to actually understand code and technical findings in context.

The APIs have been there for years — ADT has existed since 2012. What's new is having an AI layer that can make sense of the output at scale. Reading 2,000 ATC findings and producing a prioritized, explained report — that wasn't feasible without an LLM.

I'm not selling anything here. I'm exploring what's technically possible and sharing what I find. If you're dealing with S/4HANA migration planning, the combination of ADT + OData + AI is worth looking into.

The data is there. The APIs are there. Someone just needs to connect them.

How This Compares to Existing Approaches

Approach	Speed	Depth	Data Stays On-Premise	Repeatable	Cost Range
SAP Readiness Check	Hours	Surface level	No (SAP cloud)	Yes	Free
Consultant + Eclipse + Excel	Weeks	Deep	Yes	No (manual)	High
Panaya	Days	Deep	No (cloud upload)	Yes	High
Tricentis LiveCompare	Days	Deep	Hybrid	Yes	High
AI Agent via ADT + OData	Hours	Deep	Yes	Yes	Low

The AI agent approach combines the depth of a consultant-led analysis with the speed and repeatability of automated tooling — without requiring source code to leave the customer's network.

If you're interested in how AI and enterprise systems intersect, you might also find these posts relevant:

The data is there. The APIs are there. Someone just needs to connect them.

Frequently Asked Questions

What is ADT in SAP?

ABAP Development Tools (ADT) is SAP's Eclipse-based development environment for ABAP. It communicates with the SAP backend via a REST API, which means all operations — browsing code, running checks, managing transports — are available as HTTP endpoints.

Can ATC be run remotely without Eclipse?

Yes. The ADT REST API exposes endpoints for creating ATC runs and retrieving results. The npm package abap-adt-api wraps these in a TypeScript interface. No Eclipse installation required.

Does this work on SAP ECC or only S/4HANA?

The ADT API is available on any SAP NetWeaver 7.40+ system, which includes most ECC installations running on a recent kernel. You don't need S/4HANA to use ADT — in fact, the primary use case is analyzing ECC systems before migrating to S/4HANA.

Does the source code leave the SAP system?

That depends on how the agent is deployed. If it runs on-premise or in the customer's network, the data stays local. The ADT API returns source code as HTTP responses — where those responses are processed and stored is an architectural decision.

What's the difference between this and SAP Readiness Check?

SAP Readiness Check is a free service that provides a high-level overview. It tells you "you have X custom objects and Y simplification items apply." An ADT-based agent goes deeper: it can read actual source code, run detailed ATC variants, check usage references for dead code detection, and produce findings at the individual object level.

I work at the intersection of SAP and AI. If you're exploring similar approaches or have experience with ADT automation, I'd like to hear about it — reach out on LinkedIn.