Jonathan HaunThe phenomenon of cloud computing has slowly ingratiated us for many years now. Many customers have already moved entire workloads to the cloud and many vendors are now offering their products exclusively as a software as a service (SaaS) cloud platform. SAP customers still contemplating moving to the cloud will want to read this introduction to what is required when moving SAP workloads to the Amazon Web Services (AWS) Cloud platform.
Behind the scenes
SAP and AWS have been partners since 2011 and have worked diligently to provide simple, quick and cost-effective options for customers to migrate and then run their SAP workloads within the AWS cloud landscape. AWS organizes its cloud resources into regions and within each region, availability zones. The region selected to run a workload indicates where the services will be hosted geographically. One or more availability zones operate within each region, representing the actual data center where the CPU, memory, network and storage layers physically operate. Availability zones within a region each operate independently but can communicate with other zones in the same region over high bandwidth and low latency network connections. Technically speaking, zones in other regions can also communicate with each other as well; however, this results in a larger fee as between-zone bandwidth requirements increase and latency requirements decrease. This organization structure and communication backbones are critical to understanding one of the key benefits of running SAP workloads on AWS. To that end, disaster recovery and high availability, coupled with AWS’s service flexibility, offer a very cost-effective solution to increase SAP workload service level agreements (SLA) while also reducing the cost compared to the traditional on-premises data center solutions of the past. This is not the only key benefit though. Customers will also find that AWS offers excellent compatibility for migrating and running SAP workloads because they support a diverse number of operating systems, databases, hardware configurations and storage options within their AWS EC2 catalog. Scalability is also another important reason that running SAP workloads on AWS are beneficial. Organizations can quickly change the hardware and storage requirements on AWS with very little to no downtime depending on the services configuration and capabilities. Next, we will discuss the three high-level migration methodologies when choosing to migrate SAP workloads to AWS.
Three ways to migrate
The migration process to AWS itself is not very technically difficult in most cases but because there are such a diverse set of options, it is important that sufficient time is allotted to assessing the current landscape, estimating costs, outlining goals for the migration process and properly planning the process. Later in this article, we will dive deeper into this assessment and planning process. However, at this point, it is important to gain a high-level view of the migration process.
At a high level, there are three broad options for migrating SAP workloads to AWS:
- Lift and shift
- Replatforming the landscape
- Refactoring the landscape
Most clients will find that the lift and shift option is the fastest and most cost-effective way to start using AWS. However, much of the additional cost savings are found in replatforming and refactoring many of the layers of the architecture. Let’s take a closer look at these three options.
Lift and shift migration involves migrating the entire SAP environment, (including the OS, relational database, and applications) to AWS without any changes. This is often the simplest, cheapest and quickest migration option, but may not fully leverage the capabilities of AWS and may result in increased long-term costs due to running SAP on more expensive AWS assets. When we think of lift and shift, we often also include the on-premises high availability and disaster recovery architecture moving to AWS in the same configuration. Again, the goal is to minimize change and basically copy as much of the on-premises architecture into AWS EC2 instances. When the on-premises and AWS EC2 instance are mirror images of each other, the means for migrating to AWS becomes simpler and faster because we can often leverage storage or database replication to help move the bulk of the SAP data into AWS EC2 instances over the wide area connection connecting the clients on-premises systems with the AWS EC2 instances. Replication also gives the organization a near-zero downtime option during the migration cutover. We often find that clients will use this method simply because it reduces the downtime of the SAP systems. Downtime can force the organization to shut down SAP-dependent business processes which often has a real financial impact on the organization.
Replatforming involves making changes to the SAP environment to take advantage of AWS services and capabilities, such as using different operating systems, Amazon Elastic Compute Cloud (EC2) instances, Amazon Simple Storage Service (S3), Amazon Relational Database Service (RDS), different network and security typologies and different backup and High Availability (HA)configurations. This option can provide significant cost savings and improved performance but will require increased planning and execution compared to lift and shift. In addition, replatforming often requires increased cutover downtime, depending on the degree of platform change. Take, for example, a customer that is currently running SAP on IBM Power with DB2 using the big-endian execution platform. The customer might have found that, through transitioning to an x86 architecture on Linux and SAP HANA database, their overall hardware, software license and maintenance cost would be reduced by a significant factor. In addition, moving backups to AWS S3, would reduce storage and retention costs by another significant factor. In this case, the customer would have to replatform when migrating to AWS. Because of the cost savings over a three-year period, this customer decided that the extra migration effort and downtime would be economically beneficial compared to staying on premises or even trying to maintain a similar architecture in AWS.
Refactoring involves many of the same rearchitecting principles as above. However, this option transitions the SAP environment to leverage AWS and SAP services and best practices more properly. This can even include simultaneously upgrading the SAP software versions. This option can result in the most significant cost savings, added features and performance improvements long term, but it also requires the most effort and investment in terms of planning and migration time and resources. For example, the customer might be using an HA and DR solution on premises that is not supported in AWS. However, AWS offers many wonderful native and third-party equivalent solutions. While the customer might have to invest time in planning, they should expect to find AWS HA/DR solutions much cheaper and easier. In another example, the customer might choose to move to SAP S4/HANA private cloud edition, hosted on AWS. This is another example of how a client might replatform and refactor while moving to AWS and SAP’s SaaS offerings. In both examples, the customer would have to invest additional planning, testing and configuration time into re-architecting the solution before and after the migration. With the HA/DR example, the migration cutover time could likely increase as well as the downtime requirements. With the move to the SAP SaaS offering, many other factors would need to be assessed and planned. However, in both examples, the customer should expect to see significant long-term cost savings and increased innovations due to the nature of AWS and SAP’s cloud offerings.
Plan, test, assess
Careful planning, testing and assessing must be conducted before any of the three broad migration strategies are selected. I typically find that most customers use a blend of the three broad options above and therefore must carefully plan before starting the migration process. During the planning process, it is important to assess the current SAP environment and understand the requirements and dependencies of the SAP workloads. This includes evaluating the current hardware and software configurations, operating systems, network topology, storage solutions, backup and disaster recovery strategies.
Hardware assessment requires cataloging many aspects of the current configuration. This includes understanding the current CPU generation, random access memory (RAM) amounts, storage size, storage speed, network speeds between systems, high availability configuration, disaster recovery requirements and several other factors. This information is compiled and used to estimate the equivalate EC2, VPC, container, serverless and EBS storage assets that will replace each system or function. This information is also used to estimate the cost of running EC2 and EBS storage before systems are provisioned.
Software configurations are also important and must be cataloged and assessed. Depending on the migration strategy and technical means used to copy the system to AWS, software configuration parameters might have to be manually applied to the corresponding EC2 system. For example, the SAP NetWeaver profile parameters might not be copied over to the AWS EC2 instance and would have to be manually re-configured on the EC2 side. In addition, software that interfaces with SAP must also be carefully cataloged and assessed to ensure compatibility within an AWS landscape.
The operating systems versions, licenses, configuration and types must also be cataloged and assessed for several reasons including AWS support, AWS OS licenses and AWS cost purposes. Many customers will find that using an AWS EC2 instance that includes the OS license have cost differences compared to preserving perpetual licensing costs on-premises. There is also the matter of support and compatibility. For example, is the on-premises OS version supported in AWS and if not, will upgrading to a new OS in AWS require upgrading the SAP software during the migration process.
Network typology and storage are also important items to catalog and assess as this is an area where changes are found within the AWS platform. Because of these differences, customers will often need to educate their employees to help aid in decision-making during the planning process. AWS networking and storage offer many options but, in most cases, they are managed and implemented very differently than they are on-premises. Therefore, it is important to understand features and requirements while assessing the current state as this information will be critical in how AWS network services, security and storage are configured.
HA/DR is also something that needs to be carefully planned and assessed. HA and DR options within AWS are very diverse and overlap in some cases. In addition, there are a wide range of cost options depending on SLA requirements and business continuity plan requirements. Again, educating employees in these areas is often a prerequisite before many critical decisions can be made.
Getting started
Once the assessment is complete and key architecture decisions are made, organizations can begin to plan their migration to AWS using some blend of the three migration options above. Each option has its own set of benefits and drawbacks, and the best approach will depend on the specific requirements and constraints of the SAP workloads, the overall cost and the organization’s tolerance for change management. Protiviti often helps customers in this planning process as we bring the technical experience and expertise required to properly assess the current landscape, provide the guidance needed to make key decisions, help you manage organizational change impacts and develop a detailed project plan required to successfully migrate SAP to AWS.
Migrating SAP workloads to AWS can bring many benefits to an organization, but it requires careful planning and execution. We recommend taking the proper time to assess the current SAP environment, understand the requirements and dependencies of the SAP workloads, and choose the best migration option. With this proven methodology, organizations can successfully and smoothly migrate their SAP workloads to AWS.
To learn more about our SAP and AWS consulting solutions, contact us.
Damiana Frangie-Massad
Vijan Patel
Eric Wojcik
