SAP S/4HANA Migration: How to Identify Custom Code That Needs Attention

Many businesses have spent years adapting SAP ECC to match their daily operations. They have built custom reports, automated approval processes, developed special pricing rules, and connected SAP with other business applications. These changes may support important business requirements, but they can also create challenges when moving to SAP S/4HANA.

One of the most important tasks before migration is identifying which custom developments still serve a purpose, which require changes, and which can be removed.

A structured S/4HANA custom code migration process helps organizations address compatibility issues before they affect project timelines, testing, or business operations. It also gives IT teams an opportunity to reduce unnecessary code and simplify the target system.

The challenge is that not every custom program needs to be rewritten. Some developments may continue to work with little or no modification, while others may depend on SAP functions or data structures that have changed.

This guide explains how to identify custom code that needs attention, which SAP tools can help, how to prioritize remediation, and what businesses should include in their migration plan.

What Is Custom Code in SAP?

Custom code refers to developments created to meet business requirements beyond the standard capabilities of an SAP system.

In SAP ECC, these developments are commonly written in ABAP and may include custom reports, programs, enhancements, user exits, forms, interfaces, and background jobs.

For example, a manufacturing company may use a custom report to calculate production costs. A distributor may have developed a special pricing process. A finance team may depend on a custom program to prepare management reports.

Over time, organizations can accumulate hundreds or thousands of custom objects. Some remain essential, while others become obsolete as business processes change.

When preparing for SAP S/4HANA, businesses need to understand which objects are used, what they depend on, and whether they remain compatible with the target system.

Why Does Custom Code Matter During SAP S/4HANA Migration?

SAP S/4HANA uses a different data model and includes changes to application functionality compared with SAP ECC. As a result, certain custom programs may rely on tables, transactions, functions, or processes that have changed or are no longer supported in the same way.

Custom code can affect migration in several ways.

Compatibility problems

A custom program may reference a data structure or application function that has changed in SAP S/4HANA. The program may need to be adapted before it can operate correctly.

Performance concerns

Some older developments use database access patterns that are inefficient in the target environment. These programs may need to be reviewed and tested for performance.

Higher testing effort

Every business critical custom development introduces requirements for validation. Teams must confirm that calculations, reports, interfaces, and automated processes still produce the expected results.

Increased maintenance effort

Keeping unnecessary custom code can make future maintenance more difficult. Reducing unused developments can simplify testing and ongoing support.

Business disruption risks

If a critical custom program fails after go live, it may affect invoicing, procurement, reporting, production, or other essential operations.

The goal is not to remove every customization. It is to retain the code that supports genuine business needs and address the developments that create technical or operational risk.

Step 1: Build a Complete Inventory of Custom Code

Before checking compatibility, establish what exists in the current SAP ECC environment.

An incomplete inventory can cause important programs to be missed during migration planning.

Start by collecting information about:

• Custom ABAP programs and reports

• Enhancements, user exits, and BAdIs

• Custom function modules and classes

• SAPscript forms, Smart Forms, and Adobe Forms

• Custom tables and data dictionary objects

• Interfaces and integration programs

• Background jobs and scheduled reports

• Custom workflows and related developments

• Modifications to SAP standard objects

Use the SAP development repository and relevant system analysis tools to build the inventory. Where available, include object descriptions, technical owners, creation dates, dependencies, and usage information.

The inventory should cover production and other relevant system environments. Objects found in development systems may not all be active in production, so the team must confirm which developments are actually required.

Practical tip: Assign a business owner to each important custom object or group of objects. Technical teams can explain how the code works, but business owners can confirm whether it still supports a real business requirement.

Step 2: Identify Which Custom Code Is Actually Used

Not all custom code deserves the same level of attention.

A program that runs every day to support financial closing should receive a different priority from an old report that has not been used for years.

Review usage information to identify active, infrequently used, and apparently unused developments.

Depending on the SAP release and available tools, usage data may be collected through workload analysis, transaction usage statistics, custom code analysis tools, or other monitoring facilities.

