Anand Naidu is a veteran in the realm of SAP development and enterprise architecture, bringing nearly two decades of hands-on experience to the table. As a specialist proficient in both frontend and backend systems, he has spent over 19 years helping organizations navigate the shift from legacy ECC environments to the modern S/4HANA landscape. With the 2027 deadline for mainstream maintenance approaching fast, his insights into risk-based modernization offer a vital roadmap for leaders looking to clean their core without wasting resources on unnecessary rewrites.
Usage data from tools like the ABAP Call Monitor often reveals that a significant portion of custom code is effectively dead weight. How should teams interpret this data to ensure they aren’t carrying obsolete objects into their new S/4HANA environment?
The first step is always to prove an object is actually used, which we call “Step Zero” in our framework. By utilizing the ABAP Call Monitor (SCMON) or Usage and Procedure Logging (UPL), we can see exactly which developments execute in a real-world setting. However, you must ensure your observation window reflects the full business calendar; for instance, a program that has not run for six months might seem obsolete, but it could actually be a critical year-end process. Once you have this evidence, you must confirm it with the business owner before moving to the “Retire” outcome. Safely retiring these objects is the most cost-effective modernization strategy available, as every deleted object is one less thing to analyze, test, and document.
When evaluating the active portfolio, you advocate for a four-factor assessment involving criticality, dependency, change frequency, and risk. Why is it vital to look at change frequency specifically rather than just technical stability?
While stability tells you if a program works today, change frequency tells you how much it will cost you tomorrow. Consider a calculation that has remained untouched for ten years versus a sales enhancement that receives new requirements every quarter. The frequently changing logic gains the most value from a “Re-architect” outcome because a cleaner extension model makes every future update easier to build and test. Conversely, if a stable function is technically supportable, there is very little economic return in a full rebuild. We want our modernization budget to follow the risk and the effort, concentrating on where business importance and architectural fragility intersect.
The case of the aging report illustrates a common S/4HANA pitfall where logic remains valid but performance collapses. What specific actions should architects take when legacy tables like BSID or BSAD are involved?
In S/4HANA, these classic open-item tables are replaced by compatibility views over the Universal Journal, which can lead to dramatic slowdowns during month-end processing of production data. Instead of a total rewrite of the business logic, the smarter action is “Encapsulate” or “Targeted Modernization.” You should redesign the data-access strategy to use released Core Data Services (CDS) views and then conduct rigorous performance testing at realistic volumes. This approach preserves the valuable logic the business relies on while replacing the problematic data coupling that causes the bottleneck. It is a surgical strike rather than a demolition, ensuring the report remains functional under high-stress periods.
Moving a custom header field from a VBAK append to key-user extensibility seems like a small task, but it signals a major shift. How does this align with the “clean core” objective as we move closer to the 2027 maintenance deadline?
This is a perfect example of moving away from the classic “MV45AFZZ” user exits that have plagued SAP upgrades for decades. By shifting a field to key-user extensibility and moving the logic to a released extension point, you are effectively drawing a clear boundary between your custom code and the SAP core. This reduces coupling, meaning that when SAP releases its next update, your custom logic is far less likely to break. We are seeing more teams adopt this ABAP Cloud-oriented architecture to make their next ten changes safer and more predictable. It turns “clean core” from a marketing slogan into a measurable trajectory for the engineering team.
There is often a push to modernize every legacy object for the sake of architectural purity, yet you suggest retaining some old routines. What is the risk of rewriting a stable pricing routine that has been running on VOFM for years?
The risk is that you introduce new bugs into a business-critical process that is already performing perfectly. If a custom pricing routine has barely changed in ten years, uses a supported mechanism, and has strong regression testing coverage, its age is simply not a problem. In this scenario, “Retain” is actually the lower-risk decision because it avoids the potential for functional regressions in a high-volume area like sales order processing. We only suggest moving to a new model when the dependency profile changes or a clearly superior, supported option becomes available. Our goal is to avoid the “demolition order” mentality and instead make decisions based on concrete engineering evidence.
With AI now capable of explaining undocumented ABAP and drafting remediation far faster than manual review, how does this change the decision-making process for modernization?
AI is an incredible accelerator for understanding what a complex program does, but it cannot tell you why it exists or if the business still needs it. We use AI to interpret ABAP Test Cockpit (ATC) findings and suggest remediation options, which drastically changes the economics of the analysis phase. However, automatically modernizing an object that should have been retired is just a faster way to waste money. The sequence that actually works is evidence first, human decision second, and then automation third to execute the change. AI helps us manage the volume, but architectural judgment remains a human responsibility to ensure we aren’t just creating “modern junk.”
What is your forecast for the state of SAP landscapes as we approach the final stretch toward 2027?
I expect we will see a massive shift toward “selective modernization” as companies realize they don’t have the time or budget to rewrite 20 years of custom development. The organizations that successfully transition to S/4HANA will be those that aggressively retire the 30% to 50% of unused code that typically sits in a mature landscape. We will see a “clean core” become a practical, measurable reality where high-change applications live in BTP or ABAP Cloud, while stable, low-risk legacy logic is safely encapsulated. Ultimately, the winners won’t be the ones who rewrote the most code, but the ones who used evidence to decide exactly what was worth keeping.
