How to Understand SAP’s Advice on S4HANA Code Remediation

Executive Summary

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

Introduction

SAP has published its perspective on remediating code for S/4HANA. Both SAP and its consulting partners have consistently underrepresented the complexity involved in code remediation to customers to make the migration to S/4HANA seem to be less work and less cost than it is. This has been done to get companies to underestimate the complexity and cost of the implementation so they are more willing to purchase S/4HANA and S/4HANA implementation services. And to buy S/4HANA under false expectations that later come back to bite the project during the implementation. We review this terrible and biased advice on remediation and provide you with our analysis.

Our References for This Article

To see our references for this article and related Brightwork articles, visit this link.

Notice of Lack of Financial Bias: We have no financial ties to SAP or any other entity mentioned in this article.

• This is published by a research entity, not some lowbrow entity that is part of the SAP ecosystem. 
• Second, no one paid for this article to be written, and it is not pretending to inform you while being rigged to sell you software or consulting services. Unlike nearly every other article you will find from Google on this topic, it has had no input from any company's marketing or sales department. As you are reading this article, consider how rare this is. The vast majority of information on the Internet on SAP is provided by SAP, which is filled with false claims and sleazy consulting companies and SAP consultants who will tell any lie for personal benefit. Furthermore, SAP pays off all IT analysts -- who have the same concern for accuracy as SAP. Not one of these entities will disclose their pro-SAP financial bias to their readers. 

Background on this Research

The information provided by SAP as to code remediation is horrendously complicated. It is a disorganized assembly of information released without rhyme, reason, or controlling entity coordinating the information.

• We conclude that SAP’s degenerate organization of information around S/4HANA code migration will lead to inefficient code remediation projects.
• Whatever the actual level of complexity of S/4HANA code remediation, SAP has made the issue far worse by creating tools and communicating how code migration works.
• Some of the information about code remediation is found in comments on SAP blog articles, which take a great time to read and indicate frustration or confusion about how code remediation for HANA and S/4HANA is supposed to work.

How SAP views the overall migration.

The more one studies this topic, the bigger and more complicated it looks, a point emphasized by the following quotation.

Migrating to SAP S/4HANA is almost always a longterm project because of the amount of work required for a Systems Conversion. Cross-referencing the 700+ pages of the Simplification List against every line of code in your current SAP systems is a huge job, even when automated. Working through the list of incompatibility issues is another thing altogether. There will potentially be hundreds of thousands, or even millions, of issues for your development team to manually fix, one by one – but there are ways you can make migration easier.

Simply looking through that many lines of code could take months. So imagine the time-frame when you include performing fixes and testing the new code. Not to mention all the time required for project management. And then, just when you think you’re done, there’s a pile of freshly-written code to go through.

We’ve literally seen these kinds of projects take years and require thousands of labour-hours. (emphasis added)  – GekkoBrain

Sounds easy, right? It is so easy that PwC directors are commenting that it is pretty natural to implement S/4HANA  for 500 users or less in 6 to 9 months, as we covered in the article How to Understand Forrester’s Fake S/4HANA TCO Study. The time required for the code remediation is one of the most apparent contradictory data points to the project estimates. These are being proposed by consulting firms merely trying to sell S/4HANA projects that will be sold on pretenses and then lengthened out with change orders.

The following quotation is far too charitable, but the last part of the reference is undoubtedly correct.

Although SAP’s tools do a great job of identifying the Simplification Items that are holding up your Systems Conversion, they offer very little to help you effectively manage your migration project.

To make sense of it all, we created this article.

Analysis of Quotes on the Topic

Getting Rid of Unused Customization Code

“We recommend to get rid of your old unused custom code (custom code evaluation) and then analyze your custom ABAP code with the Simplification Database and find out which objects need to be changed to get adapted to the SAP HANA and SAP S/4HANA (SAP S/4HANA checks)” – SAP Blog by Olga Dolinskaja

This is partly true but greatly overstated by SAP and SAP consulting firms. This attempts to make customers think they need nearly no custom code.

SAP has a continual position that customers can use standard SAP, which has never proven true in the history of SAP projects, except for highly regulated environments like pharmaceuticals that, for regulatory reasons, cannot be customized. This is the problem in taking advice from a packaged software vendor; the advice is nearly always to use their standard functionality. SAP has created an ERP system that has vastly overstated its ability to meet different industries’ requirements.

