Review Z-tables and customizing entries with agent support — propose mapping, deprecation, or archival per field, with a full audit trail for the migration review.
In short: The agent reviews Z-tables and customizing entries and proposes mapping, deprecation, or archival per field. Stack: Claude (Anthropic direct) or Azure OpenAI Switzerland, SAP metadata parser on DD02L/DD03L, static ABAP code analysis, optional DB statistics from Oracle or HANA. Industries with the biggest leverage: SAP-heavy environments across manufacturing, insurance, and public sector — anywhere ECC or S/4HANA has grown for ten-plus years and nobody quite knows which Z-fields are still alive. Per field, a structured proposal plus audit entry is produced — the migration expert only reviews "unclear" cases and "deprecate" recommendations in high-risk areas. Connects upstream to the agentic SAP migration and downstream to the later migration audit & sign-off.
Z-tables with more than ten years of customizing — nobody remembers which fields are still used, which reports access them, or whether a field was just created "for later" once. At migration time, the question is binary: walk through every field one by one (weeks of Z-table archaeology) or lift-and-shift the lot (migration gets unnecessarily expensive and the target system starts loaded with legacy ballast)? Both are wrong, but one costs time and the other costs substance. In practice almost every project picks option two — not because it's right, but because the cut-over date is fixed and the manual path doesn't scale.
The deeper problem: custom fields and Z-tables don't have a single usage signature. A field can exist in the DDIC, be referenced in a report, and yet have had no write access in five years — or, the other way round, be filled regularly without any report ever reading it. Untangling this manually means combining several data sources: ABAP code search across reports, smart forms, Adobe forms, function modules; DB statistics on write access; sample data distribution; BI/BW extractor definitions; IDoc mappings; potentially custom Fiori apps or external interfaces. Exactly this combination is what an agent can deliver in minutes per field, where manual review often takes hours.
The agent works on an inventory of Z-tables and Z-fields from the SAP source system. For each field it gathers structured signals: schema definition from DD02L/DD03L, write-access statistics from DB history (Oracle, HANA), read references from static ABAP analysis over reports, smart forms, Adobe forms, and function modules, BI/BW extractor usage, sample data distribution (fill rate, default constancy, value range). From these signals it derives a classification — active, unused, partial, or unclear — and proposes one action per field: map to target, deprecate, or archive only.
Model-side, Claude is used for longer reasoning chains across multiple code locations and metadata sources; Azure OpenAI Switzerland is the option when Swiss data residency is a contractual condition. Tool-side, the agent accesses the DDIC directly through the SAP metadata parser, the ABAP analyzer runs as a static pass over the repository, and DB statistics are pulled through a read-only connector. Guardrails: a curated eval set per classification class, cost caps per reconciliation run, hard escalation on any field with IDoc usage or external interface references, and fully read-only behaviour — the agent writes nothing back into the SAP system, only into the audit log and the reconciliation sheet.
Important: the agent doesn't make final decisions. It prepares and only commits where signals are unambiguous. For any field with contradictory signals (e.g. an ABAP reference exists, but no write access in five years) it classifies as unclear and hands it to the migration expert. It similarly escalates every deprecate proposal in high-risk areas — financial accounting, tax logic, regulated master data. The leverage comes from the long tail of clearly classifiable fields, not from bold black-box decisions.
An SAP S/4HANA migration project — composite, not a real client — with 800 Z-tables, roughly 400 of them in unclear status. A typical mix: actively used custom tables (e.g. a Z-order type with daily write access and several report connections), long-dead fields from old customizing (a Z-table from a reorganization eight years ago, filled once, empty ever since), and tables of mixed use (two active fields, twelve dead-maintained ones, three "unclear").
The agent (Claude, accessed via Azure OpenAI Switzerland for Swiss FADP data residency) processes the inventory in one reconciliation run: per table it parses the schema, combines write statistics from the HANA DB with ABAP code references from the source repository, checks BI extractors and IDoc mappings, and classifies per field. For roughly 70% of the unclear fields the classification is unambiguous — either clearly active with a mapping proposal, or clearly unused with a deprecate proposal. The remaining 30% land in the review queue with full reasoning exposed. The migration experts work the "unclear" list and the "deprecate" proposals in regulated areas with the respective business owners — a typical conversation finding: "ah right, that field was meant for a project eight years ago that never happened — it can go."
Typical effect: clear recommendations per field in hours instead of weeks of Z-table archaeology — directional, not a published benchmark, and strongly dependent on the custom share and repository quality. The leverage doesn't sit in any individual field but in the separation: the agent takes the long tail of structurally clearly classifiable fields, the migration experts review only the "unclear" cases and the "deprecate" proposals in high-risk areas. As a by-product, a complete audit trail emerges per field: which signals the agent saw, which classification it derived, which action it proposed, which human decision followed. The trail is compatible with GoBD documentation requirements and Swiss FADP traceability and forms a clean basis for the later migration audit & sign-off — it isn't reconstructed after the fact but falls out of the reconciliation itself. Preconditions for the effect: an accessible source repository and read access to DB statistics; without these sources the classification thins out.
Several signals combined: (a) write-access statistics from DB history on HANA or Oracle, (b) read references from static ABAP code analysis across reports, smart forms, Adobe forms, and function modules, (c) BI/BW extractor usage, (d) sample data distribution (fields that are 99% empty or carry a constant default are a strong signal for "unused"). Fields with no signals at all land as unused, proposal deprecate. Fields with contradictory signals — for example, an ABAP reference from an old report but no write access in five years — land as unclear and go straight to the migration expert. A single signal is never enough for a "deprecate" recommendation; the classification emerges from the combination.
The agent creates an audit entry: what it saw, why it doesn't commit, which hypotheses it holds. The decision is made by a human. Standard pattern: migration experts work the "unclear" list in batches with the respective business-area owners. A frequent finding in conversation — the field was meant for a project eight years ago that never went live; it can go. Or the reverse: the field is only filled once a year during year-end close, falls through the statistics, but absolutely needs to come along. The agent doesn't recognize these cases from the signals alone. It only recognizes that it doesn't recognize them — and hands off cleanly to a human. This explicit "unclear" category is the point where the agent and the business work together productively.
Source side: SAP ECC 6.0 and newer, including S/4HANA on-premises and S/4HANA Cloud. The metadata parser accesses DD02L/DD03L for table structures and field definitions, static ABAP analysis runs over the source repository for code references, and DB statistics are read from Oracle or HANA depending on the platform. For Z-tables with external-system interfaces — typically IDoc mappings, custom RFC connections, or external reports via Open Data Protocol — scope is explicitly widened. This is where classical discovery comes in: external consumers need to be catalogued manually once; the agent does that quickly up-front and delivers a list of fields where external usage must still be checked.
This use case sits in the Agent Systems & Workflows practice and is the natural upstream step for the agentic SAP migration as well as the later migration audit.
Practice: how agents are built, operated, and made audit-ready in production environments — patterns, guardrails, platform choice.
Prepare migration objects per backlog entry — parse schema, detect Z-tables, propose mappings, escalate cleanly.
Classify data quality defects in the target system, schema-aware fixes with a confidence gate and an audit entry per patch.
Audit-ready diff reports with discrepancy classification and sign-off packages for cut-over.
Z-table reconciliation pays off when the custom share is substantial. For SAP systems close to standard, classical cleanup is often faster. In a non-binding 30-minute discovery call we'll talk honestly about whether your inventory is a candidate.
Book a discovery call