What Custom Code Should Survive an S/4HANA Migration?

What should be true before custom code moves to S/4HANA?

Custom SAP code should move to S/4HANA only when production evidence shows that people still use it, a business owner accepts its outcome, standard software cannot replace it, and testing proves the chosen treatment. Everything else should be retired, replaced, redesigned, or isolated before it becomes part of the new system.

Key takeaways

• Production usage evidence should come before technical adaptation work.
• Every custom object needs a named business owner and one documented disposition.
• Standard S/4HANA capability should replace custom code when it meets the approved business need.
• Personal information should not be copied forward without a valid purpose and retention basis.

SAP Learning's current custom-code guidance, retrieved in August 2026, says teams may collect production usage with either Usage and Procedure Logging or ABAP Call Monitor, but discourages running both at once. SAP recommends a collection window of 6–18 months and says it should include at least one year-end close. Those are three concrete planning facts: two available tools, one selected tool, and a window long enough to observe annual work.

“Actual usage of the extension by end users is the determining factor here.”

Usage is necessary but not sufficient. An object can run every day and still duplicate a standard process, produce an output nobody owns, or carry a control that must be redesigned. SAP's Getting Started With SAP S/4HANA 2025, version 2.0 dated February 25, 2026, tells conversion teams to run custom-code worklists early so required adaptations become visible. SAP's maintenance announcement dated February 4, 2020 sets mainstream maintenance for Business Suite 7 core applications through the end of 2027 and optional extended maintenance through the end of 2030. Those dates create urgency, not permission to carry every old object forward.

How should each custom object be classified?

Each custom object should end with one of four dispositions: retire, replace, adapt, or move outside the core. The enterprise-systems owner should require evidence for the disposition rather than treating “it still compiles” as proof of business value. This Appcentric decision card is editorial guidance, not an SAP-prescribed template.

Run the decision in a fixed order:

1. Collect use evidence. Choose one production usage tool, cover normal and annual cycles, and aggregate the result before it expires.
2. Confirm the business outcome. Name the user, process, control, output, frequency, and accountable owner for every object that appears active.
3. Test standard capability. Ask the process owner to verify whether S/4HANA now meets the need without the customization.
4. Choose one disposition. Record retirement, replacement, adaptation, or side-by-side treatment with its owner and acceptance test.
5. Prove removal and restoration. SAP Learning recommends a backup and restoration procedure, ABAP checks, and testing before restored code returns to production.

SAP Learning identifies two analysis options after usage collection: the Custom Code Migration app and the ABAP Test Cockpit. The app can use collected statistics to identify unused extensions. This technical analysis narrows the worklist; it does not replace the business owner's decision about the process, control, or output.

When should an extension move outside the SAP core?

An extension should move outside the SAP core when the requirement remains valid, standard S/4HANA does not meet it, and a side-by-side design has a supported interface, named owner, monitoring, recovery, and data controls. Moving code without those conditions changes its location but preserves the same operating debt. That test belongs before design approval.

The SAP Business Technology Platform service is the relevant Appcentric route for application development, integration, data management, analytics, and extensions around SAP. The Philippine guide to SAP BTP explains those capability groups, while the earlier article on building custom applications on SAP BTP covers the development use case. Neither link proves that a particular custom object belongs on BTP. The disposition card and technical assessment must establish that.

Philippine privacy duties also belong in the decision when an object handles personal information. Section 11 of the Data Privacy Act of 2012 requires transparency, legitimate purpose, and proportionality. It also says personal information must be adequate and not excessive, and retained only as long as necessary for its purpose, legal claims, legitimate business purposes, or another legal basis. A copied extract, shadow table, interface payload, or local report should therefore have a documented purpose, access rule, retention period, and deletion or archival treatment before migration.

For programs considering private-cloud S/4HANA, the RISE with SAP service is the matching Appcentric route. Platform choice and custom-code disposition remain separate decisions. A contract can define the target environment; it cannot prove which custom objects still deserve a place in it.

What do enterprise-systems leaders ask about custom code?

Enterprise-systems leaders usually need answers about deletion risk, evidence windows, BTP, ownership, and deadline pressure. Each answer should be tied to the current system and an accountable business decision.

Is custom code safe to delete when no usage appears?

No-usage evidence is a strong retirement signal, not automatic permission to delete. Confirm that the collection period covered annual work, obtain business-owner sign-off, preserve an approved backup, and test the process with the object removed. SAP Learning recommends checks and testing before any later restoration to production.

How long should SAP usage data be collected?

SAP Learning recommends 6–18 months and at least one year-end close as a general rule. The actual window should also cover local annual tasks, peak periods, tax work, and rarely used controls. Choose either UPL or SCMON in production; SAP discourages operating both tools at the same time.

Does moving an extension to SAP BTP mean it should survive?

No. BTP is a possible location, not business justification. The requirement still needs current use evidence, an accountable owner, no suitable standard replacement, a supported interface, monitoring, recovery, and a tested data treatment. An unowned side-by-side application is still an unowned dependency.

Who should approve a custom-code disposition?

The enterprise-systems leader should own the complete register, while the accountable process owner approves the business outcome and control treatment. Developers assess technical feasibility; privacy, security, finance, tax, and operations owners review objects within their remit. A technical migration team should not retire a business control alone.

Does the 2027 maintenance date require every object to move?

No. The date requires a decision for every object, not automatic migration. SAP's 2020 maintenance announcement states that Business Suite 7 core applications have mainstream maintenance through the end of 2027 and optional extended maintenance through the end of 2030.