Built from the custom object list and a twelve-month usage log: 2,400 objects, 2,886,517 lines.
815 objects have never been executed, 112 are modified standard, and 61% of the estate is actually in use.
| Type | Objects | Never used | Modified | Lines |
|---|---|---|---|---|
| REPORT | 900 | 330 | 48 | 1,079,094 |
| CLASS | 450 | 152 | 26 | 558,724 |
| FUNCTION | 300 | 106 | 8 | 348,484 |
| TABLE | 220 | 85 | 9 | 258,670 |
| FORM | 200 | 69 | 11 | 222,499 |
| ENHANCEMENT | 180 | 64 | 5 | 226,651 |
| INTERFACE | 150 | 54 | 5 | 192,395 |
| Package | Objects |
|---|---|
| ZSD | 332 |
| ZMM | 316 |
| ZFI | 300 |
| ZLEGACY | 297 |
| ZWM | 294 |
| ZPP | 290 |
| ZCUSTOM | 287 |
| ZHR | 284 |
815 of 2400 objects (33%, 962,650 lines) have zero executions. Every one of them is migration scope you are about to pay for and do not need.
Do this: Retire before the migration, not during it: deactivate, monitor for a quarter, then delete. It is the cheapest scope reduction available and it makes the business case smaller.
112 objects carry a modification flag. These are the expensive ones: each has to be re-implemented as a BAdI, an enhancement, or a clean extension in S/4, and each needs a functional owner to say what it was for.
Do this: Inventory them with their business reason first. A modification nobody can justify is a deletion, not a migration item.
150 interface objects. In S/4 these move to APIs, CPI or event-driven integration, and the target is a design decision, not a rewrite.
Do this: Group by partner and protocol; one modern integration can often replace several IDoc or file drops.
The busiest custom objects are REP_0621 (89,963 runs), FOR_0047 (89,893 runs), FOR_0141 (89,873 runs), CLA_0048 (89,826 runs), TAB_0190 (89,826 runs).
Do this: These are the ones that must be regression-tested hardest; everything else is a volume problem.