Expand +



Making the Move to SAP S/4HANA

How ABAP 7.51 Helps You Successfully Migrate Your Custom Code

by Karl Kessler, Vice President of Product Management ABAP Platform, SAP SE | SAPinsider, Volume 18, Issue 1

January 31, 2017

SAP S/4HANA brings the technologies that define modern business to SAP customer landscapes, from cloud computing to consumer-like user experiences, and the latest version — SAP S/4HANA 1610 — brings even more, including support for machine learning and predictive algorithms. Version 1610 also presents an opportunity for those running SAP Business Suite to transition to SAP S/4HANA, as they share the same underlying technology. But how? And what happens to your custom code? This article shows you how to navigate this process successfully using migration and conversion tools delivered with SAP NetWeaver Application Server ABAP 7.51.

Innovations such as cloud computing, consumer-like user experiences, the Internet of Things, and social networks are no longer emerging trends — they are a business reality. SAP S/4HANA is a suite of products, available both on premise and in the cloud, that brings these innovative technologies to every corner of your business, from its core financial and logistics capabilities to its built-in support for procurement, human resources, and customer relationship management.

The latest version of the on-premise SAP S/4HANA — SAP S/4HANA 1610, delivered in October 2016 — brings even more innovation to customers, including an enhanced user experience based on SAP Fiori 2.0 and supply chain capabilities that support new technologies such as machine learning and predictive algorithms. Released on ABAP 7.51, SAP S/4HANA 1610 presents a unique opportunity for businesses running traditional SAP Business Suite implementations to transition to a next-generation software suite designed for competing in the digital age, as both SAP Business Suite and SAP S/4HANA use the same underlying SAP technology.1

So how do you go about getting there? And what do you do about the vast array of custom code underlying your SAP Business Suite systems? While there is no direct upgrade path from SAP Business Suite to SAP S/4HANA — SAP S/4HANA is a completely new offering from a license and deployment perspective — SAP does offer migration and conversion tools to help customers navigate the process successfully (see the sidebar “Moving at Your Own Pace” for more on migration flexibility). This article looks at innovations delivered with SAP NetWeaver Application Server (SAP NetWeaver AS) ABAP 7.51 that enable a smooth transition from a traditional SAP Business Suite system — such as SAP ERP 6.0, enhancement package 8, running on SAP NetWeaver 7.5 — to SAP S/4HANA 1610, with a particular focus on migrating your custom code.

Moving at Your Own Pace

SAP S/4HANA provides both cloud and on-premise deployment options, so that customers can make their deployment decisions based on their unique project requirements and timeline needs. For example, customers running on database platforms from SAP partners (that are supported and properly documented in SAP’s Product Availability Matrix) and seeking a new database system and overall data platform often first move to SAP HANA, but want the option to move to the cloud later. To preserve this option, these customers need software that is cloud-ready as well as able to run on premise — software like SAP S/4HANA.

In the same vein, to help customers transition from SAP Business Suite to SAP S/4HANA at their own pace, SAP will fully support SAP Business Suite until 2025. In SAP’s experience, customers typically migrate 10%-15% of their productive landscape per year, which means that customers that begin in early 2017 can fully migrate a complete traditional SAP Business Suite landscape to SAP S/4HANA by the end of maintenance for SAP Business Suite.

Custom Code and the New SAP S/4HANA Data Model

Traditionally, custom code has been used to close the gap between SAP standard applications and individual customer needs for optimizing business operations. A typical customer installation of SAP ERP is surrounded by a large custom code base written in ABAP that has accumulated over decades to support business requirements.

For instance, many customers have written custom reports referring to SAP tables and structures, domains, and data elements. Many have also customized existing SAP applications using traditional enhancement techniques, such as Business Add-Ins (BAdIs), or extension points in the user interface, such as Web Dynpro field and table extensions. Customers have also modified the code wherever predefined extension points were missing, meaning they obtained a modification key from SAP Service Marketplace to “unlock” and edit the source object — modifications that need to be adapted and reinserted anytime a support package or enhancement package is applied.

