How SAP Used and Abused the Term Legacy

ByPrimary Researcher

Executive Summary

  • There is a history of the term legacy systems in IT.
  • SAP provides false information regarding their ability to replace legacy.

Introduction

As part of my series on SAP as legacy, which began with How SAP is Now Strip Mining Customers, I wanted to write an article to describe how SAP and other vendors deliberately misused the term legacy over the past several decades. In this article, I will show how important the adoption of words like legacy is and how they shape opinions and influence purchase decisions.

So to begin, let us review the term legacy as it applies to systems.

Our References for This Article

If you want to see our references for this article and other related Brightwork articles, see 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. 

The Definition of the Word Legacy or Legacy System in IT

“In computing, a legacy system is an old method, technology, computer system, or application program, “of, relating to, or being a previous or outdated computer system.”[1] Often a pejorative term, referencing a system as “legacy” means that it paved the way for the standards that would follow it. This can also imply that the system is out of date or in need of replacement. By the 1980s it was commonly used to refer to existing computer systems to distinguish them from the design and implementation of new systems. Legacy was often heard during a conversion process, for example, when moving data from the legacy system to a new database. While this term may indicate that some engineers may feel that a system is out of date, a legacy system may continue to be used for a variety of reasons. It may simply be that the system still provides for the users’ needs. In addition, the decision to keep an old system may be influenced by economic reasons such as return on investment challenges or vendor lock-in, the inherent challenges of change management, or a variety of other reasons other than functionality. Backward compatibility (such as the ability of newer systems to handle legacy file formats and character encodings) is a goal that software developers often include in their work.Even if it is no longer used, a legacy system may continue to impact the organization due to its historical role. Historic data may not have been converted into the new system format and may exist within the new system with the use of a customized schema crosswalk, or may exist only in a data warehouse. In either case, the effect on business intelligence and operational reporting can be significant. A legacy system may include procedures or terminology which are no longer relevant in the current context, and may hinder or confuse understanding of the methods or technologies used.” – Wikipedia

The term legacy should not be confused or mingled with the term obsolete.

Secondly, a legacy system does not have a specific timeframe for replacement.

An Implied Timeframe for Replacement?

This is explained by more of the quotation from Wikipedia:

Organizations can have compelling reasons for keeping a legacy system, such as:

“The system works satisfactorily, and the owner sees no reason to change it. The costs of redesigning or replacing the system are prohibitive because it is large, monolithic, and/or complex. Retraining on a new system would be costly in lost time and money, compared to the anticipated appreciable benefits of replacing it (which may be zero). The system requires near-constant availability, so it cannot be taken out of service, and the cost of designing a new system with a similar availability level is high. Examples include systems to handle customers’ accounts in banks, computer reservations systems, air traffic control, energy distribution (power grids), nuclear power plants, military defense installations, and systems such as the TOPS database.” – Wikipedia

All of this illustrates that a legacy system can still be adding a great deal of value.

However, through time SAP never applied this concept to the term. Instead of SAP, designating a system as a legacy was seen as a way to identify it as the replacement and as a replacement by an SAP system, of course.

How the Term “Legacy” Evolved Over Time

The final portion of the definition from Wikipedia on legacy demonstrates that the term legacy evolved.

“Alternative view[edit] There is an alternate point of view — growing since the “Dot Com” bubble burst in 1999 — that legacy systems are simply computer systems that are both installed and working. In other words, the term is not pejorative, but the opposite. Bjarne Stroustrup, creator of the C++ language, addressed this issue succinctly:

“Legacy code” often differs from its suggested alternative by actually working and scaling.

— Bjarne Stroustrup
IT analysts estimate that the cost of replacing business logic is about five times that of reuse,[citation needed] and that is not counting the risks involved in wholesale replacement. Ideally, businesses would never have to rewrite most core business logic; debits must equal credits — they always have, and they always will. New software may increase the risk of system failures and security breaches. The re-examination of attitudes toward legacy systems is also inviting more reflection on what makes legacy systems as durable as they are. Technologists are relearning that sound architecture, practiced upfront, helps businesses avoid costly and risky rewrites in the first place. Poorly designed systems often don’t last, both because they wear out and because their reliability or usability is low enough that no one is inclined to make an effort to extend their term of service when replacement is an option. Thus, many organizations are rediscovering the value of both their legacy systems themselves and those systems’ philosophical underpinnings.” – Wikipedia

Legacy Equals “To Be Replaced by SAP”

And in fact, many of the systems designated as a legacy by SAP were never replaced by SAP. This was one of the frequent disappointments on the part of companies that purchased SAP, particularly SAP’s ERP system, which often bought SAP ERP, and other ERP systems to obtain a simplified system landscape and drive down costs.

