The Custom Code Number Nobody Can Produce on Demand

The Custom Code Number Nobody Can Produce on Demand

Most SAP organizations cannot say, with confidence, how many custom objects are still actively running in production. They have spreadsheets. They have old migration assessments. They have tribal knowledge from consultants who left two years ago. What they rarely have is a verified, current count tied to actual execution data. That gap is not a minor administrative problem. Therefore, it sets the timeline, the budget, and the risk profile for every downstream decision in a SAP transformation. Reliable SAP Support becomes essential precisely because this gap exists and nobody wants to own it.

When a program director asks for the custom code inventory before scope is signed, the answer that comes back is almost always a number that cannot be defended. Functional leads cite counts from a discovery done eighteen months ago. Notably, the actual figure, once someone does the work properly, is usually larger than expected. It is also structured differently than anyone assumed.

Why the Inventory Number Is Almost Always Wrong: SAP Support

The gap between documented custom code and what is actually executing in production exists because most organizations never built a system to track it in real time. Custom objects accumulate over years of project work, break-fix development, and workarounds that were never retired. For instance, a typical enterprise SAP environment carries Z-objects and Y-objects added across multiple implementation waves. Often, different system integrators worked under different governance standards.

The documented inventory reflects what was captured at a point in time, usually during a prior migration or audit. However, production keeps moving. New objects get added. Old ones get deactivated but not deleted. Some run on schedules that only trigger quarterly. Others are called by interfaces that have since been replaced, yet the code itself still sits in the system, technically active.

What "Active" Actually Means in Production

Active does not mean recently executed. An object can be flagged as active in the repository while having zero runtime calls in the past two years. Conversely, a deprecated object can still be invoked by a batch job that nobody documented. This distinction matters enormously when you are trying to scope a migration or a platform shift.

Counting objects without tying them to actual usage data produces a number that is technically accurate and operationally misleading. According to SAP, organizations migrating to SAP S/4HANA commonly discover that 30 to 40 percent of their custom code has zero usage in the twelve months before migration. That figure varies by industry and system age, but the direction is consistent. Significantly, the real active footprint is smaller than the repository count. The high-risk active footprint is concentrated in a subset that requires the most attention.

The Governance Problem Behind the Count

Poor governance is the root cause, not poor record-keeping. When multiple system integrators work across different project waves, each team follows its own naming conventions and documentation standards. One team logs every Z-object in a central register. The next team does not. By the time the organization reaches its third or fourth major upgrade cycle, the registry is a patchwork of partial truths.

This is also why the SAP Support Portal, which provides access to SAP's own tooling for custom code analysis, is underused. Many organizations have the access. Few have a defined process for acting on what the tools surface. The portal's custom code analysis capabilities can identify unused objects. They flag compatibility issues with S/4HANA and highlight objects that require remediation. Nevertheless, running the tool once during a pre-project assessment and then filing the report is not the same as maintaining a living inventory.

How the Gap Surfaces Late and Why That Is Expensive

The inventory gap almost always surfaces during technical design, not during discovery. By that point, the program has a signed scope, a committed timeline, and a resource plan built on assumptions that are now wrong. Adding scope at that stage is not a planning adjustment. Consequently, it is a renegotiation, and it costs more than the original assessment would have.

The reason it surfaces late is structural. Discovery workshops focus on business process coverage. Technical leads are often brought in after the functional blueprint is underway. The SAP Service Desk and support teams who know the system best are rarely included in scoping conversations. They are viewed as operational, not strategic. Importantly, their knowledge of what actually breaks, what actually runs, and what nobody touches anymore is exactly the knowledge that would have prevented the scope gap. Broader industry analyses, such as the Winter 2026 global trade and economic outlook, also highlight how overlooked operational realities can drive unexpected costs and delays in large-scale technology transformations.

The Interface Map Problem