When migrating to the on-premise version of SAP S/4HANA, customers need to analyze this custom code base to see which customized applications and extensions are required in SAP S/4HANA, and then adapt that code to the new SAP S/4HANA data model. As shown in Figure 1, SAP S/4HANA comes with a dramatically simplified data model, which means that custom code that worked in SAP Business Suite may no longer work in SAP S/4HANA without modification due to changes in the underlying SAP code that is referenced by that custom code. For example, SAP S/4HANA eliminates the need for aggregates — SAP S/4HANA runs on top of the SAP HANA data platform, which aggregates all totals and subtotals on the fly using its in-memory and column-based architecture. In addition to eliminating aggregates, many underlying dictionary objects (including tables, domains, and data elements) have been simplified in SAP S/4HANA — artifacts upon which custom code typically depends.

Figure 1 — Required custom code must be adapted to the new SAP S/4HANA data model

Without adaptation to the new SAP S/4HANA data model, migrated custom code is likely to fail. It will most likely be syntactically incorrect, or will dump during runtime. Some of the custom code might remain valid if certain aspects of the data model have not changed, but in general you need to adapt the code when transitioning to SAP S/4HANA. Fortunately, ABAP 7.51 comes with tools and methodologies to enable this transition.

Converting Custom Code for SAP S/4HANA

From a process perspective, converting your custom ABAP code for the on-premise version of SAP S/4HANA is similar to the process of performing a traditional upgrade (see Figure 2).

Figure 2 — A two-phased approach to converting custom code for SAP S/4HANA

As you can see, the overall process is divided into a Prepare phase and a Realize phase. In the Prepare phase, the custom code is analyzed on the source SAP Business Suite system. The adaptation of the code happens in the Realize phase on the converted SAP S/4HANA system, since the new SAP S/4HANA code and simplified data model are required to adapt the custom code. Note that a precondition for converting to SAP S/4HANA is that your source SAP Business Suite system must support Unicode, and at a minimum must be running on SAP NetWeaver 7.0x and include SAP ERP 6.0. SAP S/4HANA 1610 requires, and includes, ABAP 7.51 as its foundation.

To support the Prepare and Realize phases of the conversion, a separate analysis system is recommended to host the analysis tools and related functionality — such as the Simplification List, the Simplification Database, and the Custom Code Migration Worklist — used during the conversion. From this system, analysis tools can monitor your existing landscape, and the centralized setup makes it easy to keep the analysis system up to date. SAP NetWeaver AS ABAP 7.51 is an ideal fit for the analysis system — in addition to providing the latest functionality, it is essentially only an SAP NetWeaver AS ABAP stack, so setup is simple and straightforward.

The Simplification List, the Simplification Database, and the Custom Code Migration Worklist play key roles during the conversion process, as you will see later in the article. The Simplification List is a detailed technical document (in PDF format) that explains how the conversion will affect specific transactions and application functionality and provides recommendations for the necessary adaptations. The Simplification Database (see Figure 3), which is accessed by the analysis tools, contains the SAP objects documented in the Simplification List that have been changed or removed for SAP S/4HANA, along with SAP Notes describing the changes.2 The Custom Code Migration Worklist lists all custom objects that refer to items in the Simplification Database and must be adapted for SAP S/4HANA.

LMM figure 3

Figure 3 — The Simplification Database contains all SAP objects that have changed for SAP S/4HANA along with SAP Notes describing the changes

Let’s take a closer look at the key tasks involved in the Prepare and Realize phases of a custom code conversion for SAP S/4HANA.

The Prepare Phase

As with a regular upgrade, you use the Maintenance Planner, a cloud-based service of SAP Solution Manager, to plan and initiate the overall system conversion process. The Maintenance Planner analyzes the source system and ensures that all correct components are in place for the conversion, guiding you step by step through the conversion process. Here, we focus on the code and compatibility portion of the process, which can be subdivided into three steps: eliminate obsolete code, check for SAP HANA and SAP S/4HANA compatibility, and prepare your adaptation worklist.

Eliminate Obsolete Code

To minimize the conversion effort and ensure a smooth transition, first evaluate your existing custom code base to determine what is really needed in the SAP S/4HANA context. In many customer installations, custom code has grown significantly over the years, and some of it is no longer necessary. Think of relocating to a new house — typically you don’t want to move everything. Some items are necessary, but it’s best to leave behind whatever is no longer needed. The same is true for custom code. SAP Solution Manager provides access to tools and services, such as the ABAP kernel-based Usage Procedure Logging tool, to help you identify custom code that is potentially dead and can be removed.