SAP has a specific strategy for misleading customers when their predictions around their system’s usage are false, as we cover in the article How SAP Will Gaslight You When Their Software Does Not Work as Promised. 

How Much Poor Quality Code?

SAP does not want to discuss how much poor-quality code is running at SAP customers. Much of this code was written by consultants working for the major SAP consulting firms, one of the worst environments for performing any technical work.

GekkoBrain covers the topic of code quality in the following quotation.

One thing we’ve noticed in almost every SAP project we’ve worked on, is the sheer volume of unnecessary or under-performing ABAP code haunting clients’ SAP systems.

But the following quotation seems to be widely accepted without question.

Approximately 60% of all custom code is never used in the productive environment, so using the UPL feature to gain a clear picture of your unused custom code means you’ll likely be able to eliminate a significant portion of it with no effect to performance. This has the potential to hugely reduce the amount of custom code in your systems, resulting in less time spent searching for and adapting custom code that’s incompatible with HANA. It could mean around a 60% saving on the time and money your systems conversion requires.

And from SAP…

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? – SAP Blog by Olga Dolinskaja

These quotations declare specifics and why finding and rooting unused custom code makes sense. It is essential to consider that SAP has a specific intent when they discuss coding. They reverse engineer their data to fit the conclusion: customers don’t need custom code. However, once gathered independently of SAP, all of the evidence supports the opposite view.

The Simplification Database is Explained

The Simplification Database is, according to SAP…

SAP provides tools, based on the Simplification Database, that detect any custom code that needs to be adapted to SAP S/4HANA. The Simplification Database is a database table in the SAP S/4HANA system that contains all Simplification Items that refer to SAP objects simplified in SAP S/4HANA. Each simplification item describes changed or removed SAP objects and refers to a dedicated SAP Note that describes the impact of the change and how the related custom code can be adapted. To analyze the required adaptations, you need to set up a system based on SAP NetWeaver AS for ABAP 7.52 that operates as a Central Check System. Using this Central Check System, you can perform remote custom code checks in ABAP Test Cockpit (ATC) for one or more systems in your landscape.

GekkoBrain connects to NetWeaver 7.52 and the S/4HANA Simplification database. 

Is it Unnecessary to Perform Custom Code Evaluation?

Observe the following quotation from a pro SAP source.

Please note: custom code evaluation is recommended but not obligatory. You can carry out your custom code adaptation process without it (e.g. in case if you don’t use CCLM in SAP Solution Manager).

Traditionally SAP customers developed over years so much custom ABAP code that it is not clear, which parts of it are still really productively used. Therefore it is recommended to monitor your system landscape for a longer period of time in order to do some housekeeping and eliminate the code, which is not used anymore within your productive business applications. – SAP Blog by Olga Dolinskaja

What an odd thing to say.

SAP proposes that you worry about estimating the work effort after you have already decided to implement S/4HANA. Does that sound responsible? And this quote again goes back to eliminating code. However, after all these years, S/4HANA has a smaller functionality footprint than ECC. And some functionality that companies rely upon has been removed. So, that means companies will need to add extra custom code, but this fact is not mentioned on the SAP blog.

Adjusting ABAP to Run on HANA

This is one of the few areas where SAP admits there will be extra work.

One reason is, that you possibly used native SQL of the predecessor database and these database vendor specific dependencies must be eliminated. Another reason is, that in some custom code implementations the SELECT statement without ORDER BY is used assuming that the data in a database table was already sorted (for example by key). According to the SQL specification when using SELECT statement without ORDER BY, you cannot rely on the sort order because it depends on the respective implementation of the DB vendor and therefore can cause unexpected behavior when the database changes (for example to SAP HANA) because the results of SELECT without ORDER BY return in a different order.

One reason is, that you possibly used native SQL of the predecessor database and these database vendor specific dependencies must be eliminated. Another reason is, that in some custom code implementations the SELECT statement without ORDER BY is used assuming that the data in a database table was already sorted (for example by key). According to the SQL specification when using SELECT statement without ORDER BY, you cannot rely on the sort order because it depends on the respective implementation of the DB vendor and therefore can cause unexpected behavior when the database changes (for example to SAP HANA) because the results of SELECT without ORDER BY return in a different order. – SAP Blog by Olga Dolinskaja

This is a good tip. The SQL must be evaluated for every place that SQL is written in the customization.