Custom code does not exist in isolation. Most of it connects to something: a middleware layer, a legacy system, a third-party application, or a reporting tool that the business built independently. When the inventory is wrong, the interface map is wrong too. And when the interface map is wrong, integration testing scope is wrong. That chain of errors compounds quickly.

A manufacturing company running a heavily customized SAP ECC environment might document 800 custom objects during discovery. When a technical team runs a proper usage analysis using SAP's own tooling, the real number could be closer to 1,200 objects. Of those, 400 have active interface dependencies that were never captured in the original assessment. Building on this, the additional remediation work does not just add cost. It adds weeks to the testing cycle and forces a rescheduling of the cutover window.

Why Support Teams Hold the Real Knowledge

The people who process tickets through the SAP Service Desk every day know which objects cause problems. They know which batch jobs fail on the last day of the month. They know which custom reports the finance team cannot live without. They know which ones nobody has opened in three years. In particular, that operational knowledge is rarely captured in a formal inventory, but it is the most reliable signal available about what is truly active and what is truly critical.

Bringing support teams into the scoping conversation early is not a process improvement. It is a risk management decision. Organizations that treat support as a downstream function consistently underestimate their custom code footprint. Those that treat support as a source of institutional knowledge consistently produce more accurate assessments.

How Technology Is Changing Custom Code Analysis

SAP Business Technology Platform Consulting has changed what is possible in custom code assessment. The platform provides tooling that can analyze usage statistics at the object level. It identifies deprecated APIs and flags objects that will not run in an S/4HANA environment without modification. This is not theoretical capability. It is available today, and organizations that use it systematically produce far more accurate inventories than those relying on manual documentation.

The analysis works by pulling runtime data directly from the production system. Instead of asking developers what they built, the tool asks the system what it actually ran. That shift from self-reported inventory to execution-based inventory is significant. It removes the human memory problem entirely and replaces it with data.

Integrating AI Into the Assessment Process

SAP Business AI is beginning to change how organizations prioritize remediation work after the initial analysis. Once the usage data is available, AI-assisted tooling can classify objects by complexity. It estimates remediation effort and flags objects where automated conversion is feasible versus those requiring manual rewrite. This reduces the time a senior ABAP developer needs to spend on triage. Ultimately, it lets the team focus on the objects that genuinely require expert judgment.

Market trends indicate that organizations using AI-assisted code analysis during pre-migration assessment reduce their remediation estimation errors significantly when compared to those using manual review alone. The improvement comes not from the AI replacing developer judgment but from the AI handling the classification work that previously consumed weeks of senior resource time.

Cloud Migration and the HANA Factor

SAP HANA Cloud solutions introduce an additional layer of complexity for organizations with large custom code footprints. Code that ran acceptably on a traditional database may perform poorly on HANA if it was written without column-store optimization in mind. Some custom reports that took thirty seconds to run on the old platform take three seconds on HANA. Others that ran in two minutes now time out entirely because the query structure is incompatible with the in-memory architecture.

This means the custom code assessment for a HANA migration is not just a compatibility check. Additionally, it is also a performance review. Organizations need to know not only whether the code will run but whether it will run acceptably. That requires a different kind of analysis and a different kind of expertise than a standard S/4HANA readiness check.

Building an Inventory That Stays Accurate Over Time

A one-time assessment solves the immediate problem but does not prevent the same gap from reappearing in three years. The organizations that manage custom code well treat the inventory as a living document, not a project deliverable. That requires process, tooling, and accountability.

The following steps form the foundation of a sustainable custom code governance model:

1. Run usage analysis on a defined schedule: at minimum quarterly, using SAP's native tooling or a certified third-party solution.
2. Assign ownership of the custom code registry to a named role: not a team. Shared ownership produces the same result as no ownership.
3. Establish a retirement process for objects with zero usage over a defined period: Twelve months of zero execution is a reasonable threshold for most environments.
4. Require interface documentation as a condition of object creation: New custom objects should not enter production without a recorded dependency map.
5. Include the SAP Service Desk team in quarterly reviews: Their ticket data provides a real-world signal about which objects are causing problems and which are invisible because they work correctly.

