by Sachin Ghorpade, Principal Architect, Microsoft, SAPinsider Expert Many SAP customers have had mission critical SAP applications running on-premise for years. These SAP applications support business processes related to finance, supply chain, and human resources, making the availability of these applications is critical to successfully run a business. There are also data privacy requirements that must be met. Oftentimes these SAP systems are accessed across the globe, requiring that network latency be optimal. However, before you deploy your SAP real estate to public cloud, ensure that you have reviewed the following considerations. This article should help you to asses, review, and make a proper decision for a specific cloud move. This can also be an early planning guide during your assessment phase.

Considerations for Your SAP Deployment in Public Cloud

To achieve on-demand scalability, increase business continuity, ensure flexibility of work, and reduce cost, cloud can be a good option. Migrating to cloud is a big change. And, like any other major organizational changes, you want to be very careful while making this big change (i.e., migrating to the cloud). Keep in mind that many of the following examples are based upon one option for deploying SAP in the cloud—Microsoft Azure.

Consideration #1: Region

In the cloud world, region refers to the location where your application will reside. The region is the first consideration to keep in mind before deploying to public cloud because companies want their data and applications as close to the site of their office as possible. Having a data center near your on-premise existing location may help businesses speed up the data transfer during the migration process. When you select the data center you should consider not only the primary location of the region, but the secondary region as well (see consideration #3).

Consideration #2: Compute SKU

A compute SKU is a unit that provides processing power to the application hosted on that compute unit. Choosing the correct size is important for mission-critical SAP workload and cost optimization. There are many compute SKUs available, including:

• SAP NetWeaver, or SAP S/4HANA application layer
• SAP HANA online transaction processing (OLAP) certified SKUs
• SAP HANA online analytical processing (OLTP) certified SKUs
• Custom SKUs under TDIv5

Based on your SAP application and database architecture, and the sizing requirements, you may choose one of the following architectures for your database layer:

• Scale-up
• Scale-out
• High availability

Consideration #3: Disaster Recovery Location

We discussed the importance of the region in the first consideration. The secondary region, or the disaster recovery (DR) site, is just as important to consider in order to meet your business continuity requirement, determine where you may need to perform test failover to the DR site, or in the case of an unlikely event like an earthquake occurring in the primary region. Some countries and organizations may have specific data privacy requirements; you may want to choose a secondary region (DR site) according to those requirements. Consider the distance between primary and secondary region to avoid the data synchronization lag due to the network latency. Also, you want to ensure that all the services required for your production site are available at the secondary site as well. Figure 1 shows the logical representation of the two regions in Azure. It Illustrates how one region is being used as primary region to run your production workload, while secondary region is being synchronized from the primary. Figure 1 — Hypothetical Azure Regional Pair

Consideration #4: Network Connectivity

When your users are distributed globally, network latency plays an important role. You need a consistent, reliable and secure network. Network bandwidth is also an important consideration while you are performing the initial migration and in hybrid deployment scenarios where a lot of data transfer happens between your SAP application in the cloud and other on-premise applications. As an example, Azure offers multiple connectivity options like Point-to-Site (P2S), Site-to-Site (S2S), and ExpressRoute. Select an option based on your bandwidth requirements. Please consider having a backup or a redundant plan for your network connectivity as well. You don’t want to lose the connection to your most important business critical system because your network can’t connect from on-premise to cloud. In such a case, your connectivity should fall to the redundant network option configured. Figure 2 represents the sample connectivity between your various on-prem locations such as headquarters, branch offices, remote-users to the cloud. Different connectivity options like ExpressRoute, Site-to-Site VPN, and Point-to-Site VPN are depicted for the connectivity. Figure 2 — Sample Network Connectivity Between On-prem and Azure

Consideration #5: Security

Your SAP system contains high business impact (HBI) data such as financial, customer, payroll, and credit card information. Security of this data is the most important consideration. You not only want the data at-rest (i.e., while data is sitting on the system at file system level) to be secured, but at in-transit (i.e., while you are transferring the data from one place to another) as well. Consider the various aspects to completely secure your SAP applications. This is a vast area; the following includes a few simple examples:

• Network security example: data being exchanged between your applications (in-transit) is encrypted and secured
• SAP application security example: SAP application-level security like access control list (ACL)
• Database security example: database backup files are encrypted
• User access control example: provide the required access in a controlled manner

Figure 3 shows a single view from which you can manage, review, and control the various security aspects such as policy and compliance, security hygiene, and threat protections. Figure 3 — Sample Security Center

Consideration #6: Infrastructure-as-a-service Vs. Platform-as-a-service Vs. Software-as-a-Service

For your business, the SAP application features required can be achieved through various platforms in the cloud (Figure 4).  You can choose from the following:

• Infrastructure-as-a-service (IaaS), where the cloud provider manages the infrastructure layer such as compute, storage, etc. and the customer is responsible for anything beyond this, such as patching of operating system, SAP system installation, and managing the infrastructure layer. If you are looking at a traditional SAP system like ERP, they are deployed with full feature set in an IaaS manner.
• Platform-as-a-Service (PaaS), where infrastructure layer is managed by the cloud provider and the customer focuses on the application development and management. SAP Cloud Services (SCP) offerings on Azure is a great example of PaaS.
• Software-as-a-Service (SaaS), where the customer is only responsible for managing the data. The complete software and infrastructure is managed by the provider. SAP applications such as SAP SuccessFactors and SAP Ariba are examples of SaaS offerings in Azure.

Figure 4 represents customers' and cloud providers' responsibility to manage the IaaS, PaaS, and SaaS stacks. Figure 4 — Responsibilities in IaaS Vs PaaS Vs SaaS Model

Consideration #7: SAP Application Availability

SAP application availability (SLA) is important for the continuity of your business. SLA entirely depends on the infrastructure availability. In the IaaS-like deployment, you rely on your cloud infrastructure provider to ensure the availability of infrastructure. You also design the application in such a way that it fulfills your business continuity requirements. For example, Microsoft Azure offers 99.9 % uptime SLA for a single virtual machine (VM) with Premium Solid-State-Drive (SSD) or Ultra Disk. If you have higher uptime SLA requirements, you would want to choose availability set deployments providing 99.95% uptime, or availability zone deployment providing 99.99% uptime SLA. Figure 5 represents the days and hours of downtime a business can expect to experience depending on the percentage of SLA. Figure 5 — Availability and Downtime Illustration

Consideration # 8: Integration and Analytics

Once you have successfully deployed your SAP system in the cloud, the next important question is: how do I easily connect this SAP system to others business systems? Or, how do I provide data access to analysts (non-SAP users) to perform further analysis without having them directly access the SAP system? You don't want to invest a lot of time in developing the connectors or purchase third party connectors which would cause licensing cost and the management efforts of the connector itself. Review what integration and analytics tools are already available from the cloud provider you've chosen. How many of those tools can provide you native integration without having to do a lot of coding? Figure 6 shows the logical representation of how systems are connected for analytics and reporting. Figure 6 — Integration and Analytics

Consideration #9: People Skills

Unlike your traditional days of on-premise where you had dedicated people for infrastructure management, this paradigm may change in the cloud world. Oftentimes, SAP basis admins perform the infrastructure deployment, SAP installation, and manage the landscape. SAP basis admins may need to ramp up on automation technologies such as ARM, terraform, and ansible. They also need to refresh/learn the infrastructure knowledge like compute, storage, and network.

Consideration #10: Tools and Processes

When you migrate your on-premise SAP system to the cloud, your existing tools and processes may require adjustment. This is an opportunity for you to review your existing tools for their licenses, end of life support, and management efforts. You may have better tools to leverage which are native to the cloud provider.  Make a list of all the tools, perform assessment, and do the parity of the available tools in the cloud. Similarly, you want to review your processes and ensure that it can still be used in the new era of cloud. You may have an opportunity to improve or define the new processes to serve your business better.

Conclusion

Cloud migration is a journey. During this journey you will discover and learn a lot of new things. It is an opportunity for you to revamp your technical and business processes. Initially, it may look disruptive because you are changing (enhancing) a lot of things which have been historically working in your on-premise environment. Cloud is the future, so let's take this opportunity and start planning to move your SAP real state migration to the cloud now. Many customers, including Coke One North America, Daimler, and Carlsberg Group, have moved to the cloud to realize the benefits for their organization, and to modernize the user experience.