Every custom object you carry into an S/4HANA conversion is an object somebody has to analyse, fix, test and support. The cheapest object to remediate is the one you never move. That is why SAP itself puts cleanup at the start of its custom code process, before the conversion run and before any remediation begins.
This guide explains how to do that cleanup in a sensible order: how to find out what is really used, how to decide what goes, how to remove it safely, and what to hand to the remediation team afterwards. It is written for SAP programme managers, technical leads and the partners who support them.
Why cleanup comes first
SAP describes custom code adaptation in two phases. The preparation phase happens before the conversion and covers scoping, cleanup and checks. The realization phase happens after the conversion and covers functional adaptation and performance tuning. SAP states that removing unused custom code before conversion significantly reduces the adaptation effort.
The logic is simple. Remediation effort grows with the number of objects in scope. Analysis, fixing, unit testing, integration testing and documentation all repeat for each object. Code that runs nowhere still costs all of that, and then keeps costing in support and in every future upgrade.
There is also a timing point that most programmes miss. SAP recommends collecting usage data for at least one year to get reliable results. If your conversion is planned for next year, usage collection has to start now, not when the project kicks off. We come back to this below.
What counts as clean-up
Cleanup is more than deleting old reports. In practice it covers four different kinds of work, and each has a different risk.
Retiring unused custom objects: programs, function modules, classes, enhancements, forms and tables that production does not run. This is the biggest and safest win once you have usage evidence.
Retiring duplicates and obsolete variants: the third copy of a pricing report, the program written for a plant that closed, the interface for a vendor you stopped using. Usage data helps, but a business owner usually has to confirm.
Resetting modifications to SAP standard: wherever a modification exists because of an old requirement or a bug that SAP has since fixed, returning to standard removes work from the upgrade adjustments.
Tidying what stays: obvious issues such as hard-coded values, dead branches and performance problems that you will touch anyway. Do this only on objects you have decided to keep.
The first two reduce scope. The third reduces upgrade effort. The fourth is optional and belongs inside remediation, not before it.
Step 1: Draw the boundary of your custom code
Start with an inventory. List everything that is yours: objects in the customer namespaces (usually Z and Y), customer enhancements and implicit and explicit enhancement implementations, modifications to SAP objects, custom tables and their data, and any code in add-on or partner namespaces that you maintain yourself.
Count the objects by type, by package or application area, and by age and last change. You do not need precision at this stage. You need a picture of where the volume sits and which areas are heavy: for example, a large estate of custom finance reports, or a thick layer of sales order enhancements.
Also write down what you do not control. Third-party add-ons and generated code may have their own vendor path to S/4HANA, and should be handled separately from your own code.
Step 2: Collect usage data from production
You cannot decide what is unused by asking people. Users forget the report they run once a quarter, and developers remember what they wrote, not what is still called. Evidence has to come from production.
The tools SAP provides
| Tool | What it records | Notes |
|---|---|---|
| ABAP Call Monitor (SCMON), with aggregation through SUSG | Which ABAP objects run in a productive system, how often, and the calling business process | SAP's recommended option. Included in AS ABAP 7.50; releases 7.00 and later can use it through the ST-PI add-on. |
| Usage Procedure Logging (UPL) | Usage counts, without the calling business process | Collected through SAP Solution Manager. SAP positions SCMON as its replacement. Existing UPL data can still be used. |
| SAP Solution Manager 7.2 (custom code lifecycle management) | Collects SCMON or UPL data across systems and supports decommissioning decisions | Useful when the same code runs in several connected systems. |
How long to collect
SAP recommends at least one year of usage data before the project starts. The reason is business cycles. Month-end, quarter-end, year-end, audit-season and annual campaign processes all call code that never appears in a two-week sample. Collect across at least one complete year-end if you can.
Rules worth knowing
Do not run UPL and SCMON in parallel, including when one is switched on from Solution Manager and the other locally.
Avoid switching on monitoring in systems that are already at maximum load, and use the record limit and scheduled deactivation options to keep data volumes under control.
SCMON reads and administration need specific authorisations (S_ADMI_FCD with the SCMD value to read and SCMA to administer), so involve security early.
Check every system that uses an object before retiring it. A function module that is quiet in the ERP production system may be called from another connected system.
Step 3: Decide what stays, goes or changes
With usage data in hand, triage every object. The aim is a decision for each one, owned by a named person, before any fixing starts. A workable decision table looks like this.
| Evidence | Decision | Who confirms |
|---|---|---|
| No calls in the full collection period, no known periodic use | Retire | Technical owner; business owner for anything finance, compliance or regulatory |
| Used, and SAP now ships equivalent standard functionality | Replace with standard, then retire | Functional consultant and process owner |
| Used rarely, business owner cannot justify it | Retire, with a short grace period | Business owner |
| Used regularly, no standard equivalent | Keep and remediate | Technical lead |
| Used heavily, expensive to fix, poor design | Rebuild with modern techniques (CDS, RAP) where it pays | Technical lead and architect |
| Modification of an SAP object | Review for reset to standard (Step 6) | Technical lead |
Be explicit about uncertainty. A short list of "unknown, to be investigated" objects is healthy. A long one means the usage collection period was too short.
SAP's Custom Code Migration app can help here. It takes usage data as input to set the initial scope, lets you adjust it manually, runs complexity analysis to find the biggest cost drivers, and is available on-premise from ABAP platform 1809 or on SAP BTP ABAP Environment.
Step 4: Run the S/4HANA checks on what is left
Once you know the scope, run the checks that tell you what each remaining object needs. SAP's approach uses the ABAP Test Cockpit (ATC) with the S/4HANA readiness checks, scanning custom code against the Simplification Database.
Run ATC remotely from one central check system so the whole landscape is analysed consistently. SAP names the S4HANA_READINESS_REMOTE variant on SAP_BASIS 7.52 or later for this.
Keep the Simplification Database current on the check system. SAP points to SAP Note 2241080 for the content and to transaction SYCM for installing it, and to SAP Note 2436688 for the ATC S/4HANA readiness checks.
Look at both categories of finding: S/4HANA simplification items (for example changed data models) and HANA-related findings (for example vendor-specific native SQL, SELECT statements that depend on an implicit order, and pool or cluster table access).
Run the checks on the retire list too. The results tell you which doomed objects would have been expensive, which is a useful number for explaining the value of cleanup to your sponsors.
Step 5: Retire code safely
Deleting code is easy. Deleting it safely is a small process of its own.
Back up first. SAP mentions gCTS as a way to keep a copy of unused custom code after conversion. Any version-controlled archive works. The point is that nothing is gone for good.
Deactivate before delete where you can. A short sunset period, with the object locked or disabled and monitored, catches the process nobody remembered.
Check other systems. Usage can come from several connected systems, so confirm that none calls the object.
Use the conversion tooling. The Custom Code Migration app can generate a transport request that excludes objects you do not want carried over, and SUM can then leave them behind. SAP also notes that the object catalogue and software component information must be correctly maintained (SAP Note 2318321).
Record the decision. Keep the retire list, the evidence and the approver for each object. If a question comes up after go-live, that record settles it.
Step 6: Reset modifications to standard
Modifications to SAP objects create work in every upgrade, through the adjustments in SPDD, SPAU and SPAU_ENH. SAP's advice is to reset as many as possible to standard.
Review each modification and ask three questions. Is the original requirement still alive? Does current standard functionality, or a supported enhancement spot, now meet it? Was the modification a workaround for a bug that SAP has fixed? Where the answer is no, no and yes, reset it. Where a real requirement remains, consider moving it to a supported enhancement technique, so the next upgrade does not repeat the work.
Step 7: Hand a clean backlog to remediation
At the end of cleanup you should have three lists: objects retired, objects to remediate, and objects to rebuild. The remediation list is now much shorter than the inventory you started with, and every item on it has a business owner.
Three things then make remediation more efficient.
Quick Fixes. ABAP Development Tools offers automated fixes for common cases, including material number field length extension and direct access to tables such as VBFA, VBUK, VBUP, KONV and BSEG. Many can be applied across a whole package at once.
Know the heavy simplification items. SAP's own guidance lists the items that affect most custom code, among them material number field length (SAP Note 2215424), the sales and distribution data model (2198647), the finance data model (1976487) and pricing and condition technique (2220005). Check whether your code touches them early.
Tune for HANA where it matters. After conversion, use SQL Monitor (SQLM) on production to find expensive or frequently executed statements and fix those first, using ABAP SQL, CDS or AMDP where pushing logic to the database pays. SAP quotes the SQL Monitor overhead as below 3 percent.
For more on that phase, see our page on custom code remediation.
When to start: a realistic timeline
Because SAP recommends at least a year of usage data, cleanup is the one part of a conversion that cannot be compressed once the project has started. Work backwards from your target go-live date.
| Phase | What happens |
|---|---|
| 12 months or more before the project | Switch on usage monitoring in production. Sort out authorisations, record limits and the deactivation date. Take the first inventory of custom objects. |
| Around 6 months before | Review interim usage data. Start the business-owner conversations on obviously obsolete areas. Install the Simplification Database content and run first ATC readiness checks, so you know how big the remediation problem is. |
| Project start | Freeze the usage data set. Complete the triage table and get approvals. Take backups and set the retire list in motion. |
| Early in the project | Retire approved objects, reset modifications to standard, and hand the cleaned remediation backlog to the engineers. |
If your project start is closer than twelve months, do not skip cleanup. Collect what you can, extend the "unknown" category honestly, and plan to keep monitoring through the project so that late evidence can still shrink the scope. A shorter data set means more objects need a business owner's decision, and a more cautious grace period before deletion.
Who needs to be involved
Cleanup fails when it is treated as a purely technical exercise. Four groups each hold a piece of the decision.
The technical lead owns the inventory, the usage data, the checks and the retirement mechanics.
Business process owners confirm that an apparently unused object really is unused, and approve retirement in their area. Finance, compliance and regulatory processes need particular care.
Security and Basis set up the monitoring authorisations and make sure collection does not disturb a heavily loaded system.
The programme manager keeps the retire list, the evidence and the approvals in one place, and makes sure cleanup finishes before remediation estimates are fixed.
A short weekly review of the triage table works better than a single large workshop. Objects move quickly through the table once owners are named.
Special cases that need extra care
Custom tables and data
A program may be unused while its table is still read by something else, or still holds data you must keep for legal retention. Before retiring a custom table, check where-used lists, check data volumes, and confirm retention rules with the business and with whoever owns archiving. Retiring the code is often safe while the table stays.
Interfaces and integrations
Interfaces are the classic source of surprise. An outbound interface that runs once a year, or an inbound one that a partner calls only on request, can look dead in a short sample. Include integration owners in the review, and check the middleware side as well as the SAP side.
Enhancements and exits
Enhancement implementations are called by SAP standard processes, so usage data records them as the standard program's activity rather than as a direct call. Review them by the process they belong to, and test the affected process after deactivation.
Reports used only by a few people
A report that one finance analyst runs at year-end is both easy to miss and expensive to lose. The usage data will show it if the collection window includes year-end, which is the practical reason to cover a full year. Where it does not, list the report as "unknown" and ask the owner.
Third-party and generated code
Code that came with an add-on, or was generated by a tool, may have its own supported path to S/4HANA. Check with the vendor before you decide to remediate it yourself or to retire it.
Common mistakes
Collecting usage for too short a period, and so retiring year-end code that is needed in December.
Fixing first and cleaning later, which pays to remediate code you then delete.
Deleting without a backup or an owner's sign-off.
Ignoring other connected systems that call the same objects.
Treating cleanup as a one-off. SAP describes the process as one to repeat regularly, before conversions and upgrades, as standard ABAP practice.
Leaving modifications alone because "they already work". Each one is a cost in every upgrade.
A cleanup checklist
Inventory of custom objects, modifications and enhancements, with counts by type and area
Usage monitoring (SCMON or UPL) active in production, with authorisations, record limit and end date set
At least one full year of data collected, including a year-end
Triage table complete, with a named approver for every retire decision
Other connected systems checked
Backup of retiring code taken and stored
ATC readiness checks run, with the Simplification Database up to date
Modifications reviewed for reset to standard
Retire, remediate and rebuild lists agreed with the business
Record of evidence and approvals kept
How Steady Rabbit helps
Our remediation team runs this cleanup as the first stage of a custom code engagement: usage analysis, triage with your business owners, safe retirement, and then fixing what remains. We work inside your programme or directly with you. If you are an SAP partner or system integrator, we can staff the workstream under your brand.
Talk to an ABAP remediation lead See custom code remediation For SAP partners
FAQs
How much custom code is typically unused?
It varies a great deal between companies, which is why we measure rather than guess. SAP says that much custom code never runs in production. Usage data from your own system is the only reliable answer.
How long should I collect usage data?
SAP recommends at least one year before the project starts, so that periodic processes such as year-end are captured.
What is the difference between SCMON and UPL?
Both record usage. SCMON also records the calling business process and is the tool SAP recommends. UPL records counts only. Do not run them in parallel.
Can I clean up after the conversion instead?
You can, but you will have paid to analyse and adapt code you later delete. Cleaning first is cheaper and shortens the project. It also gives you a smaller system to test.
Is it safe to delete code that production never calls?
It is safe when the collection period is long enough, other systems have been checked, a backup exists and a business owner has signed off. A short deactivation period before deletion adds a further safety net.
Do I need to clean up if I am moving to S/4HANA in stages?
Yes, and it pays off more, because the same cleaned codebase serves every stage. SAP also advises repeating the process before later upgrades.
Can Steady Rabbit do this for us?
Yes. See custom code remediation, or contact us through the form below.