However, this is just the remediation, not the optimization phase. Notice the following quotation, which explains an optimization phase to getting the customization to work on HANA.

After you did the system conversion to SAP S/4HANA and the system is up and running, you need to look which business processes can to be optimized on SAP HANA database since you can now make use of full power of SAP HANA regarding performance. – SAP Blog by by Olga Dolinskaja

However, this point leaves out Brightwork Research & Analysis’s conclusion that the performance of S/4HANA will degrade from ECC because HANA is a poorly fitting database for an ERP system. HANA has issues running MRP and is slower in transaction processing.

We covered these topics in the article How to Understand Why HANA is a Mismatch for S/4HANA and ECC and in the article Which is Faster HANA or Oracle 12C?

Getting Terrible Advice About HANA From SAP Consultants

Olga Dolinskaja has not researched this topic, and as with most SAP resources, she primarily repeats whatever SAP says, whether or not she thinks it is true.

This optimization process is also commonly disregarded before engaging in a S/4HANA project. This is another reason we find the entire switch out of the row-oriented database for a 1/2 column-oriented database like HANA to be incredibly wasteful. After all of this tuning and optimizing, S/4HANA customers can expect worse performance than they had under ECC for all things except reporting. SAP’s development has a problem optimizing SQL for HANA, which is an issue for any SAP customer.

The proposal is that the migration is worth it, as expressed in the following quotation.

ABAP was one of the first coding languages to introduce a high level of abstraction between business applications, operating systems and databases – now known as Logical Databases (LDBs).

Simply put, ABAP-developed applications copy information from a database, leaving the database itself completely untouched. The data is then processed and transformed by the application before the result is presented to the user.

The use of ABAP code ensured any SAP application was “database neutral” and could extract information from a range of databases because it didn’t depend on functionality unique to specific platforms.

One of the inevitable trade-offs that resulted from accessing the unique functionality of SAP HANA is that any custom ABAP code written specifically to interact with another database is now obsolete and could potentially interfere with your systems.

Innovations such as cloud computing, the Internet of Things and real-time analytics are no longer emerging technology – they’re business reality. And organizations who aren’t utilizing new technologies will quickly fall behind competitors.

HANA is SAP’s proprietary cutting-edge database and provides clients with access to some of these innovations and represents some some of the most advanced technology available. – GekkoBrain

However, the problem with this argument is that other applications run multiple databases without using a language that processes the data and then later applies it to the database, like HANA. And there is nothing particularly proprietary about SAP HANA. HANA was reverse-engineered from other currently existing databases and was made up of several acquisitions that SAP had nothing to do with developing, as we covered in the article Did Hasso Plattner and His Ph.D. Students Invent HANA?

Nothing in this explanation explains why SAP only ported S/4HANA to HANA. But that is the way it is for now. The following quotation describes why code that previously worked for multiple databases must now be adjusted to work for one…HANA.

SAP HANA’s dramatically simplified data model means custom code that worked with other databases may not function optimally using HANA. This is due to changes in the underlying database architecture that is referenced by that custom code.

One example of this is the need for code that aggregates data. SAP HANA aggregates all totals and subtotals on the fly using its in-memory and column-based architecture, obviously, this means you no longer need ABAP code that performs this task.

The first part of this quotation is not correct. The data model has not been simplified. Indeed, the custom code that worked with other databases will not function optimally or even function for HANA.

SAP’s Remediation Tools

SAP has introduced a series of S/4HANA code remediation tools like the Simplification Database and the Code Inspector. The tools we will cover are the following:

1. The Simplification Database (which we already covered)
2. The ATC with Remote Code Analysis
3. The ABAP Call Monitor (SCMON)
4. S/4HANA Migration Cockpit
5. The Migration Object Modeler 1809
6. Use the SAP Solution Manager Custom Code Lifecycle Management Tool
7. The ABAP Test Cockpit

There are several problems with these tools.

1. The tools duplicate one another, so it isn’t very clear to know which tool to use. Part of this is because the coding remediation tools have turned over, and new ones have been introduced, obsolescing the old tools. Some of these tools have been introduced too quickly and were not complete.
2. These tools have not proven useful and apply more overhead to the analysis than they give back in efficiency.
3. There is a central problem with all of these tools, in addition to the tiny amount of effort SAP has put into developing the tools. And the problem is they mostly exist for marketing reasons. They are something that sales reps can say will “simplify” the analysis when, in fact, they do not. A second issue is the constant use of “simplify” or “simplification” to describe anything involved in remediation. First, S/4HANA does not simplify anything; it is a significant change requiring significant effort. Therefore, SAP’s information is not intended to help developers as much as it is to make it sound like remediation effort will be low. Once S/4HANA is sold on these pretenses, the SAP consulting firm can change the order of the account for a major code rewrite effort.

