Running Legacy SAP Versions on AWS

As AWS is widely adopted across the globe for deploying SAP, one of the key challenges observed is to deploy the SAP versions on AWS that are out of maintenance; some of these application versions also have no support from SAP and AWS for a deployment on cloud in specific cases. There are various mechanisms that can still be used, including the modernization option for moving to the AWS platform. The possible options and their pros and cons are evaluated in this article.

What are Legacy Versions? SAP has been an industry-leading ERP software and has been in use for close to 50 years now. The versions have evolved in these years, and while many customers keep up with the pace of innovations, there are many of them who are unable to upgrade owing to logistics, costs, and various other reasons. The flagship SAP product, SAP ERP 6.0, was released as a successor of the previous R/3 releases, in the year 2005, and this product suite ends its support in December 2025 with some latest versions supported until December 2027. In line with SAP's strategy, AWS provides support for all the ERP products, and technically, this is based on the underlying SAP Kernel as well as the corresponding Operating System and Database Version. The term legacy in this context is used for any SAP version that is older than the ones currently supported together by SAP and AWS ( as described in SAP Note 1656099, me.sap., login required).

Why do customers need to migrate these Versions ( and not upgrade)? One of the key questions asked in Customer Assessments for such legacy versions is whether to upgrade them to the next supported version or re-implement the process on a newer version of SAP or one of the 200+ AWS services as per technical feasibility. In most of the cases, the nature of legacy application is such that it cannot be re-integrated into newer technology stacks, and the business is not willing to invest in such re-engineering steps as they are either in the process of doing it already but it's not expected to finish in a defined short amount of time, or they plan to de-commission it at some point of time in future, but that is undecided while migration decision need to be taken.

Technical AWS feasibility, The legacy applications will have compatibility issues with one or more of the below:

1. Operating System (OS)

2. Database ( DB)

3. SAP Kernel

Let us understand and evaluate options in each of these cases.

1. Operating System (OS) 

Each version of the SAP system is released on a subset of operating system versions that is listed in PAM (SAP's Product Availability Matrix). At a bare minimum, SUSE 11, RHEL6, Windows Server 2008 R2, or Oracle Linux 6.4 is required (see details in SAP Note). There are scenarios where customers have not yet upgraded OS to these versions as part of their strategic plans to deploy newer versions on a different operating system and host altogether. However, these old systems are kept running due to dependent business processes. Technically an older version of OS can be deployed on AWS, however its the OS that interacts closely with underlying hypervisor of AWS virtualisation layer. As neither AWS nor SAP, are testing the combination of AWS hypervisor and older OS, there is no guarantee that this combination will remain stable and AWS cannot provide SLAs for this.

2. Database (DB) 

The database layer is not directly managed by AWS in most cases, except for Amazon RDS and other PaaS/SaaS scenarios. SAP Netweaver still does not directly support any PaaS/SaaS databases and will only run under IaaS setup where the database is natively deployed on an underlying VM. All other databases are supported as long as minimal versions listed in the above SAP note are deployed. However, Oracle is a special case and can only be deployed on Oracle Linux or Windows Server OS. This is a typical challenge that most of the customers face since they have systems running either on Big-endian platforms ( HP-UX, AIX, etc) or on SUSE/RHEL, and need to undergo a migration and technology change when they decide to move to AWS. Although technically, Oracle runs on SUSE/RHEL as well, there is no SLA based support from Oracle and AWS if this combination is used

3. SAP Kernel 

The kernel from SAP is the layer that interacts with underlying OS and in some cases directly interacts with AWS hypervisor. Any application based on SAP Kernel 7.21 and higher can run on AWS. Customers running legacy 3.x/4.6/4.7/5.0 and do not wish to upgrade their underlying ABAP stack runs into a challenge as these systems can not be deployed on AWS under IaaS. As mentioned under OS, while kernel may also function well, there is no SLA committment that AWS and SAP can provide for this combination.

Possible Solutions

1. VMC on AWS 

VMware Cloud (VMC) on AWS is an offering that allows to run of VMWare, or in other words, the hypervisor itself, under a managed offering by AWS. This provides more flexibility in terms of the OS and DB combinations since instead of AWS hypervisor, in this case, VMWare hypervisor will interact with OS. Keep a note that the VMC solution is not officially certified by SAP and AWS to run SAP Netweaver applications (me.sap); however, given the nature of legacy applications that are already unsupported, this is one of the primary mechanisms by which the limitation for older version can be addressed.

2. AWS Bare Metal Servers

These are dedicated customer servers that are managed by AWS. As they eliminate AWS Hypervisor itself, they can be alternatively leveraged to run such combinations. Keep a note that this is officially only certified to run specific HANA instances as specified in the hardware directory. However, this can be leveraged to run the older versions as long as the hardware is compatible. It is usually quicker to provision VMC on AWS, as Bare Metal Servers might 

3. AWS Outposts 

AWS Outposts makes it possible to run AWS Services in customer's data center or edge locations. This is officially unsupported, as mentioned in SAP Note 1380654, which highlights that private cloud environments that replicate characteristics of public cloud environments are not supported. However, in an unsupported manner, this can be a viable solution to run legacy systems as servers under this are more flexible and are physical servers in customer/partner facility. The physical servers are usually virtualized with the same AWS EC2 instance families that are run in AWS data centers, that might lead to the same restrictions as the usual AWS ones; however, given that the physical servers are in the customer's data center, these can be used more flexibly as compared to usual AWS instances for such legacy deployments.

4. EC2 Instances 

The AWS EC2 instances are officially unsupported for legacy SAP versions, however, as long as the underlying operating system can run on these EC2 instances, which is typically the case for older versions older than SUSE 10, RHEL 5, and Windows 2008 versions. AWS allows custom images which can typically be used to run older versions; as long as the operating system boots up properly, SAP systems can typically run. Note that in most of such cases, not all the native AWS monitoring features can be used as the integration between SAP Host Agent and AWS Data Provider is only released for systems based on SAP Kernel 7.21/7.22

 While there are also other solutions like storing the system backup on to S3 or converting the relevant transactional data into AWS Services like Amazon Redshift for analytical purposes, these are not a direct migrations and require a lot of knowledge about data, which is mostly lacking for such legacy systems.

Which option to choose, There is no single correct answer to this. However, customers prefer VMC on AWS since it keeps most of the parameters the same as on-premise. Hence, the preferred, un-supported choice would be to deploy SAP on VMC on AWS.