How to Respond to SAP’s Arguments Against AWS and GCP

Last Updated on May 4, 2021 by

Executive Summary

  • SAP makes continuous arguments against AWS and GCP.
  • How valid is this argument against the cloud from SAP?

Video Introduction: How to Respond to SAP’s Arguments Against AWS and GCP

Text Introduction (Skip if You Watched the Video)


SAP consulting partners usually will only know how to repeat the arguments that come from SAP. SAP consulting partners intend to denigrate both the other systems used by a customer and promote SAP Cloud. This is true even though very few SAP consultants use SAP Cloud. In the mind of the SAP consulting partners, SAP works best when 100% SAP is used. SAP applications, SAP databases, SAP infrastructure, and SAP development tools are strictly supported without ever needing to justify usage. You will learn what SAP consultants say about SAP Cloud versus our analysis.

Our References for This Article

If you want to see our references for this article and other related Brightwork articles, see this link.

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

  • This is published by a research entity.
  • 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. 

Not Being Able to Meet Requirements Does Not Count Against SAP?

In the mind of SAP and SAP consultants, any lack of ability of SAP’s applications to meet requirements can be attributed to either a lack of business process re-engineering or to custom coding in SAP, using SAP development tools and SAP’s proprietary coding language. It is the preferred strategy to recode any “legacy” application used by the customer into SAP.

SAP’s Connection to IaaS Providers

SAP has made accommodations for non-SAP IaaS. One can use SAP on AWS, Google Cloud, and Azure. We covered the topic in SAP’s Multicloud Announcement.

As of this book’s publication, there are 92 SAP related items available on the AWS Marketplace. This is, however, misleading as many are slightly different versions of the same basic thing. Most of the offerings are either HANA or the Adaptive Server Enterprise. The Adaptive Server Enterprise is one of the most confusingly named products, and it is a database. It was renamed from the Sybase DB, which SAP acquired.

The Real Point of Offering HANA and Adaptive Server Enterprise on AWS

Looking at the HANA offerings, they appear to be more out on AWS for marketing purposes or more specific to get traction for these products and exposure rather than serious usage. The problem is that SAP’s databases are not competitive versus the other items AWS offers.

If we take the HANA database, it is a problematic database both from cost and maintenance overhead. If HANA is used with all manner of liabilities, both technical and license/legal, as we covered in the article The HANA Police and Indirect Access Charges. SAP is offering license-free versions for developers to work with. Once a company tries to activate it for production, the costs will dramatically rise. Then, they will run into other limitations, such as HANA’s limitations in clustering.

This is how SAP “boobie traps” its AWS offerings. Furthermore, HANA is a way for SAP to take over the data layer at companies, proposing that every database that touches HANA must either be HANA or pay extra fees to SAP.

There are indeed limitations in running SAP on AWS and Google Cloud. However, the problem is that SAP resources are not a good source of information on this topic, as they are told by SAP that the objective is to get customers to adopt the SAP Cloud, as it is standard. This is particularly true if the SAP consultant works for a company that is a partner with SAP. As we cover in the article How to Best Understand the Pitfalls of Vendor Partnerships with SAP, SAP partners’ consulting companies lack any autonomy from SAP.


The best way to handle SAP’s objections that customers should access the SAP Cloud instead of alternatives is by having the real story about how SAP setup their cloud to work against their customer’s interests and reinforce SAP’s account control.

The information provided to customers about both SAP Cloud and AWS and Google Cloud is unreliable. SAP allows customers to access AWS, Google Cloud, and Azure, but not in a way that makes any sense to use SAP Cloud. We can see no justification for using SAP Cloud when customers can open AWS and Google Cloud accounts and access many more options without SAP’s exorbitant markup. If customers use SAP or SAP consultants to consult on the cloud, it will lead to inferior outcomes. First, SAP has no idea what they are talking about when it comes to cloud, and second, all advice will lead right back into the clutches of SAP. SAP is also struggling with how to jam as much of their investments into on-premises technologies in the cloud context. ABAP is a perfect example of this, but there are many others. The SAP consulting firms are incentivized to redirect any customer questions about cloud back to SAP Cloud, a non-starter as far as all three of the authors of this book are concerned. Those customers looking for advice on leveraging AWS or Google Cloud (that is, real cloud) for their SAP environment need to find advisors who are not SAP partners.