Skip to Content
Technical Articles

Deployment Options in the Hybrid Cloud ERP

Welcome back to the next blog in the Hybrid Deployment ERP blog series.

The earlier blogs in this series gave us an overview on Hybrid cloud deployment model, cross company scenarios and master data integration.

In this blog, we will have a look at the various deployment options that will help the customer to transition from their existing landscape to a hybrid landscape. The blog emphasizes the technical detailing of deployment options. It does not cover the decision-making process of which options to use based on the business requirements of the customer.

There are multiple advantages of moving from an SAP ECC system to an SAP S/4 HANA system like

  • Empowering new growth with real-time information and predictive analytics
  • Accelerating time-to-value with built-in best practices
  • Removing complexity in the IT landscape to eliminate batch processing, latency, unreliable data, and workarounds
  • Reducing IT costs and redeploying resources to more strategic pursuits

In this blog we will look at couple of deployment options. For ease of representation, we are depicting the hybrid scenario as HQ and subsidiary. It can also be replaced by corporate/non-corporate, central services, etc.

 

From Monolith landscape to Federated landscape

 

In the Customer landscape depicted above, headquarters and subsidiaries are using a single instance of SAP ECC. Assuming there are several processes which are tightly integrated, a direct federated move to S/4 HANA along the lines of best practices might be difficult. This should ideally be approached by first moving the subsidiary processes on SAP S/4 HANA (Public Cloud, Single Tenant Edition or managed by HEC). The approach to move the subsidiary to SAP S/4 HANA can be done via new implementation or system conversion as depicted below.

 

 

The extensions ideally should be done on SAP Cloud platform so that it remains decoupled and is not affected by upgrade cycles. Since the subsidiary processes are now being executed in a separate instance of ERP, the ECC system at the HQ needs to ensure that the hybrid scenarios works seamlessly via integration. Once the intermediate state is achieved, the ECC system at the HQ can transformed to S/4 HANA Cloud (single tenant, managed by HEC).

From a purely technical point of view, the transition from SAP ERP on any database to SAP ERP powered by SAP HANA includes an EhP upgrade, an SAP NetWeaver upgrade, and a database migration. From a technical viewpoint, a new implementation means that the software is installed first, and then the data required to start business operations is loaded using the SAP S/4HANA migration cockpit.

By contrast, with a standard conversion procedure both the software and the data are converted in a single step. Hybrid data transition, also known as landscape transformation, stands for scenarios that go beyond the standard options of system conversion and new implementation. It comprises a host of options that need to be evaluated carefully as they often increase the project’s risk, effort, and complexity.

As long as you load master data and open items using the SAP S/4HANA migration cockpit, this approach is within the realms of the standard. However, if you want to load all historic data into the new system, this entails an extra effort and usage of specialized tools and services.

SAP S/4HANA migration cockpit uses standard application logic to provision the data. Likewise, Software Update Manager (SUM) applies software vendor logic to convert the data in-place during a system conversion. The tool to migrate the data from the source SAP ERP to SAP S/4HANA has to apply exactly the same logic. Note that this is always a project solution as there is no standard tool to migrate historic data. In complex scenarios, the data is migrated at database table level which requires an exceptionally deep knowledge of both the data structures of and the complex dependencies between the business objects of SAP ERP.

If the system as such is deemed to be in good shape, a project team may seek an approach on how to change only a part of the system configuration or functionality, while retaining the rest unaltered. Technically, such an approach includes these steps:

  1. Performing a shell creation from the current SAP ERP
  2. Performing corresponding customizing and configuration changes in this shell system
  3. Executing a standard system conversion of the shell system
  4. Loading the data.

 

SAP continuously optimizes the tools to assist customers in the conversion process and to eliminate the manual labor through automation. Most notably, a system conversion preserves your assets: data, processes, and custom code. However, you should assess the perceived value of these assets very diligently: The new technologies, new business practices, and a changed business environment may have rendered some of these obsolete. Since SAP S/4HANA is a new product, a conversion is significantly more than an upgrade. Systems that have been kept up-to-date will experience less impact because most simplifications continue the roadmap of the corresponding strategic developments in SAP ERP. Still, a close examination of the simplifications and the associated technical and functional impact will be an important part of every conversion project.

With a new implementation, you build a new SAP S/4HANA system, and either cut over to the new system or migrate the individual business units sequentially from the old SAP ERP to the new system (‘a phased roll-out’).  With a system conversion, you turn your existing SAP ERP system into an SAP S/4HANA system. Technically, the system conversion is a one-step procedure with a single downtime which is comprised of:

  1. For SAP ERP powered by HANA, an upgrade from HANA 1.0 to HANA 2.0. For SAP ERP on any database: a database migration to SAP HANA
  2. A conversion of the data from the SAP ERP data model to the SAP S/4HANA data model
  3. A software upgrade, that is, replacing SAP ERP application code with SAP S/4HANA application code.

 

Transforming Current Federated landscape to S/4 federated landscape

In case the customer has a federated landscape, similar set of rules apply. In addition to that, the integration which exists between SAP ECC systems and 3rd party systems need to be working after the upgrade as well.  To ensure the integration works with upgrades, it is advised to use whitelisted objects to facilitate integration.

For more information on SAP S/4HANA Cloud, check out the following links:

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