Lesson 1 of 5
Scoping
14 min
Listen to this lesson
A system conversion keeps custom code. That is one of its attractions and one of its biggest costs: every custom program, enhancement and modification that touches a simplified part of SAP S/4HANA must be found, adapted and tested. SAP's conversion guide calls the custom code checks the most important preparation for ABAP custom code and recommends combining the project with housekeeping, in particular removing code that is no longer used. The cheapest object to adapt is the one you delete.
The process in four steps
- ScopeCollect usage data; decide what is in scope; retire unused code
- AnalyzeCheck the scoped code against the SAP S/4HANA simplifications with remote ATC
- AdaptSPDD and SPAU for modifications; fix findings, using quick fixes where available
- TestUnit tests, a clean ATC re-run and functional tests of the processes the code serves
Collect usage data early
Scoping needs evidence of what runs in production. SAP provides the ABAP Call Monitor (transaction SCMON) to record which custom objects are called in a productive system, and transaction SUSG to aggregate that data into a compact usage set you can export. Usage data collected earlier in SAP Solution Manager (for example usage procedure logging) can also be used. Start collecting in production as early as possible and long enough to cover the whole business year: a program that runs only at year-end looks unused in a three-month sample.
Step by step: usage data in EP1
- Sam's Basis team checks the SAP Notes that SCMON and SUSG need on EP1's SAP_BASIS level. The Custom Code Migration Guide lists them; verify for your release.
- In
SCMON, activate monitoring for customer objects (the Z and Y namespaces and any registered customer namespace) and let it run without an end date. It records each called processing unit, such as a program, function module or class method, and is designed to run in production. - In
SUSG, activate aggregation so the SCMON data is condensed into long-term usage data that you can export as one snapshot. - Each quarter, export a snapshot and sanity-check it: do quarter-end jobs, interface programs and known year-end reports show up? If not, find out why before you trust the zeros.
- At the scoping decision, export the final snapshot and load it into the Custom Code Migration app (lesson 3).
- Keep SCMON running after the decision. Code that is first called later goes back into scope before the deletion transport is built.
What usage data cannot see. SCMON records code that executes. Dictionary objects such as tables, structures and data elements are never "called", so their scope follows the code that uses them: a table read by an in-scope program stays in scope even with zero calls of its own. Run a where-used check before you retire any non-executable object. Two more blind spots need a human: interfaces and programs that go live after the sample started, and emergency tools kept for rare events such as a data correction or a period reopen. List them and let the owners decide.
Decide what is in scope
| Category | Typical evidence | Decision |
|---|---|---|
| Used and still needed | Called in production; owner confirms the business need | In scope: analyze, adapt, test |
| Unused | No calls across a full year of usage data | Retire: remove in the conversion, keep a backup |
| Replaced by standard | A standard app or function now does the job | Back to standard: plan the switch and retire the code |
| Used but complex and costly | Many findings, heavy modification of SAP objects | Reevaluate: redesign, or move side-by-side, or keep and adapt |
| Used rarely by few people | A handful of calls a year | Ask the owner; often retire with a manual workaround |
Scoping decisions. Every retirement needs an owner's agreement, not just a zero in the usage data.
SAP's Custom Code Migration app supports this directly: you upload usage data, define the migration scope from it, adjust it by hand, and save the scope. Code outside the scope can go into a deletion transport, which the Software Update Manager can apply during the conversion so unused code never reaches SAP S/4HANA; SAP also describes backing the removed code up with gCTS first. Lesson 3 covers the app.
| Object (illustrative) | Usage, 12 months | Agreed with | Decision and reason |
|---|---|---|---|
ZFI_WARRANTY_ACCRUAL | 1 run (December) | Dan (finance) | Keep and adapt: the annual accrual, visible only because the sample covered December |
ZSD_PRICE_LIST_OLD | 0 | Maria (O2C key user) | Retire: replaced by the standard price list output years ago; backup kept |
ZMM_OPEN_PO_LIST | 212 runs | Omar (buyer) | Back to standard: the Monitor Purchase Order Items app covers the list |
| Core return agreement table | Not applicable (a table) | Maria (O2C key user) | Keep: read by in-scope core return programs; carried over by the conversion |
ZPP_BOM_MASS_FIX | 0 | Kenji (ABAP lead) | Retire: a one-off data correction; backup kept in gCTS |
An excerpt from Contoso's scoping decision log. Every row names who agreed and why.
At Contoso, Kenji's team found about 11,800 custom objects in the Z namespace. Thirteen months of usage data showed roughly 40% never called. After owner reviews, 4,300 objects went into the deletion transport. That cut the number of objects to analyze, adapt and test by more than a third before a single finding was opened. Testing benefits most: every retired object is one Priya's team never has to regression test, in this conversion or in any upgrade after it.
What would you do?
The usage data shows that a custom pricing report has not been called in twelve months. Maria says sales used it 'once, years ago'. Kenji wants to delete it. What should the scoping decision be?
- Delete before you adapt: unused code is the cheapest code to migrate.
- Collect usage with SCMON and aggregate with SUSG in production, covering a full business year.
- Scope decisions: adapt, retire, back to standard, reevaluate; each retirement needs an owner.
- Unused code can be removed during the conversion through SUM, with a gCTS backup.
- Tables and other non-executable objects are never called: their scope follows the code that uses them.
Check your understanding · not graded
Lesson check
1. Which transaction records calls to custom objects in production?
2. Why should usage data cover a full business year?
3. What should accompany retiring an unused custom object?
4. How can unused code be kept out of the converted system?
5. A custom table has no calls in the usage data, but an in-scope program reads it. What is the scoping decision?