- SAP has many complications in migrating SAP to the Cloud, which is not widely known.
- This article covers some of the many complications of moving SAP to the Cloud.
Video Introduction: How to Understand the Complications of Migrating SAP to the Cloud
Text Introduction (Skip if You Watched the Video)
SAP Cloud is something that not really cloud or does not meet the definition of cloud. Cloud is a technology and approach for improving IT efficiency. Therefore it is a problem when inefficient on premises vendors like SAP and Oracle co-opt cloud. The best way to leverage cloud for SAP is to bypass SAP’s cloud and use cloud service providers that enable one to connect custom development to SAP and other applications. You will learn how SAP intersects with cloud services with a special focus on SAP HANA and the cloud.
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.
SAP’s history has been not only on premises but more often bare metal rather than virtual machines.
Ravi Padmanabhan of Velocity Cloud explains this.
“The SAP application requires dedicated virtual machines not necessarily dedicated hosts – hence these hyperscalers provide lots of flexibility on how we deploy virtual machines. Depending on how you decide to utilize EC2 / GCE there are lot of economies that can be gained by customers who transform their SAP infrastructure to them.”
Any EC2 instance can run a non-production SAP application. However, for production SAP applications, it is necessary to use an SAP certified EC2 instance.
Where is SAP Cloud in terms of the number of VMs run in the Cloud? As usual, the top three cloud IaaS entities are again AWS, Azure, and Google Cloud. If customers are to initiate a VM, it will most likely be using AWS, Azure, or Google Cloud.
Dedicated Virtual Machines
However, a dedicated virtual machine is significantly different than are a shared virtual machine. For one, they cost more. This is simply a disadvantage when trying to migrate to AWS or Google Cloud.
There are restrictions in using some of AWS’s most popular offerings when it comes to using databases.
“Regarding Dynamo DB – yes this is not a certified database for the SAP core applications except for use as an extension on Hybris. The No SQL technology is not certified since the SAP application is traditional application as opposed to a Cloud Native hence they stay focused with certified databases on Oracle, SQL, ASE and HANA. There is enough flexibility for customers with the certified databases that I don’t see lack of Dynamo DB as a disadvantage. On RDS, this does not work well for SAP but is ok for Oracle applications. The reason is due to the nature of the database management structure within SAP – since this is primarily BASIS driven, using a web service like RDS does not make a lot of sense due to the database management capabilities that are inherent within the application itself. Regardless, RDS really is only a different way to purchase database licensing and management services – again I don’t see this as an inhibitor for SAP customers adopting hyperscale.”
Therefore these realities can seem at odds with the expectations of SAP to AWS migration.
“AWS manages the physical infrastructure up to the virtualization layer. The operating system and any SAP applications and databases running above the virtualization layer are managed by the customer. If a managed service is required, AWS has a network of partners that offer SAP consulting and managed services on AWS.”
Deploying SAP Databases on AWS
One can always migrate SAP to bare metal, but bare metal is merely hosting – it is moving the server from the customer location to AWS. It is not Cloud. The benefits come when migration takes place to a cloud, which means virtualization. Recall from our earlier explanation of what makes Cloud, the benefits of Cloud do not extend to simple hosting. If you look at AWS products assortment, only one, AWS EC2, would be relevant for SAP’s on-premises products. SAP has made many cloud acquisitions, such as SuccessFactors and Ariba, which do not have these limitations. However, for SAP’s internally developed products, and where SAP receives most of its revenue (ECC, BW, HANA, APO, etc.), this limitation applies. Bare metal servers are necessary for SAP application servers. To use anything else, you have to be able to integrate it with SAP ERP, but SAP PI/PO, SAP’s middleware application, is far from being able to do that.
The relatively smooth migration to the Cloud could be only on the HANA database. However, HANA does not support clustering. Clustering is set up to provide load balancing and fault tolerance.
AWS has a helpful definition of clustering.
“An Amazon Aurora DB cluster consists of one or more DB instances and a cluster volume that manages the data for those DB instances. An Aurora cluster volume is a virtual database storage volume that spans multiple Availability Zones, with each Availability Zone having a copy of the DB cluster data. Two types of DB instances make up an Aurora DB cluster.”
Therefore it is a combination of databases that are managed by one instance of a database server.
Big companies will have an issue replacing the Oracle database with HANA on a significant scale. This is because it is unsafe to use a single database instance, and backup with replication will never replace the real cluster.
SAP’s Focus on HANA for Cloud
HANA is the most prominent item offered by SAP on AWS. However, it should be remembered that HANA is only used at a tiny percentage of SAP customers. Most SAP customers still use Oracle, DB2, or SQL Server. This is explained numerically in the following quote from the book SAP Nation 2.0.
“SAP says over 7,000 customers are using HANA, which means the majority of its nearly 300,000 customers are still persisting with databases from Oracle, Microsoft, IBM, and SAP’s own Sybase and MaxDB. In periodic updates, SAP shows the state of support for Oracle’s database version 10g, 11g, 12c, its engineering systems and related products. That diversity will continue for years, as customers will not jettison the elaborate systems management and talent infrastructures they have built around those databases.”
HANA only seems so prominent because of SAP’s marketing. This can be seen by DB-Engines, which is a website that tracks database popularity.
Marketed extremely heavily, HANA has not grown in popularity as a database since the beginning of 2017.
Furthermore, customers that bought and implemented HANA in almost all cases did so on premises. And they bought a huge hardware footprint to use, which we cover in the article The Secret to Not Talking About the Cost of HANA. What is the likelihood that they are now a market to migrate to AWS? Not high.
And part of the reason for HANA being featured so prominently on AWS is obvious because SAP is trying to get more adoptions of HANA. That is not because many customers will be migrating HANA to AWS.
Another significant item offered on AWS from SAP is the Adaptive Server Enterprise or the renamed Sybase DB. However, the renamed Sybase DB is not a fixture at many SAP customers. This is usually the case that SAP does not migrate customers from acquisitions into core SAP. Therefore Adaptive Server Enterprise/Sybase DB will factor even less so in SAP customer migrations than HANA.
Sybase DB/SAP Adaptive Server is one of the most rapidly declining databases. Although the base is 55, not zero, the rate of this decline is exaggerated by roughly a factor of 2x in this graphic.
With HANA and the Adaptive Server Enterprise being the two most prominently featured products on AWS, the two most prominently featured SAP products on AWS will have minimal SAP customers’ usage.
One of the things that tend to be glossed over is the number of promises that SAP has made regarding infrastructure that has not come true and what the new SAP cloud components mean for Basis, which is the infrastructure layer in SAP.
To get this perspective, we needed to find an SAP Basis resource to explain SAP’s infrastructure history. The following quotation is from Cemal Doganay, who has worked in SAP Basis since 1998. This quotation describes the impact of moving from the on-premises SAP infrastructure to SAP’s Cloud.
“I remember the fact that every new product was welcomed with new hopes and pushing us to install ASAP from 6.40 Web Application Server, MDM, XI, MDM, APO etc. At the end, none of the initial problems were efficiently resolved but they resulted in the requirement for new products and new interfaces.
That still goes on.
I finally experienced my first SAP Cloud Project. It is a project that will migrate a legacy system and its interfaces to S/4 HANA . That sounds very exciting. The infrastructure is a private cloud which is called HEC (HANA Enterprise Cloud) which I call “Restricted Hosting.”
- Interestingly, there is no operating system access. I found ways to run a couple of operating system commands. But that was the extent of it.
- For example, to configure HANA Monitoring, we needed to open an HEC ticket to provide some rights to the database user.
- Therefore, we are limited to using the SAP GUI and HANA Studio, which is again limited.
Since the project began, I feel that what an SAP Basis Administrator does in the SAP cloud environment is to stick to Solution Manager and its capabilities plus user management. It seems that the SAP Basis Administrator On Cloud lies in Solution manager Administration plus User management. Yet, even in the Solution Manager in the monitoring area, it is highly advised to concentrate on business related monitoring rather than a technical side because HEC (they say) already monitor required items.
According to ‘HEC Catalog,’ we are not allowed to do other things. For example, Upgrades, SPS Updates, SAP Stop/Start actions. We are told we should plan to Start/Stop times one week before even in Development Systems. Otherwise, they will probably charge extra.
Like applying OSS Notes (SAP’s support note system), some items can be performed by SAP or by the customer. Of course, it should be billed separately if SAP does that.
What I observe in this short time is that Fiori’s involvement in a project will bring more maintenance headaches because security efforts should be doubled. If a backend user is created, that should also be created on the Fiori server, and proper authorizations should be assigned. So, it looks more and more as if the SAP Administration On Cloud becomes Solution Manager + user management.”
Hopefully, this provides a more realistic feel of the realities faced by SAP infrastructure as the Cloud encroaches into on premises SAP environments.
SAP has unique challenges when leveraging AWS or Google Cloud. Customers have no qualification to “hack” the SAP with their integration bus, and there are only a few developers who know both SAP inwards and Cloud inwards. And of course, SAP will newer provide an adequate API to SAP.
SAP’s databases are a poor fit for the Cloud. HANA is almost always run on premises unless an inexpensive or free version is used to test or develop AWS.
- SAP has spent the past few years getting customers that purchased HANA to buy outsized servers.
- SAP’s Adaptive Server Enterprise is a steep decline database and is database companies are migrating from, rather than focusing on migrating to the Cloud.
- HANA and Adaptive Server Enterprise are the two easiest SAP products to use in AWS. But after that, everything is more difficult to migrate to AWS. In this way, they are misleading. SAP is touting the ease of placing its databases on AWS but leaving out the complications of what happens after.