SAP S/4HANA Migration Cockpit FAQ

For SAP S/4HANA Cloud, the Staging approach is covered via Scope Item 2Q2 and that needs an activation ticket. For SAP S/4HANA Cloud the staging option will be only visible if the non-standard scope item Data Migration to SAP S/4HANA from Staging (‏2Q2‏) is activated. To do this, you have to request the scope item activation for 2Q2 via ticket on component XX-S4C-OPR-SRV. For more details, you can refer to: Data Migration to SAP S/4HANA from Staging (‏2Q2‏)
and to: FAQ for SAP S/4HANA migration cockpit - Transfer option: Transfer data from staging tables

Use synonyms to rename the tables and so that for your data export scripts and/or while using extraction tools, the destination is not changing even though the name of the staging table is changing.

For more details please see:

SAP HANA Developer Guide - Synonyms 
SAP HANA Developer Guide - Create a Synonym

Note: From 1809 FPS0 there is now a mapping table ‘/1LT/DS_MAPPING‘, which is provided in the same schema where the staging tables are generated. This table stores mapping information about the migration object, the source structure and the staging table name. You can use this table to determine the staging table names after you copy a project from a quality system to a production system and then use these names in your scripts or applications that populate the staging tables with data.

For more details or questions about staging tables you can see FAQ for SAP S/4HANA migration cockpit - Transfer option: Transfer data from staging tables

You can also find more information about creating and using synonyms for renaming staging tables in the following blog: SAP S/4Hana migration cockpit - Creating and using synonyms for renaming staging tables

Currently there are no plans to extend for other database types.

SAP S/4HANA migration cockpit was generally designed for the initial load of data into an S/4 Environment. An update functionality to Change already data in the target system is not the current scope of SAP S/4HANA migration cockpit. But we will take this requirement with us to discuss it with the colleagues responsible for the Content.

If z fields exist (SAP standard table is enhanced by a custom-own field) in the source system, the Migration Cockpit, Direct Transfer, recognizes it and these fields are automatically shown in LTMOM as source fields. In case the target fields which match exist, the Z source fields can be mapped in LTMOM in the field mapping to the target fields.

There may be single cases where Z fields are not covered by the API which is used in the migration object. In this case, open a ticket on component CA-DT-MIG.

The intention of SAP S/4HANA migration cockpit is to migrate data from an ERP system into the new S/4HANA world. For this, all the mapping logic regarding tables, data structures between these two environments is developed in SAP S/4HANA migration cockpit.

It is not a tool to load data permanently between several systems. To realize this, it would mean re-designing of the complete content of the migration objects. Example: the mapping between BSEG and ACDOCA would be invalid, as you would need a mapping ACDOCA - ACDOCA.

This means, bringing data from S/4-system A to S/4-system B in your own system landscape needs to be organized.

If the target system is an on-premise system, use the direct transfer approach. In the first place, this is independent from the deployment option or if the system is hosted. The prerequisite is that an RFC connection to the source system and back-end access is possible. If this is the case, use the direct transfer approach for the deployment option (S/4HANA Cloud STE).

In the Migration Cockpit (Fiori), you can only chose the predefined criteria. For selecting from an ERP source system, this is company code(s) and the predefined migration objects, e.g. migration object "cost center". If you just follow the procedure in the project view, you are right.

But there are different possibilities how to influence the selection and how to influence the migration of the selected items.

In LTMOM (Migration Object Modeler), you can adjust the selection from the source system. In our Migrating Your Business Data to SAP S/4HANA openSAP Course unit 6 and 7 of this week 3 you get more detailed information about these topics, especially about the so-called "technical selection".

After the selection you can also decide to skip single items from further processing in the Migration Cockpit/Fiori (see unit 3, slide 7).

In SAP S/4HANA migration object modeler one subproject is automatically assigned to one project. The subproject groups the migration objects. Each migration object is assigned to exactly one subproject. In turn, each subproject is assigned to exactly one project. It is not possible to assign more than one subproject to a project with the migration object modeler. The distinction of project and subproject has some technical reasons.

The new custom fields are automatically part of SAP S/4HANA migration cockpit for a file or staging migration objects.

For the direct transfer, you will also find the custom fields in the target structure API in LTMOM, if it is just added to the API structure by the custom fields and logic application. For the source field the behavior is different than for the file/staging approach. A custom field will only be seen in LTMOM in the source structure, if a corresponding custom field is also available in the source system. There is an automated DDIC sync between the source system and the target system in LTMOM and therefore this custom field will be seen in the source structure section in LTMOM, if available in the source system. The link between the source and target fields should be entered manually.