Now accepting guest editorial from SAP, Oracle, Workday and ServiceNow practitioners.Pitch a guide
The Sign-Off Table

Lesson 1 of 5

Inventory and usage

10 min

Listen to this lesson

0:00 / 21:07

Contoso Motor Co. is live on SAP S/4HANA Private Edition. The conversion did what conversions do: it carried across the custom code that survived the pre-conversion cleanup and adapted what the simplifications forced, nothing more. Kenji now owns an estate of about 7,500 custom objects in CMD, grouped into 240 extensions, of which only 18 are at clean core level A and 37 are at level D. Grace's board has approved a multi-year modernization. The first question is not "what do we rewrite?" but "what do we actually have, and what is actually used?"

Build an inventory you can act on

A list of object names is not an inventory. For modernization you need, per extension (a set of objects delivering one capability): the objects and packages, the business process and owner, the entry points (transactions, Fiori apps, jobs, RFC and API calls, enhancements), the clean core level and its cause, known defects, and the tests that exist today. Most of this can be generated; the business mapping needs people.

AttributeSourceWhy it matters
Objects and packagesRepository, package hierarchyScope of each change and transport
Entry pointsTransactions, app catalog, job definitions, RFC and enhancement listsWhere usage data and tests must look
UsageUsage data collected over a long periodRetire what nobody uses
Clean core level and causeATC clean core checksUpgrade risk and remediation path
Business owner and processProcess owners such as Dan and MariaWho decides and who signs off
Existing testsABAP Unit, regression test cases in SAP Cloud ALMHow safe a change is today

The minimum inventory per extension for a modernization program.

An inventory you can act on is built per extension and links objects, entry points, usage, owner, level and existing tests.
The Sign-Off Table · thesignofftable.com/academy/sap-abp-401

Usage data: the cheapest modernization tool

Legacy estates carry a lot of dead code: reports written for a one-off project, interfaces to systems switched off years ago, copies of standard programs nobody remembers. SAP's conversion guidance notes that the Custom Code Migration app can identify unused custom code and remove it during conversion with deletion transports, reducing adaptation effort. Contoso did run that cleanup before the conversion: SCMON and SUSG collected usage in EP1 for 13 months, and over a third (about 4,300) of its roughly 11,800 Z objects were removed, leaving 7,500 in scope. But a conversion team under deadline deletes only what it is sure of, so some dead code always slips through. Keep the analysis going now that the system is live: collect usage in production with SAP's ABAP call monitor (transaction SCMON) over a long period, aggregate it, and compare it with the inventory. Check the setup and retention options for your release with Sam's Basis team before switching it on.

  1. CollectSwitch on usage collection in CMP; keep at least 13 months so year-end and audit runs are included
  2. AggregateCombine usage by object and entry point; include RFC and background job calls
  3. Join with inventoryMap usage to extensions, levels and owners
  4. ClassifyUsed often, used rarely, not used
  5. Confirm with ownersFor each unused extension, the owner confirms or names a rare legitimate use
  6. RetireDelete in a tracked transport after a quiet period, with a way back
From usage collection to retirement. The quiet period and owner confirmation keep retirement safe.
The Sign-Off Table · thesignofftable.com/academy/sap-abp-401

Contoso's second usage review, run with SUSG in CMP after go-live, was sobering and encouraging at once. Of the 7,500 custom objects that survived the cleanup, about 960 were still never called. They mapped to 52 whole extensions with no usage at all, plus dead objects scattered inside used extensions. After owner review, 47 extensions were confirmed for retirement; five turned out to be rare-but-critical and stayed. Among the 47 were 9 of the 37 level D extensions: the cheapest clean core improvement the program will ever make.

Even after the pre-conversion cleanup, the post-go-live usage review found 47 extensions to retire, 9 of them at level D.
The Sign-Off Table · thesignofftable.com/academy/sap-abp-401

Usage and criticality together

RetireUnused and not critical: delete after owner confirmation and a quiet period
Simplify or replaceUsed but not critical: consider standard apps or simpler solutions
Verify the rare useLittle usage but critical (year-end, audit, fallback): keep, document, test before each change
Modernize with careHeavily used and critical: the core of the program; highest test investment
Usage and criticality decide where an extension goes next.
The Sign-Off Table · thesignofftable.com/academy/sap-abp-401

What would you do?

After six months of usage collection, a list shows 140 extensions with no calls. Grace wants them deleted next month to show progress. What should Kenji propose?

Key points
  • Inventory per extension: objects, entry points, usage, level and cause, owner, existing tests.
  • Collect usage in production over at least a full year, including RFC and job calls.
  • Rare is not unused: confirm with owners before retiring.
  • Retiring dead code is the cheapest clean core and upgrade improvement available.

Check your understanding · not graded

Lesson check

  1. 1. Why collect usage data for at least a full year?

  2. 2. What does SAP's conversion guidance say the Custom Code Migration app can do with unused code?

  3. 3. An extension has almost no usage but supports the annual fixed asset reconciliation. Where does it belong?

  4. 4. Which inventory attribute tells you how safe a change is today?