However, the proposition was never particularly accurate as SAP ERP never maintained the breadth of functionality necessary to decommission so many legacy systems. And the concept of best practices contained in SAP was also similarly oversold. This is explained well by a quote from KC Richards, a consultant with decades of database and development experience.

“My first encounter with the term “Legacy Systems” was during the adoption period of RDBM systems, the mid to late eighties. Yes, there was a time when you could put your job in jeopardy by even suggesting that you would include a “Relational Data Base Management System” in software architecture. ISAM, flat files, and other creative indexing techniques were a safe way to go. In the decade before, Dr. Codd (IBM System R – “In Codd we Trust”) and Michael Stonebraker (Ingres) were competing over the definition of what exactly made up a relational database and what was the most logical data manipulation languages. SQL or QUEL?

Each of the pioneers of relational theory was working on their own products. Larry Ellison was porting his RDBMS on every hardware platform her could find. Sybase was working with Microsoft to license “Data Server”, a database product originally built to run on UNIX computers. That work led to a product called Ashton-Tate/Microsoft SQL Server 1.0 (I remember being a beta user). Anything on a RDBMS was Avant-guard, everything else became “legacy”.

Repeating Historical Patterns in IT

I found this point of KC Richard’s quotation, particularly of interest. Here is why, and it is quite pertinent to SAP. According to SAP, relational (actually row-oriented) databases are now legacy, and column-oriented databases are recommended by SAP.

As I have covered in multiple articles on HANA, such as When Articles Exaggerate HANA’s Benefits, this is an oversimplification. Column-oriented databases have a specific purpose, and their benefits do not generalized to all usage types.

Let us continue where KC Richards states:

“Then came the next generation of “legacy” markers. “If you were not GUI, you were chewy” Then “Legacy Systems” were those not written in “newer” object-oriented languages to take advantage of newer hardware platforms. “Legacy Systems” became those that didn’t have GUI screens. Windows 3.1, Macintosh, and OS/2.

Legacy has become that term used to conveniently play on the fears of a company that defines define where its sunk costs rest, usually because they have lost track of what they expect of a system. Oddly enough, data entry is still more efficient on green screens than GUI applications. Legacy systems are simply what you have when you get them.”

This gets to a great point by KC Richards.

What is the legacy?

  • Is legacy a term that we accept as what is trendy at the time?
  • Is it about usage or about what is new?
  • Are software vendors using this term honestly, or is this marketing and perception?

SAP’s Relationship with the Word Legacy

They would declare all systems that were developed in-house as a legacy.

But that is not the correct use of the term. Legacy systems are the systems for which companies want to reduce their maintenance and future investment. But they are not necessarily systems that can be economically replaced. For example, there were many things that home-built systems did that still were required and that SAP would never do.

Porting the functionality to SAP does not solve this fundamental issue. You are merely porting code to SAP, but that does not mean SAP is “actually doing it.” That is just a ported code.

Also, as we are on the topic, why port code to SAP in the first place? Why not only keep the existing system working and integrate these systems into SAP. When porting to SAP, it means a portion of what was, in most cases, an open language like C to a proprietary language of ABAP, which does not have a similar development efficiency.

This means that maintenance and costs invariably increase. This is how SAP radically increased the costs for a large number of companies. The TCO for SAP systems was far higher than anyone anticipated, and the prices of customizing SAP were higher and are now more rigid than creating customizations in open systems. SAP’s development approach and ABAP can be considered the “legacy” of going with SAP, which meant the adoption of their vision of development.

The Statements About All Non-HANA Databases as Legacy

This is from SAP’s website.

Here SAP proposes that all other databases are outdated technology. They also imply that only HANA has in-memory architecture and that it is revolutionary. We will address each of these claims.

This is where the term legacy is used.

SAP expanded on how all non-SAP databases were legacy in the following quote from the PR release, SAP’s Bet Seems to be Paying Off.

Yesterday’s databases can’t solve modern problems, SAP HANA can. That’s the message that SAP will keep repeating as its Spotlight Tour travels the world. The business users will no doubt be eager to hear about how digitizing their enterprises will unleash new opportunities. The geeks in the audience will want to get their hands on cool, new tools. But someone is going to need to do the work and pay the tab.

In a world of open source, and what may appear to be cheaper solutions, getting the C-suite, IT, and accountants on the same page may not be an easy job. But SAP has a huge customer base and more than four decades of marketing experience to rely on and, so far, it seems to be doing something right.

Oracle 12c, MySQL, Microsft SQL Server, PostgreSQL are not yesterday’s databases. This is a titanically inaccurate statement that would only be made by someone intent on misleading the reader. HANA does only one thing well and cannot beat out databases designed to do that one thing (read access for reporting). SAP does keep repeating this message, but it just happens to be false.

