How to Understand SAP’s Advice on S/4HANA 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) for helping the client rather than helping SAP.


SAP has published its perspective on remediating code for S/4HANA. Both SAP has its consulting partners have consistently underrepresented the complexity involved in code remediation to customers in order to make the migration to S/4HANA 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.

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 any rhyme or reason or any controlling entity coordinating the information.

  • Our conclusion is that SAP’s degenerate organization of information around S/4HANA code migration is going to lead to inefficient code remediation projects.
  • Whatever the actual level complexity of S/4HANA code remediation, SAP has made the issue far worse though how it has created tools and communicated 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 also indicate a great deal of frustration or confusion as to how code remediation for HANA and S/4HANA is supposed to work.

How SAP views the overall migration.

The more that 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? So easy in fact, that PwC directors are commenting that it is quite 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 obvious contradictory data points to the project estimates that are being proposed by consulting firms that are simply 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 quotation is certainly 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.”

In order 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 in part true but greatly overstated by SAP and SAP consulting firms. This is in great part an attempt to make customers think that they need nearly no custom code.

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

SAP has a specific strategy for misleading customers when their predictions around the usage of their system turn out to be 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?

Something that SAP does not want to discuss is how much poor quality code is running at SAP customers. Much of this code was written by consultants who work for the major SAP consulting firms, which is one of the worst environments in which to perform 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 questioning.

“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 it makes sense to find and root out unused custom code. It is important to consider that SAP has a specific intent when they discuss coding. They are reverse engineering their data to fit the conclusion, which is that customers don’t need custom code. However, all of the evidence, once gathered independently of SAP 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 to the S/4HANA Simplification database. 

It is 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 is essentially proposing that you can 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, S/4HANA has a smaller functionality footprint than ECC, after all these years. And some functionality that companies rely upon has been eliminated. So that means companies will need to add extra custom code, but there is no mention of this fact at the SAP blog.

Adjusting ABAP to Run on HANA

This is one of the few areas where SAP admits where 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 everyplace that SQL is written in the customization.

However, this is just the remediation, not the optimization phase. Notice the following quotation which explains that there is 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 the conclusion of Brightwork Research & Analysis that 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, as well as in the article Which is Faster HANA or Oracle 12C?

Getting Terrible Advice About HANA From SAP Consultants

Olga Dolinskaja has done no research on 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 prior to 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 extremely 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 own development has a problem optimizing SQL for HANA, so this 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 having to use a language which processes the data and then later applies it to the database like HANA. And there is nothing particularly proprietary about SAP HANA. HANA was simply 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 explains 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. But it is true that 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 such that it is confusing to know which tool to use. Part of this is because the coding remediation tools have turned over, and new ones have been introducing obsolescing the old tools. Some of these tools have been introduced too quickly and were not complete.
  2. These tools have not proven to be useful and apply more overhead to the analysis then they give back in efficiency.
  3. There is a central problem with all of these tools, in addition to the tiny amount of effort that SAP has put into developing the tools. And that 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 the term “simplify” or “simplification” to describe anything that is involved in remediation. First, S/4HANA does not simplify anything, it is a major change requiring a major effort. Therefore, the information SAP provides is really not intended to help developers as much as it is to make it sound like the effort of remediation will be low. Once S/4HANA is sold on these pretenses, the SAP consulting firm can change order 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 simpler 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 true. 

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 actually 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.” It is important for SAP consulting companies 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 at the article The S/4HANA Implementation Buyer Intelligence Highlights.

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

As for remediation being 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

Certainly, it is good to reduce the custom code if possible, but once again the custom code was written for a reason. If SAP was able to 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. Most likely we would prefer to stay away from this transaction if possible. And this gets to one of the primary issues of the introduced tools — there is no evaluation of the quality of the tools. They are simply introduced 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. This is fairly typical that the item is still in development. This document was written in Dec 2018, roughly 4 years after S/4HANA was introduced, and SAP has still not finished its development of it remediation tools. SAP has very happy to rush S/4HANA out the door, without having tools to support the remediation, and who knows when this screen will actually be complete and the functionality ready to use? 

An Unbiased Review of SAP’s Utilities

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

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

Here is a basic introductory screen. 

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

This graphic seems to imply that two categories of data sources go into the Migration Cockpit, and are entirely organized and then sent to either on-premises or cloud S/4HANA. This is a massive oversimplification of what occurs. This is the type of graphic that is often put out by SAP marketing that 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 at SAP Blog.