This graphic is nonsensical. S/4HANA running on HANA does not mean there are fewer databases. HANA is not a more straightforward database than a purely row-oriented database, as we covered in the article How Accurate Was SAP About S/4HANA and a Simplified Data Model. SAP published this graphic in the document Custom Code Migration Guide for SAP S/4HANA 1809, but without any explanation for why this graphic is accurate. 

Notice the quote that is printed below this graphic.

“Some of your custom code objects are not valid anymore and either do not perform as expected or produce syntax errors or dumps (red objects in the picture). You almost certainly have other objects that do perform as expected and do not need to be changed (green objects in the picture).”

Does that explain the graphic? Does it sound more simple? The answer to both questions is NO.

While SAP uses the term “Simplification,” this is a better way of thinking about code remediation for S/4HANA. SAP consulting companies go along with the absurd concept that the massive dislocation and expense of S/4HANA is “simplification.” SAP consulting companies need to help SAP in misleading their customers. Our research into the history of S/4HANA implementations clearly shows that S/4HANA is anything but a simplification. The introduction to this research is found in the article The S/4HANA Implementation Buyer Intelligence Highlights.

Let us address this point. Keeping things the way they were would have been “simpler.” All of these changes implemented by SAP have significantly increased the situation’s complexity. At some point, say seven years from now, it may be simpler, but then again, it may not.

As remediation is confusing, let us review the following comment on the SAP Blog by Olga Dolinskaja.

Thanks for your description. But I am completely confused now. In the SAP Note 2271900 – Custom Code Management: Generation of Code Inspector Variant and SAP Note 2270689 – RFC Extractor for performing static checks SAP describes how to use the SAP Code Inspector to execute a remote check for the custom code analysis. These SAP Notes contain also How-To-Guides for the SAP Code Inspector.

But in your description, the ATC is the tool of choice.

What is the right recommendation for customers?

Olin Dolinskaja recommends the ATC with Remote Code Analysis.

Indeed, it is good to reduce the custom code if possible, but once again, it was written for a reason. If SAP could meet the requirements, the company would not have gone through the time and effort to create the code in the first place.

The ATC with Remote Code Analysis

This is the tool recommended for static quality checking and custom code checking for S/4HANA.

The ABAP Call Monitor (SCMON)

This is for analyzing the code usage. This is supposed to be used in conjunction with ATC.

“The purpose of the ABAP Call Monitor (transaction SCMON) is to monitor the execution (usage) of ABAP code (function modules, method calls etc.) in your productive system.” – SAP Blog by Olga Dolinskaja

From Olga’s blog.

This shows the programs and objects that appear from the SCMON From Olga’s blog.

Then one can review the request types and names from Olga’s blog.

How Good is SCMON?

Overall, we would not rate SCMON as a very transparent tool. We would most likely prefer to avoid this transaction if possible. And this gets to one of the primary issues of the introduced tools — there is no evaluation of the tools’ quality. They are presented as items that should be used.

S/4HANA Migration Cockpit

The following is from the presentation on Migration Cockpit for 1808/1809

This explanation gives us little confidence. 

Notice the migration process is declared. Notice the “Lab Preview” label on the screen. It is pretty typical that the item is still being developed. This document was written in Dec 2018, roughly four years after S/4HANA was introduced, and SAP has not even finished the development of its remediation tools. SAP is very happy to rush S/4HANA out the door without having tools to support the remediation, and who knows when this screen will be complete and the functionality ready to use? 

An Unbiased Review of SAP’s Utilities

One of the critical topics to consider is how much success SAP has had with introducing “helpful” utilities like this. In our view, very little. Therefore, each of these tools offered by SAP must be analyzed rather than used.

The Migration Object Modeler 1809 (This is part of the S/4HANA Migration Cockpit)

Here is a primary introductory screen. 

(Video Removed by SAP)

This supposedly simulates how the value in the upload file will be imported to the S/4HANA target system.

