Migrating Custom ABAP Code to SAP S/4HANA

One of the biggest challenges facing SAP customers that are looking to migrate to SAP S/4HANA is figuring out what to do with all the custom ABAP code that’s been piling up over the years. From questions about whether custom code is even needed anymore to concerns about compatibility, there’s a lot to unpack. This article will explore this aspect of the SAP S/4HANA migration process and provide some practical advice to help ABAP development teams get ready to embark on their SAP S/4HANA migration journey. Though the focus will be primarily on upgrading to on-premise SAP S/4HANA systems, this article will also briefly touch on the implications for customers looking to migrate to the public cloud offering SAP S/4HANA Cloud. Specifically, we will look at:

• Understanding the SAP S/4HANA evolution process
• Assessing the scope of the migration effort
• Formulating an adaptation strategy
• Transitioning developer skillsets to work with SAP S/4HANA

First, let’s look at how SAP software has evolved from the initial introduction of SAP HANA to the current SAP S/4HANA solution.

Understanding the SAP S/4HANA Evolution Process

SAP S/4HANA is short for “SAP Business Suite 4 SAP HANA” — although some like to say that the “S” stands for simple. No matter how you slice it, SAP S/4HANA is basically the culmination of a calculated migration process that SAP started back in 2010 when it first introduced its revolutionary SAP HANA database.

With its support for fast, in-memory access and massive parallelization capabilities, SAP quickly saw SAP HANA as the key to unlocking many capabilities that had remained out of reach for its business suite systems. Capitalizing on this opportunity required SAP to move away from its existing strategy of “any database” support for SAP NetWeaver systems (for example, allowing customers to choose their preferred host database, such as Oracle or Microsoft SQL Server systems) in favor of an SAP HANA-only approach. The very name of SAP S/4HANA implies that SAP’s business suite systems will only run on the SAP HANA database going forward (see Figure 1).

Figure 1 Revised SAP NetWeaver ABAP architecture for SAP HANA

The first step in this migration process was the release of SAP Business Suite powered by SAP HANA back in 2013. This was mostly a technical upgrade in which SAP upgraded the underlying application server ABAP code to support the SAP HANA database. From an application coding perspective, nothing really changed in this release: customers running SAP Business Suite powered by SAP HANA were still running the same code base for SAP ERP Central Component (SAP ECC) 6.0 — the only difference was that they were running on a faster SAP HANA database. While this switch led to some noticeable performance victories in certain areas, SAP had its sights set higher.

To fully take advantage of the power of SAP HANA and raise the bar in terms of ERP capabilities, SAP needed to refactor or redesign many of its applications from the ground up. These redesign efforts were focused on several key design points: speed, simplification, and new functionality. Let’s look at each of these key points in turn.

Speed

Using the code “push-down” concept, SAP found that it was able to significantly improve system performance by pushing more of the lower-level data processing down to the database layer. Such changes required some of the logic that had previously existed in the ABAP layer to be refactored into advanced SQL, stored procedures, and other SAP HANA-specific development artifacts.

Simplification

Over the years, SAP was required at times to bend the rules a little bit with regards to best practices in areas such as database normalization. These concessions were reluctantly made to keep system performance at a reasonable level. For example, redundant aggregate tables like BSAD and BSAK¹ were added in the financials area to make it easier to build reports on cleared items. These compromises added a lot of complexity to the system (not to mention a lot of redundant data eating up disk storage). So, one of the goals with the redesign process was to clean up and simplify the data model/application design. The trick here was to accomplish all this without breaking legacy code (both standard SAP code as well as customer and partner custom code). For this, SAP introduced the concept of virtual data models based on core data services (CDS) technology, which effectively replace redundant tables in the data model with views that combine and aggregate the data in real time at the database layer. To the ABAP consumer, this virtualization is (almost) completely transparent and backward-compatible.

New and Innovative Functionality

While making preexisting processes run more efficiently, SAP HANA also opened some doors to new and innovative functions that simply weren’t achievable before. So, in addition to renovating existing applications, SAP targeted some new applications and modules where it could harness the power of SAP HANA to accomplish new and exciting things (such as real-time simulations in lieu of overnight batch runs).