The Simplification List

This is a list of changes that are updated per release. It has nothing to with what has been simplified and is about simply what has changed. However, one issue to consider is that Simplification Lists are extremely lengthy and very 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 own 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 the 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

One question that companies will face is how much effort to put into the remediation analysis. Companies normally will not want to fund a fully remediation analysis, but rather will want to determine an estimate of 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 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. Because we have to be careful with this next step so as to not simply 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 just add more developers to a job as is explained in the book the Mythical Man Month.

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 in order to try to push S/4HANA implementations to be performed earlier than they should be. At the forefront of this will be both SAP and SAP consulting firms that will make valiant efforts to have their customers to underestimate the time and complexity of code remediation.

 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.


  • The information published by SAP on code migration is both not well formulated and filled with both contradictions and bad advice that has 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. 
  • Simply learning the tools and the effort involved in code remediation is its own mini-project. One of the important topics to consider is how much success has SAP had with introducing “helpful” utilities like this. In our view very little. Therefore each of these tools that are being offered by SAP really needs to be analyzed, rather than simply used.
  • The steps as explained by SAP are quite a lot of work. Testing of the tools presented by SAP show that they can often be more work than they are 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 so 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 what are the likely best methods to use to perform 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 issues are SQL errors and notice also 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, which is the original source, and the lower which is the code fix. Notice how the select statement has been significantly changed. 

The Problem: The Available Information on S/4HANA

There are two fundamental problems around S/4HANA. The first is the exaggeration of S/4HANA, which means that companies that purchased S/4HANA end up getting far less than they were promised. The second is that the SAP consulting firms simply repeat whatever SAP says. We can provide feedback from multiple S/4HANA accounts that provide realistic information around S/4HANA– and this reduces the dependence on biased entities like SAP and all of the large SAP consulting firms that parrot what SAP says. We don’t think that code remediation is a small issue or should be covered up as the major consulting firms do, which is why to recommend pulling forward code remediation.

Being Part of the Solution: What to Do About S/4HANA

Obviously the best strategy is to fight bad information with good information. We offer fact-checking services that are entirely research-based and that can stop inaccurate information dead in its tracks. SAP and the consulting firms rely on providing information without any fact-checking entity to contradict the information they provide. This is how so many companies failed with S/4HANA. They had biased information that could not be trusted and this has cost those companies dearly.

In the case of code remediation, SAP and consulting companies are trying to make potential S/4HANA customers to underestimate the degree of code remediation, when in fact it is a serious issue. Customers tend to be surprised by how much code must be cleaned as part of an S/4HANA migration.

The Necessity of Fact Checking

We ask a question that anyone working in enterprise software should ask.

Should decisions be made based on sales information from 100% financially biased parties like consulting firms, IT analysts, and vendors to companies that do not specialize in fact-checking?

If the answer is “No,” then perhaps there should be a change to the present approach to IT decision making.

In a market where inaccurate information is commonplace, our conclusion from our research is that software project problems and failures correlate to a lack of fact checking of the claims made by vendors and consulting firms. If you are worried that you don’t have the real story from your current sources, we offer the solution.

If you need independent advice and fact-checking that is outside of the SAP and SAP consulting system, reach out to us with the form below or with the messenger to the bottom right of the page.

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.

S/4HANA Implementation Research

We offer the most accurate and detailed research into S/4HANA and its implementation history. It is information not available anywhere else and is critical correctly interpreting S/4HANA, as well as moderating against massive amounts of inaccurate information pushed by SAP and their financially biased consulting ecosystem.

Select the description that best matches you.

Option #1: Do You Work in Sales for a Vendor?

See this link for an explanation to sales teams.

Option #2: Do You Work for an Investment Entity that Covers SAP?

See this link for an explanation for investment entities. 

Option #3: Are You a Buyer Evaluating S/4HANA?

For companies evaluating S/4HANA for purchase. See this link for an explanation to software buyers

Search Our Other SAP Custom Code Content


How Long Does it Take to Adapt Custom Code for SAP HANA?

How to Choose an ABAP Code Migration Tool for SAP HANA

How to Manage 25,000 Small Issues with SAP Code?


How Long Does it Take to Adapt Custom Code for SAP HANA?

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