Anthony Cecchini is the President and CTO of Information Technology Partners (ITP), an ERP technology consulting company headquartered now in Virginia, with offices in Herndon. ITP offers comprehensive planning, resource allocation, implementation, upgrade, and training assistance to companies. Anthony has over 20 years of experience in SAP business process analysis and SAP systems integration. ITP is an Appian, Pegasystems, and UIPath Low-code and RPA Value Added Service Partner. You can reach him at [email protected].
The Custom Code Dilemma 
SAP applications are around for quite some time now and so is the option and need to extend them. SAP took care of this and offered many extension mechanisms within the underlying ABAP technology stack. In addition, the ABAP platform itself served as a strong workhorse to build custom-specific functionality and apps collocated to the SAP core system…
Unfortunately, this came at a price; due to different reasons, the solutions were coupled more or less closely to the SAP core (in the worst case modified the core) and upgrades of SAP systems became an issue for many companies. Consequently, upgrades were not a regular task at customer sites but took place irregularly and customers could not make use of recent innovations (in the broadest sense) delivered by SAP. This had and has a negative impact on every user of the SAP starting from business over development to operations.
As we move forward to SAP HANA, we still need the ability to extend capabilities. If our first move is to be SoH (Suite on HANA), well since the core suite is the same and ONLY the underlying database has changed, many of the adaptions via the Enhancement Framework will remain. Granted there may be some post migration clean up and/or refactoring to change the custom objects to utilize the new 7.5 ABAP structure and the “Push Down” paradigm and along with these probably some custom ABAP code. But what about SAP S/4 HANA?
SAP S/4 HANA is centered on the simplification of different activities in your business. Migrating to this software has now become a question of when xand not if. Even so, clients are apprehensive about making a move to SAP S/4 HANA. This is because most cannot figure out how to handle all the custom ABAP codes they have accumulated over time.
The following are a few guidelines that will ease the migration of your custom code ABAP code to the SAP S/4HANA.
Understand The Evolution of SAP S/4 HANA
The SAP S/4HANA is the culmination of a process that SAP started in 2010 with the introduction of the HANA database. SAP HANA had massive parallelization capability and quick in-memory access. With the advent to a new fully re-coded business suite that runs only on the SAP HANA database. SAP upgraded its underlying ABAP server code to support the HANA database. SAP redesigned most applications on three key design elements.
Lets define these….
- Speed: System performance is significantly improved through the use of the push-down concept by SAP S/4HANA that moves low-level data into a database layer. This is because of the refactoring of the ABAP layer into stored procedures, advanced SQL, among other development artifacts. The refactoring, in turn, speeds up the system.
- Simplification: Through the years, SAP has bent some rules to maintain the system’s performance at optimal levels. This often led to several compromises that consequently made the system a bit complex. The SAP S/4 HANA has cleaned up the data model application design used and in so doing, significantly simplified the data processing.
- New functionality: SAP S/4 HANA has opened doors to some innovative functions that did not exist before. You, for instance, now have real-time simulations that have replaced overnight batch runs. The new functionalities are in addition to the renovation of some of the functions on SAP HANA.
With a realization of what SAP S/4HANA entails, you should evaluate the amount of custom code you have and if it needs adapting to the system. While you might have considerable data to work through during your migration, you need not do it manually. SAP now has several tools you can use to list your custom ABAP inventory. Some of the standard tools you can use to do this include:
ABAP Test Cockpit
The ABAP Test Cockpit (ATC) is a tool for doing static and dynamic quality checking of ABAP code and associated repository objects. You can use this tool to monitor ATC results for your custom code objects. You can view all open exemptions for each system. ATC will analyze your custom code and identifies any potential issues that might hamper your SAP S/4HANA migration efforts. It not only performs the conventional syntax/usage checks for the process but will also scan the ABAP code used by object types that have depreciated in the SAP S/4HANA. You can conduct the readiness checks using the ABAP test cockpit in a standalone evaluation system outside the legacy SAP ERP.
CCLM (Custom Code Life Cycle Management), UPL (Usage & procedure Logging), and SCMON (Call Monitor)
Do you know that on average 60% of your custom code is in reality not executed in your productive landscape? Especially in SAP Business Suite migration projects like to SAP HANA or SAP S/4HANA such amounts of unused code result in huge adaptation efforts. Therefore SAP’s recommendation is to clean up your unused custom code before migration. But how can you identify the code that is not used?
By utilizing SolMan 7.2 and the tools above to thoroughly test your custom code from functional and technical perspectives. Running the tools in your existing production systems for a sustained time will help to identify the custom code is still productive in relation to your business processes. This way, you know what to adapt to SAP S/4HANA.
ABAP SQL Monitor
Finally, we need to check which business processes, for example performance of critical database queries, need to be optimized in SAP HANA. To do this, you need to check which SQL statements can be optimized. The relevant performance data for all SQL statements executed in your productive system is displayed in SQL Monitor. Here, you can find the most expensive business processes and the frequently most used SQL statements.
Most business processes include millions of SQL statements generated daily. The custom ABAP code will play an integral role in these primary business processes. The ABAP SQL monitor checks the database’s usage of your custom code and picks any repository objects that should be refactored when migrating to SAP S/4HANA.
Formulate an Adaption Strategy
Custom code migration tools will only show you what you need to update but will not magically update your code. You should formulate a long-term strategy detailing how you will apply the necessary refactoring the tools pick to port over your current custom ABAP code. The plan helps to avoid the depreciation errors associated with the maturation of your SAP S/4HANA.
You have two options for the SAP S/4HANA migration of custom code, including re-implementation of the code and in-place conversion. In-place conversion works for clients that are diligent on system updates and keep their ABAP repository updated and clean. Most clients are however best-suited for re implementation through one of the following approaches;
- Side-by side refactoring: Here, your new SAP S/4HANA system runs parallel to your existing development landscape. The developers will then use the current landscape as a guide to move objects into your new systems and verify their adaptation.
- In-place refactoring: Here, most of the SAP S/4HANA adaptation is done in your legacy system before the software’s integration into your system. Using different tools such as the ABAP cockpit, developers will clean out generalized and low-hanging items in your system. This kickstarts the lengthy and complicated migration process and eases it by getting rid of some items early.
- Branch system refactoring: This is somewhat like in-place refactoring in that the system’s adaptation is done in a non-SAP S/4HANA {legacy} system beforehand. In the branch system refactoring, however, the development system in which the adaptation happens is a branch of an existing development landscape. To this end, SAP S/4HANA migration can be done in isolation to minimize its impact on other operations.
Transition Developer Skillsets
Whether on-premise or in the cloud, there are still technology components for developers to handle. The learning curve needed for a seamless S/4 Hana Custom Code migration is nonetheless quite steep and should not be underestimated. Here are some of the technologies that a developer should be well-versed in for a smooth SAP S/4HANA migration:
- CDS technology and advanced SQL statements that use an SAP proprietary syntax blending DDL, DML and SQL annotations and commands
- Object-oriented development concepts like the business object processing framework. This concept generates an on-rail structured experience that will work with CDS technologies and SAP Gateway for modern SAP Fiori applications.
- OData services and SAP Gateway that are the lifeblood of SAP Fiori applications that run on SAP S/4HANA.
- SAP Fiori and SAPUI5 on which the SAP S/4HANA system heavily relies.
Summary
Hopefully you are now a little better prepared to start on your SAP S/4HANA migration.But as added help, I have linked several important documents I believe will be of great help as you move forward.
Custom code adaptation for SAP S/4HANA – FAQ
Custom Code Migration Guide for SAP S/4HANA 1909
As you progress further down your trail, you might come across other issues not addressed above. It is, therefore, best to have a partner well versed in HANA migrations on premise or in the cloud.