Once you’ve eliminated any obsolete code, the next step is to perform checks on the remaining custom code for SAP HANA and SAP S/4HANA compliance, and then use the results of these checks as a worklist for adapting your custom code.

Check for SAP HANA and SAP S/4HANA Compatibility

The Code Inspector tool (transaction SCI), which is included with SAP NetWeaver AS ABAP, provides check variants for evaluating custom code for SAP HANA and SAP S/4HANA compatibility, and is ideal for performing the analysis work of the conversion process. To manage this work, and to take advantage of the latest checks included with ABAP 7.51, the Code Inspector should run in the separate SAP NetWeaver AS ABAP 7.51 analysis system mentioned earlier, from which it can run its checks on monitored systems, including lower-level systems (releases 7.0x and above), by transferring input from monitored systems via an extraction capability over a remote function call (RFC) channel.3

The FUNCTIONAL_DB check variant of the Code Inspector (see Figure 4) identifies typical errors when moving to SAP HANA, such as use of the ADBC interface, which might contain database-specific SQL statement code, and database operations on physical pool or cluster tables.4 Another commonly identified error when migrating from another database platform is invalid assumptions about the sort order of result sets. Although most custom code is based on Open SQL, which provides full database independence, some legacy ABAP programming techniques assume a certain default sort order of the result set and therefore omit the ORDER BY clause, which is required in SAP HANA, where the result set is not ordered by default as defined by the SQL standard. The Code Inspector identifies these errors, which are easily remedied by making the necessary changes (such as adding the ORDER BY clause) in the appropriate editing tool. These changes should be made immediately, during the Prepare phase, to reduce complexity.

Figure 4 — The SAP HANA checks provided by the FUNCTIONAL_DB check variant of the Code Inspector identify typical custom code errors that occur when migrating to SAP HANA

The Code Inspector also provides an S4HANA_READINESS check variant that uses the Simplification Database to evaluate the code for changes that will be needed for SAP S/4HANA, such as data model changes. One significant data model change is the extension of the material master code from 18 to 40 characters in SAP S/4HANA. Since customers often use their own material code numbers, this can cause type and length conflicts in a conversion, such as concatenation of fields if the target field is not long enough. Another significant data model change is that many physical tables referenced by write and read operations have been removed in SAP S/4HANA. For read operations, SAP S/4HANA delivers a compatibility view that computes the desired output on the fly, such as aggregations, but write operations will need to be adapted — SAP S/4HANA provides function modules for this purpose, but you must call them explicitly in your custom code.

The Code Inspector provides an assortment of SAP S/4HANA checks (see Figure 5) with the S4HANA_READINESS check variant to identify these types of SAP S/4HANA issues, such as field extension checks and database operations checks. While there is always the possibility of false positives due to the nature of custom code that cannot be understood by a tool, the checks provide valuable information for analyzing your particular situation, and identifying where you need to make changes in the Realize phase.

Figure 5 — The SAP S/4HANA checks provided by the S4HANA_READINESS check variant of the Code Inspector use the Simplification Database to identify custom code changes required for SAP S/4HANA

Prepare for the Adaptations

Once you complete your checks in the Code Inspector and remedy any errors identified by the SAP HANA checks, you are ready to prepare for the necessary SAP S/4HANA adaptations. While you must manually create your worklist of changes identified by the SAP HANA checks, which tends to be fairly simple and straightforward, the results of the SAP S/4HANA checks, which are likely to be more extensive, are compiled into the Custom Code Migration Worklist that serves as your SAP S/4HANA adaptation guide in the Realize phase. Some required SAP S/4HANA changes are currently beyond the scope of the Code Inspector checks, however. To bridge this gap, and to ensure that nothing is overlooked, SAP provides transaction SYCM.

Included with SAP NetWeaver 7.5,5 SYCM is a small transaction that runs in the centralized analysis system, with extraction capabilities providing the necessary input from monitored systems. SYCM provides an overview of how your custom code objects relate to the simplification items in the Simplification Database (see Figure 6). For example, if you call a BAPI in your SAP Business Suite custom code, but this BAPI no longer exists in SAP S/4HANA or its interface was changed in a way that is incompatible with SAP S/4HANA, a corresponding entry will appear in the SYCM overview screen. From there, you can navigate to the corresponding code and development objects or display the SAP Note that documents the listed simplification item.