This graphic implies that two categories of data sources go into the Migration Cockpit, are entirely organized, and then are sent to either on-premises or cloud S/4HANA. This is a massive oversimplification of what occurs. This type of graphic is often put out by SAP marketing and is designed to make everything look easier than it is. 

Use the SAP Solution Manager Custom Code Lifecycle Management Tool

Notice the following quotation about the CCLM.

“The SAP Solution Manager tool Custom Code Lifecycle Management (CCLM) can retrieve the usage data from your productive system and visualize them for your convenience. Based on the graphical presentation you get better transparency of the usage of your custom ABAP code and can easier analyze it then using only UPL technical data.”

The ABAP Test Cockpit

We have heard of little feedback on this tool. The image is from the article in the SAP Blog.

The Simplification List

This is a list of changes that are updated per release. It has nothing to do with what has been simplified and is simply about what has changed. However, one issue to consider is that Simplification Lists are incredibly lengthy and time-consuming to read. This tends to be left out of any discussion around the list. Notice the complication involved in comparing to the Simplification List.

Second, you need to fix SAP HANA and SAP S/4HANA findings. Adapt your custom ABAP code, using the findings of the SAP HANA and SAP S/4HANA checks (ATC results).Findings of SAP S/4HANA checks are related to S/4HANA Simplifications. Each simplification requires a different approach to solve findings. Therefore, findings of SAP S/4HANA checks refer to a SAP Note which describes how you can solve them. – SAP Blog

Here it is expressed that each S/4HANA change needs to be checked against their SAP OSS Note.

The SAP blog is good enough to include the major simplifications.

2215424 Material number field length extension
2198647 Data model changes in SD
1976487 Data model changes in SAP S/4HANA Finance
2220005 Data model changes in Pricing and Condition Technique
2214585 Sales support is not available
2223144 Foreign Trade is not available
2206980 Data model changes in Material Inventory Management
2227579 Storage Location MRP
2226131 Public Sector specific fields in Business Partner
2296016 Removal of orphaned objects

SAP’s Recommendation for Going Forward

In addition, your custom code needs to be checked with ABAP Test Cockpit (ATC) against the SAP S/4HANA simplifications in the Simplification Database and for any SAP HANA related changes. The result is a list of findings where your custom code does not comply with the scope and data structure of SAP S/4HANA. At this step, you can estimate the required effort required to adapt the custom code to migrate to SAP S/4HANA.

This is itself an oversimplification. This means only that the information is partially available to perform any analysis.

The Absence of the Legacy System Migration Workbench

SAP removed the LSMW as a migration tool, although it is still part of S/4HANA. This is covered in the following quotation from note 2287723.

The Legacy System Migration Workbench (LSMW) should only be considered as a migration tool for SAP S/4HANA for objetcs that do not have interfaces or content available after carefully testing for each and every object. The use of LSMW for data load to SAP S/4HANA is not recommended and at the customer’s own risk.

Using Benchmarks for Remediation Estimation

Companies will face a question of how much effort to put into the remediation analysis. Companies usually will not want to fund a full remediation analysis. Instead, they will want to estimate what that remediation will entail in terms of effort, time, and money. Let us review these statistics from GekkoBrain.

450 priority 1 issues

29,019 priority 2 issues.

After runtime usage filtering, we typically remove about 50% of the issues, which in the above case left us with 14,573 priority 1 and 2 issues.

With approximately 20 minutes per issue, this amounts to 607 days work!

So this is a very back-of-the-envelope calculation. Here is the more detailed math.

14573 * 20 min = 291,460 minutes.

Now we take 291,460 / 60 min to get 4,857.66 hours. 4,857.66 hours / 8 give 607 days of work.

Now at this point, the project planning, of course, must include the identification of resources. We have to be careful with this next step so as not to only project duration without knowing if the resources are available and, of course, the productivity of each resource.

There are 260 workdays in a year. If three developers are used, one ends up with .77 of a year or 9.24 months. One of the things that can be appealing is to add more developers. But one cannot necessarily add more developers to a job, as explained in the Mythical Man-Month book.

His observations on this topic are explained below:

He had added more programmers to a project falling behind schedule, a decision that he would later conclude had, counter-intuitively, delayed the project even further. He also made the mistake of asserting that one project—involved in writing an ALGOL compiler—would require six months, regardless of the number of workers involved (it required longer). The tendency for managers to repeat such errors in project development led Brooks to quip that his book is called “The Bible of Software Engineering”, because “everybody quotes it, some people read it, and a few people go by it”.[1] The book is widely regarded as a classic on the human elements of software engineering.[2]