Running parallel to all this was SAP’s introduction of its new SAP Fiori user experience (UX), which quickly emerged as the standard UX going forward for all applications — including non-ABAP-based software-as-a-service (SaaS) applications such as SAP SuccessFactors and SAP Ariba solutions. When we put all this together, you can start to see SAP S/4HANA for what it really is:

• SAP S/4HANA is (still) an SAP NetWeaver ABAP-based ERP system that runs exclusively on the SAP HANA database.
• Since SAP HANA is an ANSI SQL-compliant database,² most legacy ABAP code that uses standard Open SQL statements will be compatible or portable to SAP S/4HANA systems by default.
• The system was designed to be largely backward-compatible with legacy SAP ERP systems.
• While there is quite a bit of net-new functionality included with SAP S/4HANA, there is also a lot of legacy functionality brought over from SAP ERP 6.0 — particularly in the case of edge modules that haven’t been prioritized for renovation yet. This renovation process will be going on for the foreseeable future as SAP continues building out the new SAP S/4HANA core.
• Although most of the new-dimension solutions such as SAP S/4HANA Finance and SAP S/4HANA Enterprise Management (formerly SAP Simple Finance and SAP Simple Logistics) are built using the new SAP Fiori UX — that is, based on SAP’s user interface (UI) development toolkit for HTML5, known as SAPUI5 — there are still many applications out there in SAP S/4HANA that run on legacy UI technologies, such as Web Dynpro or even classic Dynpro.

At the end of the day, while SAP S/4HANA may not be the SAP system you remember, it is still (mostly) SAP software as you’ve always known it. Over time, more legacy features will be phased out, but for now ABAP developers can rest assured that the SAP world hasn’t been completely turned upside down — things are just evolving faster than they have in the past.

Getting Started: Assessing the Scope of the Migration Effort

Now that you have a grasp on what SAP S/4HANA really is, the next step is to evaluate how much custom code you have and whether or not some of that code needs to be adapted to work in the new SAP S/4HANA system.

For customers that have been developing custom solutions on their SAP ERP systems since the early 1990s, there can be a lot of code to wade through. Fortunately, this is not an exercise that must be completed by hand.

SAP provides several useful tools that you can use to catalog your custom ABAP inventory. (For more information about available code migration tools and how you can use them, check out the official Custom Code Migration Guide for SAP S/4HANA provided by SAP online.) Some of the more notable tools provided here include:

• ABAP Test Cockpit helps analyze your custom code to identify potential issues and determine SAP S/4HANA readiness.
• ABAP Call Monitor, Usage Procedure Logging, and Custom Code Lifecycle Management help test code usage, both from a technical and functional point of view. By running these tools in your existing production systems for an extended period of time, you can identify which custom solutions are still in productive use within the context of the business processes that use them.
• ABAP SQL Monitor helps analyze the database usage of your custom code and identify ABAP repository objects that need refactoring.

While ABAP Test Cockpit and the corresponding Eclipse-based ABAP development tools have been around for a while, ABAP Test Cockpit takes on a new and very important role in SAP S/4HANA adaptation projects. Here, besides performing the traditional syntax/usage checks, ABAP Test Cockpit also scans ABAP code for usage of object types that have been deprecated in SAP S/4HANA. These SAP S/4HANA readiness checks can be performed outside of the legacy SAP ERP system in a standalone evaluation system based on SAP NetWeaver 7.51+. As Figure 2 shows, the readiness checks are seeded with a “simplification database” downloaded from SAP Service Marketplace that contains an up-to-date list of affected or deprecated objects. With this information in hand, ABAP Test Cockpit can connect to the back-end SAP ERP system via a remote function call and scan through its custom ABAP code to look for incompatibilities. Developers can then evaluate the results right in ABAP Test Cockpit and, in some cases, use the surrounding ABAP toolset to apply the updates in place in a systematic and reliable way. (For a detailed look at using ABAP Test Cockpit for this purpose, see this article.) 

Figure 2 Running SAP S/4HANA readiness checks

Formulating an Adaptation Strategy

While code migration tools like ABAP Test Cockpit are great for analyzing your custom development inventory, they only shed light on what needs to be updated — they don’t go so far as to magically adapt and update your custom ABAP code for you. Moreover, static code analyzer tools also can’t help you figure out how best to approach custom development in your organization going forward.

