Transitioning the Customer from Existing Landscape to Hybrid Landscape in SAP

Monolith to Federated

The monolith landscape allows the headquarters and subsidiaries of a company to use a single instance of SAP ECC. There are several processes that are integrated into this system. Hence, the move to the SAP/4 HANA system will require all of this to be shifted without losing the integration. Hence, this will be quite the conundrum to solve. All the connections and the data that is shared between these subsidiaries and headquarters will have to be saved.

Extensions, ideally, should be done through the SAP cloud platform. This is done so that it remains decoupled. This way, it won’t be affected by upgrade cycles. The subsidiary processes that are now being executed in separate instances will need to be integrated. Hence, the HQ here will need to ensure that all the processes that were separate in the ECC system have to be interconnected. This is easier said than done.

Once hybrid scenarios reach a sort of intermediate state, then the transformation to SAP/4 HANA can truly begin.

There are three upgrades that need to be included in an upgrade scenario. The first is an EhP upgrade, an SAP NetWeaver Upgrade, and database migration. This means that the software will be installed first, and then the critical data will be loaded. When all this is finally done, then the SAP ERP migration will be complete.

However, with this transition to the SAP/4 HANA platform, things will be done a little differently. In contrast, the standard procedure with both the software and the data will be done in a single step. This means that not only will the processes be integrated, but the steps will also be combined. Hybrid data transition, which is also known as landscape transformation, goes beyond standard system conversion.

This comprises a lot of options that need to be evaluated very carefully. They often increase the risk and the effort that is involved in the process. However, if pulled off correctly, they yield a massive result. Hence, the risk to reward ratio is pretty low. The reward to risk ratio is pretty high.

This approach is within the basic standards if you want to load master data and open items on the SAP/4 HANA platform. However, if all the historic data has to be loaded into a new system, then there is a lot of extra effort involved. This also involves the use of a lot of specialized tools and services.

The logic used in the standard SAP/4 HANA migration cockpit provisions the data. Also, the Software Update Manager applies vendor logic to convert data that is stored in place during a system conversion. The tool which is used to migrate the data from the source ERP to SAP/4 HANA has to apply a similar logic. In fact, the exact same logic has to be applied here. In very complex scenarios, the data that is migrated at the database level requires very deep knowledge. The knowledge has to be concerned with the data structures and the complex dependencies between business objects.

Here, the project team has to seek an approach on how to change part of the system configuration. This can include changes to the configuration or functionality while retaining the rest of the system without changes. This can be especially hard when dealing with so much data and so many connections.

Usually, this approach entails these 4 steps:

  1. Shell Creation from the current SAP ERP
  2. Customizing and configuration changes that correspond to the changes in the shell system.
  3. Standard system conversion execution in the shell system.
  4. Data loading

With a new implementation, you can build new SAP/4 HANA systems. You can either cut over the new system or you can migrate individual business units. You can also use a new phased rollout. With system conversion, you can turn the existing ERP into the SAP/4HANA system. This is a one-step procedure which is comprised of a single downtime. This is composed of the following:

  1. For SAP ERP which is powered by HANA, upgrading from HANA 1.0 to 2.0. For SAP ERP which is on any database, the migration can be towards SAP HANA.
  2.  The conversion of the data from SAP ERP data model to the SAP/4 HANA data model
  3. A software upgrade which replaces the SAP ERP application code with the SAP/4 HANA application code.

Federated to Federated

This is the case in which the customer has a federated landscape already. Hence, similar sets of rules apply. In addition to this, the integration that is present between SAP ECC systems and third-party ones will have to be working after the upgrade is finished. To ensure that the integration is still intact, it is advised that whitelisted objects are used. This will facilitate the integration much better.

These are the two main ways in which you can upgrade to SAP/4 HANA from SAP ECC.