However, absence of recent usage does not automatically mean that a program can be deleted. Some reports run only during annual audits, year end closing, tax submissions, or other infrequent business events.

Before retiring any object, check its purpose with the relevant business team and review its dependencies.

Classify custom developments into three groups:

1. Required: Supports an active and important business process.

2. Needs review: Usage or business value is unclear.

3. Potentially obsolete: Appears unused and has no confirmed business requirement.

Only retire code after confirming that it is no longer needed and that its removal will not affect another program, interface, or business process.

Step 3: Use SAP Tools to Find Compatibility Issues

A reliable S/4HANA custom code migration strategy uses available SAP analysis tools to identify potential problems early.

SAP Readiness Check

SAP Readiness Check for SAP S/4HANA can provide an overview of relevant system conversion considerations, including findings related to custom code where supported by the selected assessment.

It helps teams identify areas that require further investigation before committing to a migration plan.

The output should be treated as an assessment input rather than a guarantee that every custom development has been fully validated.

ABAP Test Cockpit

The ABAP Test Cockpit, commonly called ATC, can run static checks on ABAP developments. Depending on the configuration and available checks, it can identify syntax issues, problematic programming patterns, and potential compatibility concerns.

For SAP S/4HANA preparation, teams can use an appropriate central ATC setup and relevant SAP checks to examine custom code against the target environment.

Review the findings to determine which issues require code changes, which need additional analysis, and which can be addressed through an approved exemption.

Custom Code Migration tools

SAP provides tools and guidance for custom code analysis and adaptation. The available capabilities depend on the SAP release, system setup, and selected migration approach.

These tools can help identify references to affected objects and support the process of adapting custom developments.

The team should confirm that its analysis environment and checks are appropriate for the intended SAP S/4HANA target release.

Step 4: Review Simplification Items and Changed Data Structures

SAP S/4HANA introduces changes to applications and data structures that can affect existing custom developments.

For example, some traditional SAP ECC data access patterns may no longer be appropriate because of changes to underlying data models or application functionality.

A custom program that reads or updates affected tables directly may require particular attention.

The team should review the relevant SAP simplification information for the target release and examine custom objects that reference affected tables, transactions, function modules, or application components.

This review helps distinguish general code quality findings from issues specifically related to the transition to SAP S/4HANA.

Do not assume that every reference to an older table is automatically a migration blocker. Some tables or compatibility views may remain available, depending on the object and target release. Confirm the actual technical and functional implications before changing the code.

Step 5: Check Dependencies Between Custom Objects

Custom code rarely operates in isolation.

A custom report may call a function module, read a custom table, trigger another program, or send data to an external application. Changing one object can affect several related developments.

Dependency analysis helps teams understand these relationships before making changes.

For each important custom object, identify:

• Programs and functions it calls

• Tables and data structures it uses

• Interfaces that exchange information with it

• Background jobs that depend on it

• Business transactions affected by its output

• Other custom developments that use its results

Pay particular attention to custom code that interacts directly with SAP standard tables or internal application functions.

When a dependency is affected by the target SAP S/4HANA release, assess the complete process rather than correcting one isolated object.

Step 6: Prioritize Custom Code Remediation

Once the inventory and compatibility analysis are complete, create a remediation plan.

Not every finding has the same business impact. A minor issue in a rarely used report should not necessarily receive priority over a compatibility problem affecting invoicing or financial postings.

A practical prioritization model considers three factors:

Business criticality: How important is the development to daily operations, financial accuracy, compliance, or customer service?

Technical risk: Does the code rely on changed data structures, unsupported functions, or problematic programming patterns?

Usage and dependency: How frequently is it used, and how many other processes depend on it?

Use these factors to assign each object a priority.

This model is a planning aid, not an official SAP classification. Project teams should define their own criteria based on business risk and technical findings.

Step 7: Decide Whether to Fix, Replace, or Retire Each Object

After prioritization, decide how each custom development should be handled.

Fix existing code

If the development still serves an important business purpose and can be adapted efficiently, correcting the existing code may be the most practical option.