Before diving straight into code adaptation, it’s a good idea to first work on formulating a long-term enhancement strategy. While it may be easier to apply the minimum number of refactorings to get all the current custom ABAP code ported over, this approach is shortsighted as deprecation errors will eventually crop up in this patchwork code as SAP S/4HANA continues to mature.

From a practical point of view, these SAP S/4HANA migration projects may be the last opportunity IT departments get to dive in and clean up their ABAP repositories for the foreseeable future. So, while there’s undoubtedly pressure from leadership to get the code migration done as quickly and cheaply as possible, it’s crucial that you take your time and do this right. In the upcoming sections, we’ll take a closer look at key points to consider when formulating your strategy — specifically, the side-by-side extension concept and some scenarios for landscape configuration.

Introducing the Side-by-Side Extension Concept

In recent years, SAP has talked a lot about the idea of systems like SAP S/4HANA serving as the “digital core” of the business. In addition to emphasizing the importance of core ERP systems for a business, the term “core” connotes the idea of a layered architecture where new features are built on top of a clean and stable core.

Customers that are already running SAP Fiori applications on premise have seen this trend toward decoupling in action with the introduction of the SAP Fiori front-end server. Here, while it’s possible to build and deploy SAP Fiori applications directly on SAP’s business suite systems, such as SAP S/4HANA, SAP recommends that these applications be developed on a separate SAP Fiori front-end server, as shown in Figure 3. This approach decouples the newer-dimension SAP Fiori technology components (that is, SAP Gateway and the SAP NetWeaver UI add-on) from the back-end business suite systems so that they can vary independently. This way, you don’t have to wait six months to upgrade to the latest UI add-on release due to tighter, more restrictive support package upgrade schedules on critical back-end ERP systems. Perhaps more important, you don’t have to invest as much time in regression testing efforts in the back-end business suite systems since the upgrades are self-contained within the SAP Fiori front-end server layer.

Figure 3 Understanding the SAP Fiori front-end server

With the introduction and maturation of SAP Cloud Platform, SAP has taken the layered architecture concept a step further by introducing the new side-by-side extension concept. As Figure 4 shows, this concept moves even more of the customization off the digital core and onto a separate (and independently scalable) SAP Cloud Platform tenant instance.

Figure 4 The side-by-side extension concept

With secure on-premise access via the SAP Cloud Connectivity service and a host of programming environments and available cloud services, developers have everything they need to build or refactor their custom ABAP solutions to run outside of the new SAP S/4HANA system. They can even utilize the new cloud-based ABAP environment to continue building these extensions using the ABAP programming language. (Learn more about SAP Cloud Platform ABAP environment in this article.)

The “cloud” part of SAP Cloud Platform is a concept that is here to stay and is becoming more and more common for new extension solutions rolled out by SAP and its partners. Even if cloud (SAP S/4HANA or otherwise) is nowhere on the roadmap, customers need to ask themselves whether it’s a good idea to continue building wholesale ABAP-based enhancements directly within their SAP business suite systems. As SAP S/4HANA and other SAP and non-SAP business suite systems trend toward a SaaS model, customers need to be thinking about a holistic, enterprise-wide strategy for enhancements that can grow and adapt with the business. For some customers, an SAP S/4HANA migration project could be the perfect catalyst to drive these changes as they move forward.

Reviewing Landscape Configuration Scenarios

Technically speaking, there are two basic paths to SAP S/4HANA migration: in-place conversion or a new/reimplementation project. For customers that have been diligent about system updates and keeping their ABAP repository clean and up to date, in-place conversion (such as taking a small step from SAP Business Suite powered by SAP HANA) may well be a viable approach. (For more information on this approach, read this article.) For a large majority of SAP customers though, an in-place conversion is just not feasible for both technical and functional or logistical reasons.

Looking at reimplementation from an ABAP logistics perspective, one of the first questions that comes to mind is where should the legacy code adaptation work be performed? On the legacy system? On the new system? In our estimation, there are three basic approaches customers can take for this:

