How to Understand Code Remediation Tools for HANA

Executive Summary

  • SAP provides advice for remediating code for HANA.
  • We review the quality of this advice (as well as the organization of SAP content) for helping the client rather than helping SAP.


SAP has published its perspective on remediating code for HANA. Both SAP has their consulting partners have consistently underrepresented the complexity involved in code remediation to customers in order to make the migration to HANA seem to be less work and less cost than it actually is. In this article, we review the material on remediation without any SAP bias.


The information provided by SAP as to code remediation is horrendously complicated. It is a disorganized assembly of information released without any rhyme or reason or any controlling entity coordinating the information. Our conclusion is that SAP’s degenerate organization of information around HANA code migration is going to lead to inefficient code remediation projects. Whatever the actual level complexity of HANA code remediation, SAP has made the issue far worse though how it has created tools and communicated how code migration works.

Automatically Fixing 90% of ABAP Errors?

It is very appealing to be able to fix ABAP errors automatically. This is the proposal of GekkoBrain.

“We typically eliminate 90% of the issues before getting started on code fixes by eliminating code items that are either in unused programs or because the fix will have limited impact – for example, performance related fixes in programs with low usage. Once the fixes have been made and are transported back into the DEV system, we can precisely pinpoint who should test and which transactions to test, before releasing the code for production.

Instead of attempting to speed up the process of scanning your codebase and manually adapting code, Gekkobrain actually helps you strip away up to 90% of the HANA-incompatible custom ABAP-code in your systems. “

These code management tools also provide a method of following for performing the remediation, rather than following all of the steps as outlined by SAP. These tools can be used for analysis and to improve or optimize ABAP code in addition to remediating the code prior to say HANA or S/4HANA. This is expressed in the following GekkoBrain quotation.

“Optimizing your ABAP codebase with Gekkobrain’s automatic code fixing module will dramatically improve the performance of your custom code. In fact, we’ve seen performance improvements of up to 50% in often-used programmes for some customers.”

Managing 30,000 Issues?

Code analyzers return a high number of issues as the following quotation attests.

“When I was tasked with cleaning up code for a SAP user, we ran the code inspection, we had SAP estimate the efforts and ended up with a nice spreadsheet with 30,000 rows. Each row was one issue. As a project manager, how do I manage this? How do I allocate team member to tasks? How do I figure out, if they’ve done the work? How do I know, when we’ll be ready? I don’t. I can’t. As a project manager tasked with getting the custom code HANA ready, the first thing you will learn is that it’s a much bigger task than expected. As mentioned, I had to get 30,000 issues fixed. Half of which were in unused programs, which still left me with around 15,000 issues to fix. Each issue was about 25 minutes, leaving me with a project of 750 days.”

So, of course, the starting point is the 15,000 unused programs. So immediately the number comes down significantly.

With companies performing migration analyses to S/4HANA this will be one of the most extensive period of analysis into the previously written custom code in the history of SAP’s ERP systems.

Curiously, there are not very many SAP code remediation tools.


What GekkoBrain proposes will sound tantalizing to companies preparing for either a remediation or a remediation analysis. We found GekkoBrain’s descriptions and explanations to be far more effective than SAP’s material on code remediation. We have not had the opportunity to verify the statements made by GekkoBrain.

Search Our Other HANA Content

Financial Disclosure

Financial Bias Disclosure

Neither this article nor any other article on the Brightwork website is paid for by a software vendor, including Oracle, SAP or their competitors. As part of our commitment to publishing independent, unbiased research; no paid media placements, commissions or incentives of any nature are allowed.

HANA & S/4HANA Research Contact

  • Interested in Research on S/4HANA & HANA?

    It is difficult for most companies to make improvements in S/4HANA and HANA without outside advice. And it is not possible to get honest S/4HANA and HANA advice from large consulting companies. We offer remote unbiased multi-dimension S/4HANA and HANA support.

    Just fill out the form below and we'll be in touch.


The Risk Estimation Book


Software RiskRethinking Enterprise Software Risk: Controlling the Main Risk Factors on IT Projects

Better Managing Software Risk

The software implementation is risky business and success is not a certainty. But you can reduce risk with the strategies in this book. Undertaking software selection and implementation without approximating the project’s risk is a poor way to make decisions about either projects or software. But that’s the way many companies do business, even though 50 percent of IT implementations are deemed failures.

Finding What Works and What Doesn’t

In this book, you will review the strategies commonly used by most companies for mitigating software project risk–and learn why these plans don’t work–and then acquire practical and realistic strategies that will help you to maximize success on your software implementation.


Chapter 1: Introduction
Chapter 2: Enterprise Software Risk Management
Chapter 3: The Basics of Enterprise Software Risk Management
Chapter 4: Understanding the Enterprise Software Market
Chapter 5: Software Sell-ability versus Implementability
Chapter 6: Selecting the Right IT Consultant
Chapter 7: How to Use the Reports of Analysts Like Gartner
Chapter 8: How to Interpret Vendor-Provided Information to Reduce Project Risk
Chapter 9: Evaluating Implementation Preparedness
Chapter 10: Using TCO for Decision Making
Chapter 11: The Software Decisions’ Risk Component Model