The Question
SAP landscapes accumulate technical debris over time. Custom tables are created during projects, experiments, integrations, or hurried workarounds, and many of them quietly remain long after the original purpose has vanished. Years later, when organizations begin preparing for an S/4HANA conversion, the uncomfortable question appears. Which of these custom tables are actually in use, and which ones are empty artefacts that survived simply because nobody bothered to check?
The question sounds technical, but it reflects a deeper governance issue. Enterprise systems rarely become messy through a single catastrophic decision. They become messy through thousands of small tolerances that nobody revisits.
The Practical Problem
One useful step during early S/4HANA preparation is identifying unused custom tables. These objects typically begin with prefixes such as Z or Y and often belong to specific development classes associated with modules. Over the years they may accumulate quietly, especially when projects end abruptly or when enhancements are replaced by newer approaches.
The ABAP utility shown in the example addresses this exact problem. It scans the data dictionary for active transparent tables, filters them by custom prefixes, checks row counts dynamically, and identifies tables that currently contain no records. The output can also be filtered by development class, which makes module-level analysis possible.
What The Program Actually Does
The logic behind the program is deliberately simple. It reads metadata from dictionary tables such as DD02L and DD09L to identify candidate tables. For each table it executes a dynamic SQL statement that counts the number of stored records. If the result is zero, and if the development class matches the module filter specified by the user, the table is added to the final output list.
The report then displays the results through an ALV grid and can optionally send the list through email. In other words, it converts an otherwise vague suspicion about unused objects into a concrete list that teams can evaluate.
Why Empty Tables Matter
An empty custom table may appear harmless. It contains no business data, consumes little storage, and rarely interferes with daily operations. The difficulty is that technical objects do not disappear simply because nobody uses them. They continue to exist in the dictionary, in transports, in development documentation, and sometimes inside forgotten pieces of custom code.
During S/4HANA preparation this clutter becomes particularly inconvenient. Each object may need to be evaluated for compatibility, relevance, or removal. A landscape with hundreds of abandoned artefacts inflates the perceived complexity of the system and complicates rational cleanup.
The Module Perspective
Filtering results by development class is especially useful in large ECC environments. Custom tables often belong to specific module packages, such as sales, finance, manufacturing, or procurement. When empty tables are grouped by module ownership, the investigation becomes much easier. Teams can review their own objects and determine whether they represent dormant experiments, obsolete solutions, or structures that were never used in the first place.
This approach also reduces the tendency for responsibility to float ambiguously between teams.
A Word Of Caution
An empty table does not automatically mean the object should be deleted. Some tables are designed for occasional runtime use or seasonal activity. Others may have been intentionally cleared through archiving processes. The report should therefore be treated as a discovery tool rather than an automated cleanup script.
Each object still deserves a brief investigation before any structural changes are made.
Why Phase Zero Matters
Running utilities like this during phase zero of an S/4HANA conversion creates significant practical value. It reveals unused structures early, encourages technical housekeeping, and reduces the volume of objects that later remediation phases must analyse. More importantly, it introduces a habit that many organizations lack. Evidence before assumption.
Large ERP systems age better when teams occasionally pause to ask which parts of the landscape are still alive.
The Larger Lesson
Technical debt rarely arrives dramatically. It accumulates quietly in small objects, forgotten tables, unused fields, and abandoned enhancements. None of them appear alarming individually. Together they create the illusion that the system is larger and more complicated than it actually needs to be.
A simple diagnostic program cannot fix governance by itself. It can, however, expose the places where governance quietly disappeared.