1. Side-by-side refactoring: In this scenario, a new, pristine SAP S/4HANA development system is set up in parallel to the existing development landscape. Using the SAP S/4HANA readiness checks as a guide, developers can carefully start moving legacy development objects into the new system and verify the results of adaptations directly in the target environment.
2. In-place refactoring: In this scenario, much of the adaptation work is performed ahead of time directly within the legacy system. Using tools like ABAP Test Cockpit, developers can start systematically cleaning up most of the items that are of a more generalized variety (such as bad SQL scripts and deprecated statement or object usage). Following this approach, customers can get a jumpstart on what could be a fairly long and complex migration project down the road by eliminating some lower-hanging fruit items.
3. Branch system refactoring: This approach is similar to the “in-place refactoring” scenario in the sense that the adaptation work is performed in a legacy (non-SAP S/4HANA) system. The primary difference, in this case, is that the development system where the adaptation work is performed is a copy of the existing development system that is branched off from the existing development landscape so that the adaptation work can be performed in isolation, minimizing any effects on ongoing development activities.

Whenever possible, a best practice is for customers to follow the side-by-side refactoring scenario and stand up a new SAP S/4HANA development system to perform this migration work. In addition to giving developers some early exposure to SAP S/4HANA and available toolsets, this approach also provides some peace of mind when it comes to trusting that the adaptation work is complete and the end result works as expected in the new environment.

While the other two scenarios — where the adaption work happens in a legacy system — are less than optimal, they are better than the alternative of doing nothing. Even if an SAP S/4HANA migration is not on the immediate roadmap, this is a project that’s not going to go away. This migration will eventually need to be part of every SAP customer’s journey. For customers that have a lot of custom ABAP development on their hands, this adaptation process can take a while (perhaps months), so the sooner you can get started, the smoother the process will be. Leaving this to the end and putting ABAP developers in the critical path of a high visibility SAP S/4HANA migration project is asking for trouble on a lot of fronts.

So how do you best prepare for a trouble-free migration path? Next, we will look at some technologies and skillsets that developers can familiarize themselves with to transition more gently to the world of SAP S/4HANA.

Transitioning Developer Skillsets to Work with SAP S/4HANA

While on-premise SAP S/4HANA systems provide customers with a gentler transition, there is no getting around the fact that SAP S/4HANA introduces a lot of new technology components that developers are going to need to come up to speed with. Although this phenomenon is not exactly uncharted territory for most ABAP developers, the SAP S/4HANA transition is a very different animal in the sense that many of the new technology components are not ABAP-based (for example, SAPUI5 is 100% JavaScript-based). As such, the learning curve can be very steep and should not be underestimated.

For customers and developers just setting out on this journey, we always recommend that they start by formulating a methodical learning plan with some reasonable goals. In many cases, this could be a multi-year journey, so it’s important to have a plan that prioritizes technologies that developers are likely to be contending with on a more regular basis. In the upcoming sections, we’ll take a closer look at some of the more significant technologies related to SAP S/4HANA: advanced SQL statements and CDS technology, object-oriented development concepts, SAP Gateway and OData services, and SAPUI5 and SAP Fiori interfaces.

Advanced SQL Statements and CDS Technology

One of the benefits of standardizing on a single database in a system like SAP S/4HANA is that SAP now has the freedom to expose a much larger set of database-level functionality. As a result, the Open SQL standard has been expanded quite a bit with SAP NetWeaver 7.40+. Many of the more complex features being used these days (such as nested joins and subqueries), however, can sometimes prove difficult to grasp for ABAP developers who have always worked with a simplified Open SQL subset.

This SQL gap is even more pronounced when it comes to the liberal use SAP S/4HANA makes of CDS technology. Although directly consumable within the ABAP layer, CDS views are built using the Eclipse-based toolkit and utilize an SAP-proprietary syntax that blends elements of SQL, DDL (data definition language), and DML (data manipulation language) commands and annotations. As the entire virtual data model for SAP S/4HANA is built on CDS technology, this is not something that developers can avoid. What’s more, SAP has standardized on CDS technology across all SAP HANA-based environments — both in the cloud and on premise — so you will see it pop up more often going forward.

