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.
*** Author's Note:
As of July 2019, Microsoft have released the
Microsoft Cloud Adoption Framework for Azure and have seen
success with customer cases. ***
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.
- 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.
- 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.
- 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.
- 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.
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.
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.
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.
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
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
😎 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.
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.
I would argue this approach can be considered as
Re-Architect Migration Scenario because we are extending using Cloud PaaS services.
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
- SAP Packaged Applications and Custom Applications have different migration pathways to Microsoft Azure.
- Two possible scenarios of Re-Host and Re-Build apply for SAP Packaged Software on Azure IaaS services.
- Always check dependencies to OS/DB/SAP Kernels and SAP versions during assessment phase.
- 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
Other Relevant Articles here in SAP Technical Community
Quick Guide to SAP on Azure SLA and OLA
Quick Project Manager’s Guide to SAP on Azure
Quick Reference to SAP on Azure Components for HA and DR
SAP Customer Center of Excellence for Azure
SAP Customer Center of Excellence for Azure: Govern, Design, Innovate & Build
SAP Center of Excellence for Azure: Sustain & Run
SAP IT Service Operations Management on Azure
SAP Security Operations On Azure
SAP Expert Role Guide to Microsoft Azure Skills and Certification
Exam Study Resources for AZ-120 Planning and Administering Microsoft Azure for SAP Workloads.
Worst SAP Production Outage Disasters
______________________________________________________________________
This post was originally published in
LinkedIn here on 27 November 2018
Profile & Disclaimers
chthe