Skip to Content
Personal Insights

Microsoft Cloud Operating Model & SAP on Azure Migration Scenarios

My earlier post Your Journey to Microsoft Cloud: 5 Strategies for Success & 3 Leadership Principles was about strategies and leadership principles of a successful Microsoft Cloud migration.

Here, I expand further on Migrate section of the whitepaper: Adopting Microsoft Cloud Operating Model. People might assume that all these scenarios would apply to SAP migration too.

I will attempt to answer in this article which scenarios are applicable to SAP migration to Azure and why it is different from say a .Net or Web application moving to the cloud. I will also discuss extended platform services can be used in Azure with SAP and map the scenario.

Migrate and Modernise

Let’s see the cloud technical definition in the Microsoft Cloud Operating model here.

No alt text provided for this image
  • Rehost: Often referred to as “lift and shift” migration, this no-code option lets you migrate your existing applications to Azure quickly. Each application is migrated as is, which provides the benefits of the cloud without the risks or costs of making code changes.
No alt text provided for this image
  • Refactor: Often referred to as repackage, is a cloud migration approach that involves some change to the application design but no wholesale changes to the application code. The application takes advantage of infrastructure as a service (IaaS) and platform as a service (PaaS) products such as Azure App Service, Azure SQL Database managed instance and containers.
No alt text provided for this image
  • Rearchitect: Modify or extend your application’s code base to scale and optimise it for the cloud. Modernise your app into a resilient, highly scalable, independently deployable architecture. Use Azure to accelerate the process, scale applications with confidence and manage your apps with ease.
No alt text provided for this image
  • Rebuild: Rebuild an application from scratch using cloud-native technologies. Azure platform as a service (PaaS) provides a complete development and deployment environment in the cloud, without the expense and complexity of software licences, the need for underlying application infrastructure, or middleware and other resources. With this cloud migration strategy, you manage the applications and services you develop, and Azure manages everything else

Custom Development versus Packaged Application

Let’s further define what an SAP application is. SAP software is nothing more than what the IT industry calls a Packaged Application. Here are the key differences of a Custom Application and Packaged Applications.

No alt text provided for this image

Figure 1: SDLC Custom Built Applications vs. Packaged Applications (Source here)

In a broad sense, the design, build, test and deploy process has clear differences. Packaged applications like SAP focuses on a business process best practice framework as its base.

Custom development though is all writing code and deploying it (for example: a web application). A Web application may have a back end database and front end UI (User Interface)

The SDLC for implementing and managing custom applications is different than that used by custom applications. The focus of packaged applications is on process. The business maintains an architectural role in how processes need to work. IT is responsible for customizations, configurations, and availability

There could be typo in the above bold quote. It should read as Packaged Applications. But it does make a point. The software model and life cycle management of a custom application versus a traditional SAP solution is different.

This is also not about Software As-A-Service (SaaS) models like S/4 HANA Cloud. This model is standardized versions of the software via a multi-tenanted cloud. It usually means customers have to adopt specific business processes without modification to the code base.

Mainly, SAP extensions are possible with SAP Cloud Platform (SCP) through OData, but not modification to the core code base of S/4 HANA On-Premise or Cloud Editions. On the right, are SCP Platform Services as Side by Side Scenario.

No alt text provided for this image

Figure 2: SAP S/4 HANA Side by Side Extension Scenarios with SCP (Source here)

SCP also runs on Azure under the Cloud Foundry PaaS in some regions. As more services are delivered via Open Service Broker for Azure, Meta Azure Service Broker will be replaced.