On the plus side, CDS technology can open up a whole new world of data access for developers who learn how to use it effectively. This is especially true for developers who go the extra mile to learn SAP’s SQLScript language for building stored procedures in SAP HANA. Using a blend of CDS views, SQLScript programming, and an ABAP-based integration construct called ABAP Managed Database Procedures, developers can harness almost all the raw power of SAP HANA without ever having to leave the ABAP environment. A best practice for ABAP development teams getting started with SAP S/4HANA is to always begin focusing on advanced SQL statements and CDS technology. (This article provides a comprehensive introduction to CDS.)

Object-Oriented Development Concepts

For some reason, object-oriented (OO) development has always been a hot button in the ABAP development world, and many developers avoid it at all costs. Regardless of where you stand on this often-heated debate, the fact is that SAP S/4HANA makes liberal use of OO development so it’s becoming much harder to avoid ABAP Objects in the new world.

In the SAP S/4HANA environment, SAP utilizes ABAP Objects technology extensively. Many of the new frameworks SAP has developed are based on design patterns and advanced OO concepts such as composition, inheritance, design-by-contract, and polymorphism. If you are unfamiliar with a lot of those terms, then it’s probably a good idea to brush up on your OO knowledge at some point soon.

One of the more prominent examples of OO usage in SAP S/4HANA is the Business Object Processing Framework, which is a key component in SAP’s ABAP programming model for SAP Fiori. The framework provides a structured, on-rails experience for developing business object models that work in tandem with SAP Gateway and CDS technologies to create modern SAP Fiori applications. Even if you don’t have plans to build custom SAP Fiori applications anytime soon, it’s a good idea to learn about the framework so that you can understand how to debug SAP Fiori applications that are based on this technology. Note that a decent amount of ABAP Objects knowledge is needed to be able to even debug these kinds of applications.

SAP Gateway and OData Services

RESTful application programming interfaces (APIs) based on the OData protocol are the lifeblood of SAP Fiori applications running on SAP S/4HANA. As such, it’s critical that developers get to know their way around SAP Gateway to be able to identify and debug OData services. This requires an interesting blend of knowledge about HTTP, RESTful API design, and ABAP Objects/OO development concepts used within SAP Gateway. Unlike classic Dynpro transactions where developers could enter an “/h” command and hop right into the debugger, SAP Fiori applications can be more difficult to troubleshoot as it’s harder to determine whether the problem is on the JavaScript-based front end or the ABAP-based back end.³

SAPUI5 and SAP Fiori

Finally, since SAP S/4HANA makes heavy use of SAP Fiori technology, there’s a lot of demand for developers who understand how to work with the SAP Fiori UX and SAPUI5 development toolkit. (For an introduction to SAP Fiori development, see this article.) For many developers, this is one of the hardest areas to jump into since SAPUI5 is exclusively JavaScript-based, as opposed to legacy ABAP-based web technologies such as Web Dynpro or Business Server Pages applications. For ABAP developers who are not very familiar with single-page application design, this learning curve can be significant and, in some cases, unrealistic. This is absolutely an area where you don’t want developers tinkering around and experimenting with things they don’t understand.

As a best practice, developers should start learning their way around HTML, JavaScript, and perhaps most important, browser developer tools (particularly those provided with Google’s Chrome browser). Here, it’s particularly important to build up some basic troubleshooting skills so that you can at least diagnose SAP Fiori applications and make educated guesses about what’s broken. SAP’s openSAP learning platform offers a number of free courses on SAP Fiori and related technologies that are definitely worth checking out.

Time to Get Started

With the advice provided in this article, you can start planning your migration journey to SAP S/4HANA. Like most complex tasks, just figuring out where to begin is half the battle. And as you progress down the trail, please do share your stories “from the trenches” of how you are making SAP S/4HANA work in your business. Please email jwood@bowdark.com with any questions, and visit https://www.bowdark.com for more information. We look forward to hearing about your journey.

¹ BSAD is a standard SAP table used to store Accounting: Secondary Index for Customers (Cleared Items) data, and BSAK is a table used to store Accounting: Secondary Index for Vendors (Cleared Items) data.
² To unify structured query language (SQL) commands and statements for best practices, the American National Standards Institute (ANSI) created specific standards for database query languages.
³ DJ Adams provides an excellent guide to help you get started with troubleshooting SAP Fiori applications called “SAP Fiori and SAPUI5: Debugging the User Interface” (SAP PRESS, 2016).