With the end of maintenance for SAP Business Suite at the end of 2027, companies using SAP ECC will inevitably have to deal with the migration to SAP S/4HANA.A reasonable approach to reduce the complexity of an SAP S/4HANA system conversion is to split the overall project into several preliminary projects or sub-projects. This strategy saves the company’s own resources and reduces the risk of the conversion.
The custom code and the individual functionalities are a suitable starting point for straightening out the SAP S/4HANA project. In general, the question of which enhancements have been implemented in SAP ECC plays an important role when planning an SAP S/4HANA system conversion. A custom code analysis provides helpful insights and clarifies which functionalities are still needed in SAP S/4HANA. Finally, only relevant code fragments are to be lifted onto SAP Cloud Platform. The custom code analysis also provides an estimate of the effort required to port the code identified as relevant.
The extensions to SAP ECC can then be implemented on SAP Cloud Platform using INCEMENDO.data_access so that they can be reused one-to-one after migration to SAP S/4HANA. INCEMENDO.data_access emulates the interfaces and services of SAP S/4HANA to ensure communication and data exchange between the business logic in SAP ECC and extensions on SAP Cloud Platform. This means that companies can already use the functionalities outsourced as side-by-side extensions in SAP ECC and later also in SAP S/4HANA without having to adapt them again after the system conversion. For the extensions it is irrelevant whether a classic SAP Business Suite or SAP S/4HANA is available as a substructure.
The implementation of side-by-side extensions has another advantage: By extracting their custom code from SAP ECC, companies follow SAP’s keep-the-core-clean strategy. The ERP core remains clean, which means that updates can be rolled out faster and the testing effort is reduced. At the same time, companies keep open the migration path to SAP S/4HANA cloud. With the change from the on-premise to the cloud variant, they benefit, among other things, from efficient maintenance and automatic updates without use of their own resources, preconfigured best practices for a shorter time-to-market and integration with other SAP applications such as SAP Hybris or SAP SuccessFactors.
Basically there are two types of extensions: frontend extensions and full extensions. With front end extensions, the business logic and data continue to run in the back end, and communication takes place via OData services. The front end itself does not process any data. Instead, it displays the results of the back end, for example via a Fiori app, and receives the user’s input. The resulting higher communication volume must be taken into account when designing the front end extensions so that it does not have a negative impact on performance and security.
With full extensions, the front end, business logic and data are located entirely on SAP Cloud Platform. There are two ways to synchronize the data between the ERP core and the outsourced extension:
Bidirectional synchronization using Smart Data Integration
Event-driven synchronization: SAP’s Event API informs the application on SAP Cloud Platform in the event of changes; data is synchronized as needed.
In both cases, the ERP system remains the master. The back end acts as the single source of truth, while the synchronization of data in the front end is ensured by the corresponding algorithms.
Extensions on SAP Cloud Platform are event-based or connected to SAP ECC via OData services. Their integration requires an SAP NetWeaver stack, which needs specific access to the relevant tables, interfaces and BAPIs to pull data from SAP ECC. Anyone who is already driving the standardized development of OData operations on the SAP NetWeaver stack will benefit from the fact that the applications can be migrated one-to-one as part of SAP S/4HANA system conversion. No further adjustments are necessary.