Enterprises are already digitized. This occurred decades ago. Digitization means when information is placed into ones and zeros. Who this statement is tricking is a mystery to us.

The clear direction in databases is towards open source. Google built its infrastructure on open source. AWS is mostly open source. HANA is the most expensive database we track and has been relentlessly exaggerated by SAP and their surrogates since its introduction, as covered in the article When Articles Exaggerate the Benefits of HANA.

What SAP Did with Casting All Non SAP Databases as Legacy

SAP said that all data was loaded into memory. Now, naturally, there is data copied to disk. But SAP stated that everything was loaded into memory all at once, and they put down other vendors that performed memory optimization. Years ago, we found the contrary in SAP’s technical documentation around HANA. But the opposite (all in memory) was a significant marketing and sales point for HANA, and vendors like Oracle and IBM and others that proposed this was not realistic were called “legacy databases.” SAP still calls all other databases it competes against “legacy databases,” even though HANA mostly follows the same design (it specs massive hardware and memory, but HANA cannot adequately address the memory). This leads to one question:

“why are other database legacy?”

At SAPPHIRE 2019, Hasso claimed that over 200 peer review studies all proved that HANA had produced these great benefits over “legacy databases.” This is not possible. Furthermore, we found these studies do not exist as we covered in the article How Accurate Was Hasso Plattner About SAP HANA Publications?

Evaluation of SAP’s Claims

First, SAP is a more recent database than IBM BLU, Oracle 12c, and Microsoft SQL Server. However, SAP is in no position to call any of these databases legacy. This is because these databases outperform HANA, as we cover in the article What is the Actual Performance of HANA?

Legacy means that the item is near obsolete.

This a ludicrous claim for any of these databases, all of which have many times more installations than HANA. Unlike HANA, all three of these other databases are used outside of SAP with non-SAP applications. SAP cannot claim this, which provides an inkling as to the competitiveness of HANA.

This claim is so exaggerated that…

Ding Ding Ding!

We award SAP a Golden Pinocchio for making this proposal.

The comment is so divorced from reality and so false that there is no other conclusion than SAP is undoubtedly aware they are deceiving readers by publishing these statements.

Other Claims

Now let us review the other claims made in the SAP statements.

  • All other Databases are Outdated Technology?: That is an enormous claim. What evidence has SAP produced that this is true? Information coming back from actual projects indicates that HANA cannot keep up with the performance of previous-generation databases outside of data warehouse type queries (where it loses against the updated versions of these other databases). The details of this are covered in the article HANA as a Mismatch for S/4HANA and ERP.
  • HANA has Revolutionary In-Memory Architecture: This claim is also false, as we cover in the article How to Understand Why In-Memory Computing is a Myth.
  • ACID Compliance?: ACID stands for (Atomicity, Consistency, Isolation, Durability). They are fundamental requirements of a database. Every single one of the databases that HANA competes with is ACID compliant! And they have been for decades. This is equivalent to General Motors, saying that its cars are better than competitors because they use spark plugs. Why would SAP say such a thing? Most likely, because their readers do not know what ACID compliance is, they think it is different.
  • Only HANA Can Support High-Speed Analytics?: This is news to every database vendor that competes with SAP. All of these databases can support high-speed analytics. Again, HANA loses against its primary competitors in analytics if those databases are the most up-to-date versions. The older version will lose against HANA in analytics because they lack the column-oriented store. SAP is continually attempting to have HANA compete against databases from vendors from six years ago when HANA was first introduced. Of course, HANA on new hardware will beat other databases on older hardware. Something quite obvious, but which is missed by IT departments that implement HANA on new hardware and discuss the improvements — without accounting for the percentage of performance, which is solely due to the hardware. Did we cover this topic in the article, How Much is Hardware Responsible for HANA’s Performance?
  • Only HANA Has Application Services?: Application Services are a bit of a nebulous term. But they are applications. Oracle 12C, IBM Blu, and MS SQL Server run applications. Applications sit on top of them. Therefore, this is a curious way to differentiate HANA. This seems to imply that HANA is unique because it can interoperate with applications. If it couldn’t, then what would it be doing?
  • Only HANA has a Flexible Data Acquisition?: Why is that true? More flexible than competitive offerings? A database stores data. Data acquisition is usually performed by middleware. Of course, it depends upon the definition. If SAP’s definition of acquisition is that data can be loaded in different ways into the database, all of the competing databases have this ability.
  • HANA has a Single Platform?: HANA is not a platform. HANA is a database. If SAP means that both the applications are offered by SAP as is the application — then this is true. But because SAP is not as good with databases as its competitors, this also means that HANA buyers give up specialization and many other factors to buy their application and database from the same vendor.
  • Only HANA has no Data Duplication?: It is unclear why HANA offers less data duplication than competing databases. In fact, because of bizarre license restrictions, we are aware of scenarios where HANA has a 100% level of data duplication. This is explained in the article HANA Police and Indirect Access Charges. Here SAP requires companies to buy a second HANA license and replicate all data between the two HANA instances to allow data to be moved to a third database.

