SAP S/4HANA Migration Cockpit FAQ

FAQ on SAP S/4HANA Migration Cockpit provides information necessary to start and lead a migration project successfully.

Files/Staging Tables

Is it necessary to activate staging tables via raising a ticket? (SAP S/4HANA Cloud)

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: https://rapid.sap.com/bp/#/scopeitems/2Q2
and to KBA 2733253 - FAQ for SAP S/4HANA migration cockpit - Transfer option: Transfer data from staging tables: https://launchpad.support.sap.com/#/notes/0002733253

Is it possible that every project in every environment has exactly the same table names?

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 KBA 2733253 - FAQ for SAP S/4HANA migration cockpit - Transfer option: Transfer data from staging tables:  https://launchpad.support.sap.com/#/notes/0002733253

You can also find more information about creating and using synonyms for renaming staging tables in the following blog: https://blogs.sap.com/2020/04/15/sap-s-4hana-migration-cockpit-creating-and-using-synonyms-for-renaming-staging-tables/

Is there any plan to add support for other database types (Oracle, MS SQL Server, etc.)?

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

Can I create my own 'update' object in SAP S/4HANA migration object modeler using a copy of the standard 'insert' object?

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.

Direct Transfer

What is the approach of migrating customer data field (z field) from ERP ABAP system?

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.

Are there any plans of extending the direct transfer scenarios to the possibility to migrate from S/4HANA to S/4HANA system?

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.

Is Direct Transfer available for SAP S/4HANA Cloud, single tenant edition?

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).

Using RFC connection, will all data be replicated from the source to the target system? For example, all 1000 cost centers in source, based on migration object, will be replicated to the target?

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 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).

Migration Object Modeler

The object browser tree contains the structure element "subproject". Is this subproject automatically generated? Can I create more than one subproject?

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.

When you use In-App Extensibility to add Custom Fields they are automatically included in the migration File template: - Does this also work for the Staging approach - On-premise & Cloud? - Does this also work for Direct Transfer

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.