Figure 6 — Transaction SYCM provides an overview of how custom code objects relate to the simplification items in the Simplification Database

SYCM serves as an initial overview and entry point for further analysis of the impact and effort required to adjust your custom code objects for SAP S/4HANA. While SYCM is useful in the Prepare phase for estimating and planning for the adaptation effort that will be required in the Realize phase, it should not replace the Custom Code Migration Worklist in the Realize phase — the Custom Code Migration Worklist should serve as your main guide, with SYCM filling in any gaps in a complementary role.

The Realize Phase

Once you are prepared to adapt your custom code for SAP S/4HANA, you are ready to execute the physical conversion. Use the Software Update Manager system maintenance tool to execute the physical conversion steps, such as migrating the database to SAP HANA, updating all the relevant software components (such as the ABAP kernel and Basis components), and converting the data. With the physical conversion complete, it’s time for the functional adaptation of the code, which takes place in the newly converted system.

First, you adapt your modifications to SAP standard-delivered objects that will also be present in SAP S/4HANA using transactions SPDD and SPAU, as you would when upgrading or applying a support package or enhancement package to SAP Business Suite. Note that with ABAP 7.51, the SPAU transaction has been enhanced to support mass operations in cases where you want to reset your modifications and return to the SAP standard.

Next, it’s time to work through the custom objects identified by the Code Inspector as needing adjustment for SAP S/4HANA, due to their dependence on the simplification items included in the Simplification Database, which are listed in the Custom Code Migration Worklist (see Figure 7). These custom objects can be adjusted by simply going into the editor tool for each affected custom object and fixing the syntactical and semantic errors, such as adapting write operations that reference physical tables that no longer exist. Remember to use transaction SYCM for an initial overview of any custom objects that correspond to items in the Simplification Database, since the Code Inspector checks do not cover all SAP S/4HANA-related issues.6

Figure 7 — An example listing of custom objects requiring adaptation in the Custom Code Migration Worklist

When the worklist is complete, the system is ready from a purely functional perspective. You will still need to optimize system performance by tuning critical queries and SQL statements using the SQL Monitor (transaction SQLM), which tracks execution times for SQL statements and the originating program, function modules, or ABAP classes. The SQL Monitor offers drilldown capabilities (see Figure 8) and leads you to the corresponding tool to fix any identified performance issues.

Figure 8 — The SQL Monitor offers drilldrown capabilities for investigating identified performance issues


SAP S/4HANA enables customers to integrate into their organization the technologies that define modern business, and SAP S/4HANA 1610 is an opportunity for those running SAP Business Suite to make the move with the support of migration functionality delivered with SAP NetWeaver AS ABAP 7.51 — including conversion tools for managing your custom code. Validated with realistic custom code from large SAP Business Suite customers, these tools help you ensure a smooth and reliable transformation of your organization into a next-generation digital business running on SAP S/4HANA.

Learn more about migrating your custom ABAP code at

1 Note that the on-premise SAP S/4HANA requires only the ABAP platform, meaning that the digital core is based on technology innovations delivered with the ABAP platform. Java-based on-premise services such as Adobe Document Services, Enterprise Services Repository, and SAP Process Integration can be reused from existing SAP NetWeaver integration hubs. [back]

2 The most recent content provided for SAP S/4HANA is described in SAP Note 2241080. [back]

3 SAP Note 2270689 describes the extraction process. [back]

4 SAP Note 1912445 describes the FUNCTIONAL_DB check variant in detail. [back]

5 Since the publication of this article, transaction SYCM has been replaced by the ABAP Test Cockpit. Learn more at[back]

6 In the future, SAP plans to embed all SYCM findings into the Code Inspector. [back]

An email has been sent to:


Karl Kessler, SAP
Karl Kessler

Karl Kessler ( joined SAP SE in 1992. He is the Vice President of Product Management ABAP Platform — which includes SAP NetWeaver Application Server, the ABAP Workbench, the Eclipse-based ABAP development tools, and SAP Cloud Platform ABAP environment — and is responsible for all rollout activities.

More from SAPinsider


Please log in to post a comment.