Misuse of the Term Legacy

There is a distinction between legacy and obsolete.

Let me provide a specific example, which is the US rail system.

The US Rail System

The US has roughly 98,000 miles of railroad track. This track is old, but it is not legacy. And why not provides valuable insights as to how the term legacy should be used.

  • Rail is far more fuel-efficient and cost-effective than motor transport.
  • The US would have a tough time delivering freight without this rail system.
  • Maintenance should not be minimized on the US network of rails; in fact, maintenance should be kept high. The US should not shrink the total number of miles of track (as we have in the past) but should expand them to take freight off the roads, which is a highly energy-intensive and polluting way to move freight.

Now let us look at another system.

The US Road System

The US has around 4 million miles of roads. Most of these roads were built after the rail network. There have most likely been too many miles of roads created. This is primarily because they were created during a time of low-cost oil. Due to global consumption versus available supplies, this looks sure to not be the case in the future. The automobile’s proliferation is causing human civilizations to use up the global petroleum stock far faster than it would have the automobile not seen such extensive usage.

Therefore, while some of the 4 million miles of roads are needed, some will probably be legacy as auto travel will need to come down in the coming decades.

While the US’s road network is partially legacy, none of the rail networks would qualify as legacy. Thus, the items’ age is not the primary driving factor in determining whether something should be considered legacy. Legacy is all about usage or expected usage.

That is, legacy is all about usage or expected usage, not age.

Towards an Accurate Usage of the Term Legacy

In this article, I am attempting to describe the term legacy by its objective definition. I don’t make more money if people use it correctly; I don’t make less money if people use it correctly. However, the same cannot be said for software vendors.

I don’t know how all the software vendors use the term legacy, but I study SAP documentation and SAP statements, and I know how SAP uses the term legacy. When SAP uses the term legacy, they mean any applications that their customer built. Or when a competitor develops that application. SAP used the term legacy to describe all CRM systems that are not SAP’s CRM system.

SAP used the term inaccurately and in the most self-centered and disrespectful sense to diminish the customers’ systems. SAP very much pushed forward the concept and the highly dubious concept of best practices that seek to propose and to propose falsely that all business processes either fall into SAP’s software flows, or they are illegitimate. SAP continues to make this argument regarding customizations for its new ERP system, S/4HANA.

“Another key “how” question we hear S/4HANA adopters frequently debating is their approach to customization. Typically, customers have tended to heavily customize their existing SAP ECC on-premise deployments and, in moving to S/4HANA, organizations can rethink their business processes, which may result in more simplicity and avoid the need for a lot of customization.” – ASUG

*This quote is from ASUG, but as ASUG is simply a marketing arm for SAP, I do not draw any distinction between statements from ASUG and statements from SAP. This is SAP’s position on customizations. SAP was wrong when it proposed that customers would be able to move to “best practices” with earlier versions of their ERP system, and they will be wrong again when S/4HANA is broadly implemented. 

Go to top

Conclusion

SAP misused the term legacy on countless sales engagements. They used the term as a term of propaganda. So what does that mean? When a term is used this way, it is used not to describe something accurately but just the opposite. The user intends to describe inaccurately and make the listener more amenable to the message.

A second important characteristic of what defines when a term is used as propaganda is that and often without having to provide evidence to support the claim. And if we observe how SAP used the term legacy, there was never a case-by-case analysis of companies whether the functionality could be replaced by SAP. Whether it was a good idea to customize it into SAP if it could not be replaced, etc.. That would have taken a lot of work. In many cases, the outcome would have been both that SAP did not have the functionality and made no sense to port the functionality to SAP. But most executive buyers preferred not to do this work and buy whatever was a trend (what everyone else was buying).

It was much easier to use the blanket term legacy to paper over or obscure all of that analysis. Rather than being analytical, the use of the term legacy seems specifically designed to appeal to emotion and fashion. To a concept of there being an “in crowd ” and an “out crowd.” Companies wanted the new great stuff that SAP offered and did not want to be stuck with “legacy.” One wonders how many decisions to go with SAP or other similar vendors when this term was in its heyday, to present the impression that the company was hip and with the times.