Blog Written By: Cole Fennel, www.colefennel.com
If you are performing a greenfield implementation of S/4HANA you will need to get familiar with the S/4HANA Migration Cockpit, the go-to conversion tool for Financial master and transactional data in S/4HANA. The S/4HANA Migration Cockpit is an application (with a FIORI front end) included in S/4HANA that provides pre-built migration objects that can be customized and enhanced, with the ultimate goal of making data migration to S/4HANA as easy as possible.
Up until release 1909, the S/4HANA Migration Cockpit was typically used to migrate data from flat .XML files that were populated using Microsoft Excel. All data would first be extracted from the source system into these files and then these files would be imported into the S/4HANA Migration Cockpit where they would be validated and ultimately migrated into the S/4HANA system. In addition to the flat file approach, there was an alternate staging table approach available that would load the objects from staging tables that were populated using an external data load tool.
In the 1909 release of S/4HANA, SAP released new functionality in the S/4HANA Migration Cockpit to support direct data transfers from existing SAP ERP systems. This removes the need to manually extract data into flat files, and allows a direct RFC connection to pull the data from a customer’s existing SAP ERP system (as long as it meets the prerequisites, described more in Tip 1 below). As a user of the S/4HANA Migration Cockpit’s direct transfer approach, I wanted to provide some tips and hints for doing so, from my experiences. This won’t be a full implementation guide and will be highly summarized to keep it useful as a blog. I will link additional resources with full technical documentation at the end. I will cover a few questions that you will likely come across if using the S/4HANA Migration Cockpit’s Direct Data Migration for the first time.
The first two are boring pre-requisites, but make sure you have those taken care of before starting or you won’t make it very far.
Before you get started using the S/4HANA Migration Cockpit, you’ll likely need to install SAP notes into your existing (source) and new S/4HANA (target) landscape. Here are a few items that are required:
Source System (existing SAP ERP system)
Target System (S/4HANA 1909 or higher)
In addition to the BASIS requirements, you’ll need the following users created and roles assigned.
S/4HANA Data Migration User (your personal user in S/4HANA, as the Data Migration Expert)
SAP ERP RFC User (this user will need to be created in the source SAP ERP system, and will be used for the RFC connection between the two systems)
Previously, the S/4HANA Migration Cockpit would be accessed via transaction LTMC. LTMC is still used for the file and staging table approach for data conversion, however, the new direct transfer functionality is accessed via the FIORI Launchpad.
If you have the correct security roles assigned, you should see the following tile under the Data Migration tab.
By clicking the tile, you’ll be brought to the S/4HANA Migration Cockpit.
The first step for migrating data is to create a “Migration Project” in the S/4HANA Migration Cockpit. The Migration Project is used to represent a single test migration iteration between a source and target system. You will name the Migration Project, select the scenario (in this blog I am talking about SAP ERP to SAP S/4HANA), and select the RFC connection between the two systems. After that, you’ll select all relevant migration objects to be included in the Migration Project. This includes all master and transactional data objects relevant to your scenario. The list is long and includes objects like Business Partners, Cost Centers, G/L Accounts, Sales Orders, Fixed Assets, etc.
If you are converting data to multiple clients in S/4HANA, you will want to create a separate Migration Project for each client. For example, in a QA environment you might need to migrate data to two separate SAP S/4HANA clients in parallel to allow for two different test clients. You would need to create two separate Migration Projects, one for each target client.
The backend tables that keep track of key mappings and migrated data are all based on the Migration Project, and not based on the target SAP clients, so if you do not create two separate projects you’ll get an error that says "Source record <Record Info> already transferred to target system” when trying to convert the data to the second client.
If you are able to access the S/4HANA Migration Cockpit Tile and create a project, a good test to see if you have the connection setup successfully between S/4HANA and SAP ERP is to create a Migration Project. When you select the RFC as “Connection to Source System”, it should automatically pull all Company Codes from your existing SAP ERP system for you to select. If it successfully displays all Company Codes from your source SAP ERP system without throwing an error, you are off to a great start! That means the RFC user successfully called the DMIS add-on installed in the SAP ERP system, and had the credentials required to fetch information.
Once the Migration Project is created and the Migration Objects are created, you can open up a Migration Object (such as FI – Cost Center) and Select Data from the source SAP ERP system. This will import all relevant Cost Centers from the source SAP ERP system into the cockpit’s staging areas.
An important feature to be aware of is that once a record is selected from the SAP ERP system and brought into the cockpit’s staging area, it will not be updated if you re-select the data. Heike Jensen wrote a very clear blog that explains how to re-select data, so rather than repeating it, I will link it here. This is definitely something you will need to be familiar with when working through a data migration, as there will be times you’ll need to change source data and then re-select it before importing it into S/4HANA.
https://blogs.sap.com/2020/04/04/sap-s-4hana-migration-cockpit-direct-transfer-can-i-repeat-the-sele...
When migrating data, you’ll need to complete several value mapping tasks in the Migration Cockpit. Some of them may be relatively straightforward, for example mapping one company code to one company code. Many may not need any mapping at all and will simply need your confirmation that values remain the same. However, if you have a mapping that has 1000+ possible values mapped to 1000+ possible values, you’ll want a way to upload that mapping via a flat file. Manually entering the mapping via the FIORI interface would not be a good use of time.
The good news is you can import mappings such as these in transaction LTMOM (I’ll elaborate on LTMOM more in a separate tip). However, you can only import the mappings via file before you have successfully migrated data for any migration objects using that mapping. Once you have migrated a record, you will not be able to import the mappings via file in that Migration Project. So I highly recommend to get your mappings in order BEFORE you migrate a single record in the Migration Project.
Again, Heike Jensen wrote a great blog about this, so rather than re-describing it I’ll link her blog below.
https://blogs.sap.com/2020/04/04/sap-s-4hana-migration-cockpit-direct-transfer-value-mapping-1909/
Several blogs could be written about this subject, but the Migration Object Modeler, accessed via transaction LTMOM, is a very powerful tool. It can be used to see and manipulate almost everything in the migration process including field mappings, value mappings, custom ABAP conversion rules, and even creating completely custom migration objects.
As an ABAP developer, and a user of many SAP migration technologies (including BIB for SuccessFactors, PTP for Employee Central Payroll, etc), I found the debugging experience to be extremely smooth while using the S/4HANA Migration Cockpit. The real strength in the pre-built migration objects is they all use BAPIs to import the mapped data. And, LTMOM gives a direct mapping of the source structures to the BAPI Function Module, so you have complete visibility to what is being mapped.
You can find the relevant BAPI either by looking in LTMOM, or reading the Migration Object documentation. Just go to SE37, put a breakpoint at the beginning of the BAPI, kick off a simulation in the Migration Cockpit, and you should be able to see what exactly is happening when the BAPI is called.
If you know where to look, there is a solid supply of resources for using the S/4HANA Migration Cockpit's Direct Transfer approach. I already put a few above, but here are some resources to further educate yourself.
If you are performing a greenfield implementation of S/4HANA you will need to get familiar with the S/4HANA Migration Cockpit, the go-to conversion tool for Financial master and transactional data in S/4HANA. The S/4HANA Migration Cockpit is an application (with a FIORI front end) included in S/4HANA that provides pre-built migration objects that can be customized and enhanced, with the ultimate goal of making data migration to S/4HANA as easy as possible.
Up until release 1909, the S/4HANA Migration Cockpit was typically used to migrate data from flat .XML files that were populated using Microsoft Excel. All data would first be extracted from the source system into these files and then these files would be imported into the S/4HANA Migration Cockpit where they would be validated and ultimately migrated into the S/4HANA system. In addition to the flat file approach, there was an alternate staging table approach available that would load the objects from staging tables that were populated using an external data load tool.
In the 1909 release of S/4HANA, SAP released new functionality in the S/4HANA Migration Cockpit to support direct data transfers from existing SAP ERP systems. This removes the need to manually extract data into flat files, and allows a direct RFC connection to pull the data from a customer’s existing SAP ERP system (as long as it meets the prerequisites, described more in Tip 1 below). As a user of the S/4HANA Migration Cockpit’s direct transfer approach, I wanted to provide some tips and hints for doing so, from my experiences. This won’t be a full implementation guide and will be highly summarized to keep it useful as a blog. I will link additional resources with full technical documentation at the end. I will cover a few questions that you will likely come across if using the S/4HANA Migration Cockpit’s Direct Data Migration for the first time.
The first two are boring pre-requisites, but make sure you have those taken care of before starting or you won’t make it very far.
1. First, ensure all of your BASIS requirements are met
Before you get started using the S/4HANA Migration Cockpit, you’ll likely need to install SAP notes into your existing (source) and new S/4HANA (target) landscape. Here are a few items that are required:
Source System (existing SAP ERP system)
- Must be running at least SAP ERP 6.0
- Must be running at least SAP NetWeaver 7.0
- Must install add on DMIS_2011_1 SP17 or higher
- This will likely not be installed already in your source system, so you’ll need to install this component, which is used for the data extraction. For more information on installation reference SAP note 1577441.
Target System (S/4HANA 1909 or higher)
- Must be running S/4HANA 1909 or higher
- Must have FIORI launchpad installed and functional
- Must install required SAP Notes for S/4HANA Migration Cockpit – Direct Transfer
- SAP Note 2819445 gives an overview of what needs installed
- There will be a significant amount of notes to install initially. To combat this, SAP developed a report described in Note 2596411 that can be run to highlight any notes that are missing and / or need installed. Please note, you may have 50 notes to install… but most require no user input and are small program fixes.
2. Ensure you assigned the correct security roles
In addition to the BASIS requirements, you’ll need the following users created and roles assigned.
S/4HANA Data Migration User (your personal user in S/4HANA, as the Data Migration Expert)
- To use the Data Migration Cockpit, you’ll need the following the following roles assigned to your user:
- SAP_BR_CONFIG_EXPERT_DATA_MIG
- SAP_DMIS_OBT_MASTER
- SAP_CA_DMC_MC_DEVELOPER
SAP ERP RFC User (this user will need to be created in the source SAP ERP system, and will be used for the RFC connection between the two systems)
- It is recommended to create a user of type communications, not a dialog user.
- This user will be used for the RFC calls between S/4HANA and SAP ERP
- Must have the following role assigned in the source system:
- SAP_DMIS_OBT_REMOTE
3. Accessing the S/4HANA Migration Cockpit is different for the direct transfer approach
Previously, the S/4HANA Migration Cockpit would be accessed via transaction LTMC. LTMC is still used for the file and staging table approach for data conversion, however, the new direct transfer functionality is accessed via the FIORI Launchpad.
If you have the correct security roles assigned, you should see the following tile under the Data Migration tab.
By clicking the tile, you’ll be brought to the S/4HANA Migration Cockpit.
4. Organize your Migration Projects appropriately
The first step for migrating data is to create a “Migration Project” in the S/4HANA Migration Cockpit. The Migration Project is used to represent a single test migration iteration between a source and target system. You will name the Migration Project, select the scenario (in this blog I am talking about SAP ERP to SAP S/4HANA), and select the RFC connection between the two systems. After that, you’ll select all relevant migration objects to be included in the Migration Project. This includes all master and transactional data objects relevant to your scenario. The list is long and includes objects like Business Partners, Cost Centers, G/L Accounts, Sales Orders, Fixed Assets, etc.
If you are converting data to multiple clients in S/4HANA, you will want to create a separate Migration Project for each client. For example, in a QA environment you might need to migrate data to two separate SAP S/4HANA clients in parallel to allow for two different test clients. You would need to create two separate Migration Projects, one for each target client.
The backend tables that keep track of key mappings and migrated data are all based on the Migration Project, and not based on the target SAP clients, so if you do not create two separate projects you’ll get an error that says "Source record <Record Info> already transferred to target system” when trying to convert the data to the second client.
5. A quick way to initially test the Direct Connection
If you are able to access the S/4HANA Migration Cockpit Tile and create a project, a good test to see if you have the connection setup successfully between S/4HANA and SAP ERP is to create a Migration Project. When you select the RFC as “Connection to Source System”, it should automatically pull all Company Codes from your existing SAP ERP system for you to select. If it successfully displays all Company Codes from your source SAP ERP system without throwing an error, you are off to a great start! That means the RFC user successfully called the DMIS add-on installed in the SAP ERP system, and had the credentials required to fetch information.
6. Be aware of how to Re-Select data from the source system
Once the Migration Project is created and the Migration Objects are created, you can open up a Migration Object (such as FI – Cost Center) and Select Data from the source SAP ERP system. This will import all relevant Cost Centers from the source SAP ERP system into the cockpit’s staging areas.
An important feature to be aware of is that once a record is selected from the SAP ERP system and brought into the cockpit’s staging area, it will not be updated if you re-select the data. Heike Jensen wrote a very clear blog that explains how to re-select data, so rather than repeating it, I will link it here. This is definitely something you will need to be familiar with when working through a data migration, as there will be times you’ll need to change source data and then re-select it before importing it into S/4HANA.
https://blogs.sap.com/2020/04/04/sap-s-4hana-migration-cockpit-direct-transfer-can-i-repeat-the-sele...
7. Mapping tasks can be completed in the FIORI application, or by file, but only before successfully migrating records
When migrating data, you’ll need to complete several value mapping tasks in the Migration Cockpit. Some of them may be relatively straightforward, for example mapping one company code to one company code. Many may not need any mapping at all and will simply need your confirmation that values remain the same. However, if you have a mapping that has 1000+ possible values mapped to 1000+ possible values, you’ll want a way to upload that mapping via a flat file. Manually entering the mapping via the FIORI interface would not be a good use of time.
The good news is you can import mappings such as these in transaction LTMOM (I’ll elaborate on LTMOM more in a separate tip). However, you can only import the mappings via file before you have successfully migrated data for any migration objects using that mapping. Once you have migrated a record, you will not be able to import the mappings via file in that Migration Project. So I highly recommend to get your mappings in order BEFORE you migrate a single record in the Migration Project.
Again, Heike Jensen wrote a great blog about this, so rather than re-describing it I’ll link her blog below.
https://blogs.sap.com/2020/04/04/sap-s-4hana-migration-cockpit-direct-transfer-value-mapping-1909/
8. Get familiar with the Migration Object Modeler (LTMOM)
Several blogs could be written about this subject, but the Migration Object Modeler, accessed via transaction LTMOM, is a very powerful tool. It can be used to see and manipulate almost everything in the migration process including field mappings, value mappings, custom ABAP conversion rules, and even creating completely custom migration objects.
9. Take advantage of debugging, it’s never been easier
As an ABAP developer, and a user of many SAP migration technologies (including BIB for SuccessFactors, PTP for Employee Central Payroll, etc), I found the debugging experience to be extremely smooth while using the S/4HANA Migration Cockpit. The real strength in the pre-built migration objects is they all use BAPIs to import the mapped data. And, LTMOM gives a direct mapping of the source structures to the BAPI Function Module, so you have complete visibility to what is being mapped.
You can find the relevant BAPI either by looking in LTMOM, or reading the Migration Object documentation. Just go to SE37, put a breakpoint at the beginning of the BAPI, kick off a simulation in the Migration Cockpit, and you should be able to see what exactly is happening when the BAPI is called.
10. And finally, check out these excellent resources
If you know where to look, there is a solid supply of resources for using the S/4HANA Migration Cockpit's Direct Transfer approach. I already put a few above, but here are some resources to further educate yourself.
- SAP Documentation on S/4HANA Migration Cockpit
- Great and free OpenSAP Course on Using the S/4HANA Migration Cockpit
- Blogs by Heiki Jensen
- heike.jensen#content:blogposts
- SAP Managed Tags:
1 Comment