Brooks discusses several causes of scheduling failures. The most enduring is his discussion of Brooks’s law: Adding manpower to a late software project makes it later. Man-month is a hypothetical unit of work representing the work done by one person in one month; Brooks’ law says that the possibility of measuring useful work in man-months is a myth, and is hence the centerpiece of the book.

Complex programming projects cannot be perfectly partitioned into discrete tasks that can be worked on without communication between the workers and without establishing a set of complex interrelationships between tasks and the workers performing them.

As S/4HANA implementations become more common, estimation errors in code remediation will increase. And it is quite likely that the mythical man month will be applied yet again to try to push S/4HANA implementations to be performed earlier than they should be. At the forefront of this will be SAP and SAP consulting firms that will make valiant efforts to have their customers underestimate code remediation time and complexity.

 A Two-Step Process

Therefore, the estimation is a second part of the process after the initial data has been extracted from the SAP system.

Conclusion

• The information published by SAP on code migration is not well formulated and filled with contradictions and bad advice with more of a sales/marketing orientation than a technical orientation. In the wide-ranging SAP analyses that we have performed, this is one of the most confusing areas. SAP’s terrible explanations about code remediation pose a major risk to S/4HANA implementations. 
• Its mini-project is simply learning the tools and the effort involved in code remediation. One of the critical topics to consider is how much success SAP has had with introducing “helpful” utilities like this. In our view, very little. Therefore, each of these tools offered by SAP needs to be analyzed rather than simply used.
• The steps, as explained by SAP, are quite a lot of work. Testing the tools presented by SAP shows that they can often be more work than worth. They also create an unrealistic expectation on the part of the customer that the work will be faster than they think.
• The large amount of work in custom code remediation shows why the average implementation time estimates from SAP and their published case studies are ridiculous. And why the Florida Crystals claim to have “upgraded” from ECC to S/4HANA, as we covered in The Florida Crystal S/4HANA Case Study is pure fantasyland. Not only doing the work, by analyzing the work to be done is a serious research effort. There are many different ways of performing the remediation, and the first part of any remediation is figuring out the likely best methods to use to complete the task.

A rather surprisingly candid explanation of the task of code remediation is found in the following quotation.

There’s no hiding the fact that this is an involved task. Almost every HANA-readiness project we’ve been a part of has required fixes for tens of thousands of incompatible code instances. Usually, it’s a case of months, or even years, rather than weeks.

Unfortunately, it’s impossible to say exactly how much time any individual instance of incompatible ABAP code will take to fix.

In our experience, the majority of issues take an hour or less to fix, but when you’re trying to plan a HANA-readiness project containing tens of thousands of issues, loose estimations will result in widely inaccurate forecasts.

For example, if you have 20,000 issues to fix but the estimation for each issue is out by just 15 minutes, it will result in your forecast being incorrect by over 150 working days.

The only way to gain an accurate estimation of how long it’ll take to fix your custom code and get HANA-ready is to go through and assess each issue individually – a time-consuming but ultimately worthwhile process to better plan the project. Staying on top of your HANA-readiness project can feel like a full-time job in itself. Just keeping track of which code items have been fixed, which are currently being worked on, and which are still unresolved isn’t easy when there are tens of thousands of issues that need to be adapted.

Any HANA-readiness project is extremely time-consuming and each one will take a different length of time – making it difficult to stick to pre-agreed budgets. However, using a tool like Gekkobrain can help reduce the pressure by automating some time-intensive tasks.

Although you’ll still need to manually adapt any incompatible custom code, Gekkobrain provides a clear list of code items that need fixing and an estimate of how long it’ll take, as well as giving you the tools needed to effectively and efficiently manage the project. – GekkoBrain

And of course, we were not surprised to read the partner list on the GekkoBrain website and find that they are not a partner with SAP. This type of disclosure would not be allowed if GekkoBrain were an SAP Partner.

GekkoBrain provides an impact analysis of the different remediation issues. Notice some of the problems are SQL errors, and also notice that the items or issues are coded by complexity level and by their impact. 

Notice there is also an hour estimate per issue. 

This shows the top right item, the source, and the lower, which is the code fix. Notice how the select statement has been significantly changed.