SAP S/4HANA Migration Cockpit: Simplifying Data Migration

The Migration Cockpit is integrated with the SAP Activate methodology, which essentially delivers a more structured implementation and migration to S/4HANA. Exactly here comes the SAP S/4HANA Migration Cockpit.

To provide businesses with a smooth and errorless migration, the Migration Cockpit offers preconfigured migration objects, guided processes, and real-time monitoring. It was hence designed to ease and even automate the data conversion process. Above all, it makes any extraction, transformation, and loading (ETL) very easy, reducing risk while saving time and effort, whether the data is from a legacy system or is for a greenfield project.

The complexities of SAP’s Migration E2E process will be covered in detail in this blog article, giving you a thorough how-to for a smooth and effective data migration.

What is the SAP S/4HANA Migration Cockpit?

This is the renovation of SAP S/4HANA Conversion Cockpit, more commonly known as the Legacy Transfer Migration Cockpit or LTMC, for allowing data conversion to SAP S/4HANA. With release 1610, it was introduced toward the close of 2016.

The LTMC uses the Legacy System Migration Workbench (LSMW) migration tool, which SAP S/4HANA no longer supports. SAP does not promote the LSMW, and it can only be utilized under certain limits under SAP S/4HANA.

As an integrated component of SAP S/4HANA and SAP S/4HANA Cloud, SAP provides the migration cockpit without requiring an extra license or payment. It can be helpful to employ extra tools.

Who is the SAP S/4HANA Migration Cockpit intended for?

Projects of light to medium complexity can use the Migration Cockpit.

Data can be moved to SAP S/4HANA from one or more source systems using the SAP S/4HANA Migration Cockpit. Whether the data originates from a SAP system or one that is not is irrelevant.

Template files (templates) are the basis for data transfer. These could be staging tables or XML files in Excel. Direct transmission is now an option, though (since Release 1909).

The SAP S/4HANA Migration Cockpit is the only migration tool currently offered by SAP, while alternative solutions (such as SAP Data Services) are available for transfer to an on-premise system. It’s also important to evaluate the right SAP S/4HANA deployment options early on, since migration approaches can vary depending on whether the system runs on-premise, in the cloud, or in a hybrid setup.

The SAP S/4 HANA data migration process consists of the following points:

Pre-migration actions/steps

Step 1: Migration Strategy

A migration strategy can and should immediately be established, whereby data will flow from the old system to the new one.

There are a few differences when it comes to data migration between SAP S/4HANA Cloud (SAP S/4HC) and on-premises implementations. The same data loads are frequently repeated for clients and partners who have previously used on-premises versions of SAP software. In order to optimize the loads from a performance perspective and refine the data quality, the same collection of files is loaded again.

Technically, this is accomplished by either updating the test client from a golden client or by returning the SAP system to a condition that existed just before the test execution cycle. However, SAP S/4HC lacks these client and/or system refresh principles, and alternative techniques are employed to effectively evaluate data migrations before production loads.

The right strategy for a given system can be determined by a variety of factors. Among the subjects to think about are, but are not exclusive to:

• The amount of company information that needs to be transformed and moved
• Permitted downtime for businesses
• During migration, the scope of data changes.
• Data types that are subject to migration
• Verify the source system’s business data quality and customize

The type of data used for migrations is master and transactional data. The difficulties generally come with the database master data since one cannot just keep loading the same datasets because of primary key constraints (e.g., product number, business partner number, etc.). Transactional data on the other hand, generates a new number upon creating the documentation (e.g., sales order number); thus, it usually can be loaded many times, though some considerations hold here as well (for instance, legacy document number no longer being unique in SAP S/4HC).

Before entering further options, the first critical point is that both the IT and business teams should go through the data in the migration templates to check whether the data is complete and spot-check for suspicious accuracy before loading any data into S/4HC. This helps to find some errors that can be corrected before the system loading; however, it is one of the overlooked points. This will save you from that unfortunate circumstance of having loaded data that is not correct and needs to be corrected in the system, but cannot be reloaded anymore.

Customers have so far employed the following methods for data migration in SAP S/4HC.

Data is loaded progressively by beginning small and expanding the datasets with each load. For a big volume test, this method involves migrating the data in tiny steps until confidence levels increase. Load 1 BP, for instance, followed by 5, 15, 25, 50, and so on, until you have a sizable collection of several thousand. To ensure that nothing was overlooked and that the data is accurate, you should examine the data and run a few transactions through the system after each incremental data load is finished. After that, load the next progressive data set and make any necessary adjustments.

