If you were moving to a new house, it’s likely that you’d review what’s important to take with you versus what can be donated, tossed, or left behind. Moving SAP environments to Microsoft Azure requires similar considerations and preparation.

Cloud Rationalization and the Five Rs of Migration

In the planning step of the cloud adoption framework, one of the goals is to review current systems to determine fit for migration. So, what are the options for migration? Gartner Research popularized the notion of the five Rs of migration, namely, rehost, refactor, revise, rebuild, and replace. It refers to the process that must be undergone to get to a future state—either through migration or modernization.

For SAP, it starts with gathering which business processes are using the systems, that is, mapping of business processes to the SAP system. That tells which systems are crucial for business and reveals those that have less dependency. This process helps not only with the migration approach but also with the DR approach. The following figure shows an example of this exercise.

The output of business processes to SAP system mapping feeds the rationalization decision. This can sometimes be an iterative process so you shouldn’t get stuck on getting this 100% right; you can always reevaluate and refine later.

Bringing the SAP context to the cloud rationalization process, first you need to figure out whether the systems need to be retained, can be replaced, or is ready to retire. Those in the retain list can be either rehosted on the cloud as is (lift-and-shift) or be rearchitected (modernized). Below shows these five Rs of the cloud rationalization process.

Retain

This is the most migration effort-intensive part because it brings in the complexity of moving the systems as well as testing the business processes on the new platform. Retain can be subdivided into the following:

• Rehost: Also known as lift-and-shift, this process is achieved mostly through IaaS and focuses on moving the system to the cloud with minimal to no architectural changes. The overarching idea is to get to the cloud before you try to change anything.
• Rearchitect: Also known as modernization of an application, this process can be either IaaS or PaaS and realizes the idea that the system is needed but not necessarily in the current form. For example, a business process can be merged into another system, or a PaaS service integrating with another system can perform the same function. This serves as a basis for application modernization.

Replace

If there is an old version of the system that is difficult to maintain or upgrade, a SaaS product may be a better fit if it provides the necessary functionalities. SAP SuccessFactors is an example of a SaaS product that provides a human resources (HR) and payroll solution, which can be a replacement for SAP ERP Human Capital Management (SAP ERP HCM).

In addition, sometimes installing a new SAP product and moving the data may work better where there is no upgrade or migration path for older systems.

Retire

Traditionally in an on-premise environment, the variable cost of hosting small applications is low, and, over time, you may have accumulated a lot of those applications. Eventually, the evolution of business processes or system upgrades bringing more functionalities removes the need for those applications, but they are seldom decommissioned either due to lack of time or analysis.

A good way to analyze these systems is by asking the question, “why not”—as in why can’t this system be retired instead of why should this system be retired. This rephrasing triggers the analytical part of our brains to help figure out whether the functionality provided by the application is really being used and, if so, whether it can be done by any other system or cloud native solution.

It’s not uncommon for an organization to retire anywhere between 10% and 20% of the applications when moving to the cloud.

The next figure shows the decision flow for the cloud rationalization process leading to a decision regarding rehost, replace, or retire.

SAP System Certification as IaaS

For SAP systems, it’s also important to note how the systems are certified on the cloud. Most of the ABAP/Java systems are certified only as IaaS solutions; thus, the decision about possible modernization also has a certification requirement built into it.

SAP Migrations versus New Implementations

SAP provides several different migration paths, which can be a combination of as-is, upgrade and migration, SAP HANA conversion, and migration. As-is migration is probably the simplest among the available options, but you also need to make sure the application minimum requirement for certification on Microsoft Azure is met. In some cases, you may need to upgrade either the application or database (or both) before it can be migrated. For backward-compliant versions, you can do a new installation on Microsoft Azure and move the data or files to the newly installed system. For example, newer SAP HANA versions are often backward compliant (with few exceptions), and it’s a good idea to install the latest version and patch on Microsoft Azure. With migration, you can often bring in a new SAP kernel as well.

Moving to the SAP S/4HANA new implementation in Microsoft Azure is also an option with data loading from the on-premise system, specifically when the current system is very old and/or has complex customizations.

Details of these paths are discussed in the migration section of the book, but we wanted to highlight that migration versus new implementation (or installation) isn’t mutually exclusive and often cross paths.

Third-Party Systems

SAP systems are connected to several other applications, commonly called third-party systems or bolt-ons. These often have less stringent support requirements and are easier to either replace or rearchitect; you can follow the same decision path for retain, replace, and retire, keeping in mind that moving to Microsoft Azure may provide easier integration and better options.

For example, an on-premise Simple Mail Transfer Protocol (SMTP) solution can easily be replaced by something similar on Microsoft Azure without much consideration about compatibility or certification. Another example is the Vertex tax solution, which can be used as a SaaS solution integrating with SAP systems on Microsoft Azure.

Conclusion

When it comes to choosing a system host for a cloud SAP solution, Microsoft Azure is one of the popular options. This blog post explored the rationalization process and walked you through the decision framework.

This content was originally posted on the SAP PRESS Blog and has been adapted from a section of the book SAP on Microsoft Azure: Architecture and Administration by Ravi Kashyap. Used with permission of SAP PRESS. All rights reserved.