The Role of a SAP System Integrator

Engaging an experienced SAP system integrator USA organizations trust for complex environments can accelerate the inventory work significantly. A qualified integrator brings pre-built tooling, methodology, and the pattern recognition that comes from having done this analysis across dozens of environments. They know where the gaps typically hide. They know what questions to ask that an internal team might not think to ask.

However, the integrator cannot own the inventory permanently. The goal of the engagement is to establish a process the internal team can sustain. An integrator who delivers a report and leaves has solved a point-in-time problem. An integrator who transfers the methodology and the tooling has solved the structural problem.

Connecting Inventory to SAP COE Services

Organizations with a mature SAP Center of Excellence, often referred to as SAP COE Services, have a natural home for custom code governance. The COE is positioned to own the registry, run the periodic analysis, and enforce the retirement process. In organizations without a formal COE, the governance function often falls to the basis team or the application support team by default. With this in mind, this works if the accountability is explicit and the tooling is in place.

The connection between custom code governance and broader SAP COE Services is not incidental. A COE that cannot answer the custom code question accurately is a COE that cannot answer the migration readiness question accurately. The two are directly linked.

Frequently Asked Questions

Q. Why do most SAP organizations not know their exact custom code count?

A. Custom objects accumulate across multiple project waves, often under different governance standards and with different system integrators involved. Without a defined process for tracking additions and retirements in real time, the documented count drifts away from the production reality. The gap widens with every upgrade cycle that passes without a formal reconciliation.

Q. What tools does SAP provide for custom code analysis?

A. SAP provides native analysis tools accessible through the SAP Support Portal, including the Custom Code Migration app and usage statistics reporting within the SAP Readiness Check. These tools pull execution data directly from the production system and identify objects with zero usage, deprecated API calls, and compatibility issues with S/4HANA. The challenge is not access but adoption.

Q. How does the SAP Service Desk contribute to custom code governance?

A. The SAP Service Desk processes tickets that reveal which objects are actively causing problems in production. That ticket data is one of the most reliable signals available for identifying high-risk custom code. Organizations that include support team input in their inventory reviews consistently produce more accurate assessments than those that rely on repository data alone.

Q. What is the financial impact of discovering custom code gaps late in a migration?

A. According to Gartner research on ERP migration programs, scope changes identified after the technical design phase are typically two to four times more expensive to address than the same changes identified during discovery. A custom code gap that adds 200 objects to the remediation scope can shift a program timeline by weeks and add significant unplanned cost to the testing and cutover phases.

Q. How can 2iSolutions help organizations get an accurate custom code inventory?

A. 2iSolutions brings structured methodology and hands-on tooling experience to custom code assessment engagements. The team combines execution-based analysis with operational knowledge from support environments to produce an inventory that reflects what is actually running in production, not just what was documented at the last project milestone. The result is a defensible number that program directors can use to make real decisions.

Conclusion

The custom code number is not just a technical metric. It is the foundation on which migration timelines, remediation budgets, and testing strategies are built. When that number is wrong, everything downstream is wrong too. The organizations that get this right are not necessarily the ones with the most sophisticated tooling. They are the ones that treat the inventory as an ongoing operational responsibility rather than a project-phase deliverable.

Getting to an accurate count requires combining execution data from the production system with operational knowledge from the teams who support it daily. Neither source alone is sufficient. The repository tells you what exists. The runtime data tells you what runs. The support team tells you what matters. Together, those three inputs produce a number that can actually be defended when the program director asks.

2iSolutions works with organizations at exactly this intersection, helping teams move from a number they cannot defend to an inventory they can act on. The work is not glamorous, but it is the kind of foundational accuracy that determines whether a transformation program stays on track or spends its first six months recovering from a scope it never fully understood.