Prior to using the TEST system, test data loads are used on the DEV system. Before testing in the TEST system, you can adjust your data loads in the DEV system if your SAP S/4HANA Cloud landscape consists of three systems. This will enable you to resolve any problems with the quality of the data before the TEST system’s final testing.

Prefixing in Master Data: A Prefix is a string added to each load of data and is usually 1-2 characters long. The characters do not exist in master data and hence can be excluded while setting up an app in the system. This method of integration becomes a little burdened when heavy linking exists for each linked data to be Find and Replace in every template, for example, Customers to Sales Pricing and Sales Orders. This is an advantage because it gives the capacity to load the same datasets. A drawback, meanwhile, is that loads of junk data get into the TEST system.

Each approach can be considered for all migration projects, but an analysis should be made against the system architecture and data flow that affects migration.

Step 2: Select Migration Objects

After the question has been addressed, you need to identify the source of all the data, as well as the types of data (financial, transactional, historical, and master data) that must be moved from the legacy system to the SAP Cloud system. This strategy/overview was developed in collaboration with the business and process owners.

All upcoming processes and the final system’s setup should be known or underway in order to ascertain the necessary data.

You can locate the pertinent migration items associated with the data once all of the data has been identified.

• The following links will take you to the full list of migration objects.
• The migration items that are available for SAP S/4HANA
• The migration items that are available for Cloud-based SAP S/4HANA
• Overview of the cloud

Step 3: Get Data from legacy system(s) and perform data quality checks

History demonstrates that legacy data can be distributed across various data sources, each with its own critical fields and structures.

These resources may include:

• Third-party ERP solutions
• Microsoft products
• ERP systems from various legal bodies

You have two options for supporting the project during the migration process: use the “Sopra Steria solution-Data Migration OSDM” or your own ETL tool.

The following tasks will be assisted by choosing “Sopra Steria Solutions – Data Migration (OSDM)”:

• Check the quality of the data.
• Data transformation according to business rules
• Development, Quality, and Production will all be subject to the same corporate regulations.
• Rebuild the content of the upload structures.
• Assemble the required audit trails and reports.

The data from the legacy system should be routinely obtained and quality reviewed during the course of the project. We must start this as soon as possible. In an ideal world, the data would be restored from the old production system. The process is iterative until the quality is enough for go-live.

When dealing with HR and talent management systems, this kind of data validation is equally critical in the journey to SAP SuccessFactors integration, where accuracy and consistency directly impact user experience and compliance.

Step 4: Construct the right migration object structures by mapping and transforming data

Once the structure of the various operations has been established, you can move forward with mapping and converting the old data into the upload sheets.

The mapping and transformation rules for each selected migration object should be determined and approved by the business owners.

You can fill the migration object structures in a variety of ways:

The CSV files or the XML files?

Every file has a unique purpose. The XML file is utilized when the business owner or migration consultant manually fills it out. This can be useful for carrying out basic inspections or tests. The CSV structure is useful when utilizing an ETL program.

The ETL tool that would be utilized to carry out the mapping and transformation rules was chosen as part of the migration plan. This configuration allows us to request new upload files in the event that project-related rules change.

The following modifications must be discussed with or verified by the migration consultants:

• New custom fields
• Changes in procedures that affect the migration
• Changes made by SAP to the migration object structures

Since every mapping activity must align with the SAP S/4HANA system architecture, ensuring compatibility at this stage avoids downstream issues and accelerates migration success.

Migrating the data through Migration Cockpit (Simulate, Migrate)

Understanding SAP’s Migration Cockpit

A user-friendly tool made to make data migration easier is SAP’s Migration Cockpit. It enables companies to move data into SAP S/4HANA or other SAP systems from a variety of sources. The Migration Cockpit is versatile and is good for companies of all sizes. The solution could be installed on a corporate premise or in the cloud.

Requirements

Make sure your pre-requisites are checked off before you start:

• Target SAP system or SAP S/4HANA is available for operation
• Data Source: Prepare the migrating data in a compatible file format, which can be CSV, Excel, or XML.
• Migration Objects: Determine which particular data objects (such as customers, vendors, or materials) you wish to migrate and comprehend their relationships.
• Request the necessary authorizations (Migration Cockpit & Change/create for the selected data objects).

Access the Migration Cockpit

