Data Migration

SAP is encouraging its customers to migrate to S/4 HANA to benefit from the new system and because the SAP ERP will receive support until 2030. Hence, we will see more companies migrating partially or fully to S/4 HANA on-premise or on the cloud.

This blog will walk through the process and tools to transform Business and Custom data to the S/4 HANA and S/4 HANA Cloud on a high level.

You can categorise your migration data by the Business and Custom data in your system.

PHASES:

For the Business data, SAP recommends following the SAP Activate Methodology to transition to SAP S/4 HANA on-premise and cloud. https://go.support.sap.com/roadmapviewer/

Written By Marcela Marquez

Written By Marcela Marquez

Senior SAP Developer Consultant

Marcela Marquez is one of our senior certified SAP developer consultants having several years of SAP ABAP development and implementation projects. She is a proud member of SAP Australian User Group (SAUG) and Women who code Brisbane. Her expertise in Object-Oriented programming, SAP HANA, ABAP RESTful and Fiori Elements makes her an extremely valuable team member.

S/4 HANA

Data Migration Blog, DalRae Solutions SAP Consultancy

In the Data Management workstream, the data loaded from the source systems need to be prepared and planned. According to the data volume management DVM, some configurations might need it for business objects for the on-premise solution and finally migrated with sufficient time and quality into your target system.

 

For the Custom code, the phases show below. 

Data Migration Blog, DalRae Solutions SAP Consultancy

Here, first you need to consider which custom code must be taken over and adapted for the S/4 HANA system. To achieve this, prepare the selected code by checking in production which has not been used and analyse which ones need to be adapted to the S/4 HANA database. Finally, make some functional fixes to that code and optimise it for the new target system.

For both Business and Custom data, there are different ways to transition to S/4 HANA and S/4 HANA Cloud.

The first one is called SYSTEM CONVERSION: when you usually migrate the data and your existing business processes. For example, you have an SAP ERP, AFS (Apparel and Footwear Industry) or EWM (Extended Warehouse Management) in place, and you do a system conversion and move on to S/4 HANA. As this is an on-premise transition, the data does not leave the system, and everything as it is, such as historical data, etc. Custom code must be prepared and adapted though. To transfer the data RFC functions are used.

Data Migration Blog, DalRae Solutions SAP Consultancy

Next is SELECTIVE transition, previously called landscape transformation, which is an in-between scenario where selected data is migrated. For instance, you migrate only a Company code or merge different systems. For this scenario, a customer project is needed. The SAP Migration Cockpit tool cannot be used.

The last one is called NEW IMPLEMENTATION: you start from scratch with a brand new SAP S/4 HANA or S/4 HANA Cloud, where you migrate dedicated data like open items and master data. SAP provides the SAP S/4 HANA Cockpit tool for this scenario.

During migration, there are three main tasks considered: extract, transform and load.

The first task is to extract the data from your source system (SAP, non SAP, or file-based) by files or directly accessing the data source. Then, transform the data if necessary, such as map fields and values, and finally load the data to the target system (SAP S/4 HANA or SAP S/4 HANA Cloud).

BUSINESS CODE DATA MIGRATION:

SAP recommends the use of the SAP Migration Cockpit to perform business data migration as:

  • It is included in the SAP S/4 HANA and SAPS/4 HANA Cloud licenses.
  • Supports customers with the “New Implementation” scenario.
  • No developer skills are required.
  • Step-by-step guidance through the migration process.
  • Preconfigured migration objects and rules.
  • Automatised cross-object value mapping.

Note that the SAP Migration Cockpit is not intended nor recommended to be used as an interface to frequently load data into a system or to mass change existing data. 

As the SAP Migration Cockpit supports the New Implementation scenario, the overall process is the following:

Data Migration Blog, DalRae Solutions SAP Consultancy

The simulation step is a great way to validate the integrity of the object in the target system. It displays issues, for instance, value discrepancies, that need to be fixed before migrating the object.

Now, if we go deep with the type of approaches for the transfer of the data to the SAP Migration Cockpit, these are the ones supported depending on the customer’s system and data volume.

Data Migration Blog, DalRae Solutions SAP Consultancy

The transaction LTMC can access the Migration Cockpit on the SAP on-premise system. On the Cloud system select the Migrate Your Data tile.

SAP on-premise system.

Data Migration Blog, DalRae Solutions SAP Consultancy

SAP Cloud System

Data Migration Blog, DalRae Solutions SAP Consultancy

CUSTOM CODE DATA MIGRATION:

SAP recommends the following checks and tools to perform Custom data migration:

The first step in preparing your Z code for the move to SAP S/4 HANA is to find what custom code is never used so it can be ignored (Custom Code Scoping). To perform this task, use the ABAP Call Monitor, transaction SCMON. SAP recommends running it for a whole year. Then, after activating the job in transaction SCMON, go to transaction SUSG to aggregate the data collected, so it does not get deleted.

Data Migration Blog, DalRae Solutions SAP Consultancy

Now, to detect unused code, if you already have a S/4 HANA system, use the Custom Code Migration App by uploading the data collected in SUSG. Otherwise, check the following tables: SUSG_PROG with field PROGNAME = Z* (run this in the background, as one year of data can cause the search to time out). TADIR with all your Z programs and classes and table TFDIR for your Z functions modules. Download the list of all the tables to compare them or create a report Z program.

Finally, remove unused code via Software Update Manager SUM or separate them by assigning a different package for future reference and exclusion from the migration process.

The next step in the Custom code preparation is the Custom code analysis, for which you can use the Custom Code Migration App. If you do not have the Custom Code Migration App, run the ABAP Test Cockpit (Transaction ATC), SQL Monitor (Transaction SQLM) and the SQL Performance Tuning Worklist (Transaction SWLT).

These tools will help to check for expensive SQL statements that could benefit from SAP HANA database features.

Custom Code Migration App

Data Migration Blog, DalRae Solutions SAP Consultancy

SQL Monitor

Data Migration Blog, DalRae Solutions SAP Consultancy

ABAP Test Cockpit

Data Migration Blog, DalRae Solutions SAP Consultancy

Current Custom Code analysis options.

After analysing the results and having the new S/4 HANA or S/4 HANA Cloud system in place, take action on items that need to be adapted. This is part of the Functional Adaptation step in the Custom migration process.  

The tool of choice for the functional adaptation is the ABAP Development Tools for Eclipse, where you can run the ABAP Test Cockpit on packages and get a list of quick fixes relating to changes that need to be made for SAP S/4 HANA and SAP S/4 HANA Cloud (ABAP in the cloud).

Data Migration Blog, DalRae Solutions SAP Consultancy
Data Migration Blog, DalRae Solutions SAP Consultancy

After the functional adaptation, perform Custom code optimisation by Code pushdown, performance tuning and improving the user experience.

The roadmap to transition to S/4 HANA and S/4 HANA Cloud regarding Business or Custom data requires preparation, transformation/conversion, and adaptation when migrated to the S/4 system. The steps mentioned in this blog intends to broaden your knowledge on this subject at a high level. You do not need to have a S/4 HANA system to start the preparation task as you can adapt your SAP ERP system as much as possible to be S/4 HANA ready and reduce time in your migration project.