SAP Packaged Software when migrated to Azure will only utilize Infrastructure-As-A-Service (IaaS) Services (eg: virtual machines and storage. Generally, Platform-as-a-Service (PaaS) services are not being used because they are not certified by SAP . For example, Azure SQL Managed Database Service.

SAP Note: 928533 SAP Applications on Azure: Supported Products and Azure VM types

SAP Netweaver Architecture

SAP Netweaver ABAP Architecture (adapted) has not changed since it was introduced years ago on-premise.

No alt text provided for this image

Figure 3: SAP Netweaver ABAP Architecture (Adapted)

This nice diagram depicts the SAP Netweaver Library: Function-Oriented View in SAP Help. This has all the various components as a SAP Packaged Software that is being delivered to a customer.

No alt text provided for this image

Figure 4: SAP NetWeaver Library: Function-Oriented View

For Custom application migrating to the cloud, the four scenarios above applies.So, how do we map the various cloud migration for SAP Netweaver Platform based Application (S/4 HANA or ERP on AnyDB)?

SAP Packaged Applications however does not fully conform to this definition. This is because the SAP Netweaver Library provides all the software components required to build, deploy and test as a bundle. There is no such thing as re-coding SAP to a cloud native application.

SAP also has its own software life-cycle tools SWPM (Software Provisioning Manager). It functions to install, upgrade, migrate. The Maintenance Planner also determines the various support packages to upgrade.

Mapping SAP Migration Strategies to Azure Cloud Migration Center Scenarios

So, let us read Microsoft’s “Migrating SAP Azure” whitepaper. Let us assume the current on-premise source system as follows on the second column of table 1:

Technical Platform Scenarios

No alt text provided for this image

Table 1: Example of SAP Components mapped to Azure Migration Scenarios

Only two out of the four scenarios apply: Re-Host and Re-Build into a IaaS services in Azure. The migration paper discussed in general, but here I will go deeper by giving examples here.

Scenario (A) Lift and Shift to Cloud:

Keep same version of SAP Netweaver kernel, SAP application versions and Databases. When you migrate off to the cloud, there is an opportunity to upgrade to the latest SAP Netweaver kernel to 7.5, OS and DB. But, the question is whether it would make sense to upgrade to Ehp 8 for example. Because doing this means that there is a need for a significant amount of testing post migration.

Scenario (B) Lift and Migrate to Cloud:

Change of OS and DB. For example: Oracle 11.2 to SQL 2017 server and this is a SAP OS/DB migration scenario. The OS would then have to be at least be Windows Server 2016 LTSB.

Scenario (C) Lift and Shift/Migrate to Cloud, Migrate to part to HANA:

Change of OS (SUSE or Redhat Linux) and DB (HANA), and upgrade to at least ERP 6.0 (Ehp 8) because that is the minimum version. SAP Netweaver kernel 7.5 is then required for installation as a target version in Azure. This is also commonly known as Business Suite on HANA.

Scenario (D) Transformation to S/4 HANA and Cloud: Consolidation or (selective) Reimplementation or Greenfield

New implementation build and start afresh with a new software version. In this instance, S/4 HANA with all new business processes adopted. This is not even migration or re-host scenario.

Selected data migration using third party tools or start with no legacy data sets. This might be Re-Build Scenario according to Azure Migrate Center. Because there are no PaaS services, this definition also does not fit completely too.

No alt text provided for this image

Figure 5: SAP Journey to Azure Cloud Scenarios

Extension in Microsoft Azure using SAP ABAP SDK & Azure App Service

However, just like the S/4 HANA Side-By-Side Extension Scenarios, the same function could be applied by Azure Platform-as-a-Service (PaaS) solution.

Microsoft Core Services Engineering and Operations or aka Microsoft Internal IT built a ABAP SDK that can be download here in Github.

There is also the choice of using Azure App Service which includes Java, Node.js and many other development frameworks. In an upcoming article, I will discuss about how we can connect up Azure Bot Service to a SAP ERP or S/4 HANA using Odata.

I would argue this approach can be considered as Re-Architect Migration Scenario because we are extending using Cloud PaaS services.

No alt text provided for this image

Figure 6: SAP ABAP SDK connector for SAP ERP and S/4 HANA

You can read about the case study Streamlining business processes with SAP connectors and Azure services.

_____________________________________________________________________

Article Summary

  1. SAP Packaged Applications and Custom Applications have different migration pathways to Microsoft Azure.
  2. Two possible scenarios of Re-Host and Re-Build apply for SAP Packaged Software on Azure IaaS services.
  3. Always check dependencies to OS/DB/SAP Kernels and SAP versions during assessment phase.
  4. SAP S/4 or ERP (Packaged Applications) can be extended to SAP Cloud Platform, ABAP SDK and Azure Platform Services as part of your agile digital transformation platform. This can be considered as a Re-Architect scenario.

Table 2: Summary Mapping of Microsoft Cloud Operating Model to SAP on Azure Migration Scenarios

No alt text provided for this image

If you enjoyed the post, please click the 👍icon, share or comment and let me know!

Other Relevant Articles here in SAP Technical Community

SAP IT Service Operations Management on Azure

SAP Security Operations On Azure

______________________________________________________________________

I blog this article to share information that is intended as a general resource and personal insights. Opinions are my own and not the views of my employers (past, present or future) or any organization that I may be affiliated with. Your comments to my posts are your views and I am not liable for anything shared by anyone else.

This post was originally published in Linkedin.

Be the first to leave a comment
You must be Logged on to comment or reply to a post.