Replace with standard SAP functionality

Some custom developments duplicate capabilities already available in the target SAP S/4HANA environment. Replacing them with standard functionality may reduce future maintenance requirements.

However, confirm that the standard feature meets the business requirement before retiring the custom solution.

Redesign the development

Some programs may need a broader redesign because of changed processes, data structures, performance requirements, or integration methods.

Retire unnecessary code

If a development has no continuing business purpose, removing it can reduce the amount of code that needs to be maintained and tested.

Every decision should be documented with a business owner, technical rationale, estimated effort, and approval where required.

Step 8: Test Custom Code in the Target Environment

Static analysis identifies potential problems, but it does not prove that a program works correctly in real business conditions.

Testing should confirm both technical compatibility and business results.

For critical custom developments, plan:

• Unit testing for individual programs and functions

• Integration testing across connected systems

• Regression testing for existing business processes

• Performance testing where response time or processing volume matters

• User acceptance testing with relevant business teams

For example, if a custom program calculates invoice values, confirm that the results are correct for relevant tax scenarios, discounts, currencies, and business conditions.

Compare results with the existing system where appropriate and investigate any differences.

Repeat testing after code changes and include the final approved versions in cutover preparation. Maintain clear records of defects, fixes, test evidence, and business approvals.

Common Mistakes to Avoid During Custom Code Migration

Businesses can reduce migration risk by avoiding these common mistakes.

Assuming every custom object must be rewritten: Many developments may remain suitable or require only limited changes. Assess each object individually.

Deleting code based only on low usage: Rarely used programs may support annual or legally important activities. Confirm their purpose before retirement.

Ignoring business owners: Technical findings alone cannot determine whether a development is still necessary.

Starting compatibility checks too late: Early analysis provides more time to estimate remediation effort and address major issues.

Fixing code without regression testing: A change that resolves one technical issue can still affect existing business functionality.

Ignoring external interfaces: Custom code may exchange data with applications outside SAP. Test the full process rather than only the ABAP object.

Custom Code Migration Readiness Checklist

Before moving into the main implementation phase, confirm that your team has completed the following activities.

• Created an inventory of relevant custom developments.

• Reviewed usage information and confirmed business ownership.

• Identified potentially obsolete objects.

• Run suitable SAP compatibility and static code checks.

• Reviewed relevant simplification items and changed data structures.

• Mapped important dependencies and interfaces.

• Prioritized findings by business impact and technical risk.

• Decided which objects to fix, replace, redesign, or retire.

• Estimated remediation effort and assigned responsibilities.

• Prepared testing, regression validation, and approval procedures.

If several items remain incomplete, address them before finalizing the migration schedule and implementation budget.

How VC ERP Consulting Can Help

Custom code assessment requires a combination of SAP technical knowledge and an understanding of business operations.

VC ERP Consulting can help organizations review their existing SAP environment, identify migration considerations, plan code remediation, and prepare for SAP S/4HANA implementation.

Learn more about SAP ECC to SAP S/4HANA migration services to understand how migration planning can support your business requirements.

You can also review the company’s SAP S/4HANA migration FAQs for answers to common migration questions.

Conclusion

Identifying custom code that needs attention is an essential part of preparing for SAP S/4HANA migration. A complete inventory, usage analysis, SAP compatibility checks, dependency review, and structured testing plan help businesses identify risks before they affect implementation.

The objective is not to preserve every old development or rewrite everything from scratch. It is to retain valuable business functionality, correct incompatible code, replace unnecessary custom solutions where suitable, and remove developments that no longer serve a purpose.

VC ERP Consulting can help your team assess its current SAP ECC landscape and plan the next steps toward SAP S/4HANA.

Ready to assess your custom code before migration?

Contact VC ERP Consulting to discuss your system, technical requirements, and migration goals.

• Website: https://www.vc-erp.com/contact-us.html

• Email: sales@vc-erp.com

• Phone: +91 99789 60138

Start your migration planning with a clear view of your custom code so your team can make informed decisions about effort, risk, and project priorities.