• Log in with the correct credentials to your SAP system.
• Access the Migration Cockpit through the SAP Fiori Launchpad.

Create a Migration Project

Click on Create to start a new migration project.

Create a project, name it, and choose the migration object related to the data you want to migrate.

Now decide on the source and target structure by mapping fields from your source file onto corresponding fields of the SAP system.

Download Migration Templates

• Download the template for each selected migration object.
• Templates are typically available in XML or CSV format.
• These templates provide the structure and field definitions for your data.

Fill Template with Data

• Open the downloaded template (e.g., Excel).
• Fill the template with your source data, which should adhere to the required format.

Upload the Data

• Upload the completed template files to the Migration Cockpit.
• The system will then transfer the data to staging tables.

Prepare Staging Tables

• The staging tables are created automatically for each migration object.
• Prepare these tables to receive the data.

Mapping Tasks

• Depending on the migration object, you may need to confirm mapping tasks.
• This step connects the data from your uploaded files to the correct values in S/4HANA.

Simulate the Migration

Run a simulation to preview the migration process and identify potential issues.

Review the simulation results and make necessary adjustments to the mapping and data.

Once satisfied with the simulation, execute the migration process to transfer the data into the SAP system.

Migrate the Data

• If the simulation is successful, then proceed with a live migration.
• The system will post the data to the S/4HANA tables.

Migration Results

• View the result to see the status of your migration after the migration stops.
• The data are shown to have been migrated.

Optional Correction File

• Create a correction file to address any errors or inconsistencies found during or after migration.
• Transfer data from the correction file to the staging tables.

Post-migration actions (Checks in the destination system and testing)

This part of the migration process is always underestimated. IT and business need to take the necessary time to handle all post-migration actions and run the predefined test cases.

To be able to use the migrated data within your testing runs, some actions need to be done:

The recommendation of SAP is that you do not migrate historical data, with the exception of some financial data. When historical data is required to be migrated (ex: monitoring of the % of completeness of a contract or a project), you should load the already processed amounts together with the unprocessed amounts. Afterwards, already processed amounts need to be handled and financially reversed.

Verify the migrated data under the SAP system to ensure accuracy and completeness.

Carry out required reconciliations and cross-checks to ascertain data integrity with regard to migration.

After conducting the required E2E business process testing with newly created data, the same tests need to be carried out with migrated data. Both tests must be successful to be able to sign off on the migration files.

Key Features of SAP S/4HANA Migration Cockpit

SAP S/4HANA Migration Cockpit is an abstraction meant to straightforwardly support the transfer of data into SAP S/4HANA systems. It offers a nice interface, some predetermined objects, and guided processes for migration of both master and transactional data, so that they can fairly upgrade and accurately build the migration action from legacy systems or other SAP systems onto S/4HANA.

A brief review of the main features of the solution:

Predefined Migration Objects:

• The cockpit offers a library of pre-configured migration objects, like customers, vendors, materials, etc., allowing users to select and map data to the corresponding objects in S/4HANA.

Guided Procedures:

• It walks the user through the entire migration from beginning to end, using a project name creation, to data upload, and monitoring, all from its very friendly interface.

Flexible Data Loading:

• The tool accommodates several means of loading data, such as by uploading files (using SAP templates in CSV, Excel, or XML formats) or by using staging tables.

Built-in Validation and Error Handling:

• The Migration Cockpit allows for data prechecks and possible error identification during migration to ensure the accuracy and consistency of data.

Monitoring and Tracking:

• A monitoring screen is provided in order to monitor the migration process, to check the status at every step, and to track down any issues that any arise.

Integration with SAP Activate:

• The Migration Cockpit is integrated with the SAP Activate methodology, which essentially delivers a more structured implementation and migration to S/4HANA.

No Additional Cost:

• Before or after licensing of SAP S/4HANA, Migration Cockpit is available without cost.

Benefits of SAP S/4HANA Migration Cockpit

• Reduced Complexity:

A guided, standardized process helps streamline this complex activity of data migration.

• Faster Implementation:

Streamlined process, along with predefined migration objects, speeds up implementation in general.

• Improved Data Quality:

Validation and error handling ensure the accuracy and consistency of data during its migration.

• Lower Migration Costs:

The tool lowers migration costs by automating many typical manual activities involved in data migration.

• Enhanced User Experience:

The simple guided procedures facilitate navigation and control during the migration process, thereby enhancing the usability for less-experienced users.