Hello S/4HANA migration cockpit users,
in this blog we would like to share some best practices, either in documents or short videos.
OpenSAP Course on Data Migration with deep-dive into the SAP S/4HANA migration cockpit and the migration object modeler for self-studying – here
Migration Cockpit – Staging Tables
- Check backend Transcation DBCO if your database connection is available
- you need to white-list this connection in table DMC_C_WL_DBCO_OP; use SM30
- Naming convention staging tables: /LT1/DS<sys-id><consecutive number>
- due to technical reasons, staging tables are transparent tables – can be seen in SE11 – but are not used, only tables in HANA schema. To acces them you can use OpenSQL
- NUMC fields must have leading zeros SAP Note260849
- DATE fields are YYYYMMDD
Migration Cockpit – Short Learning Videos
- Learn how to personalize your view (e.g. to create an “active view” for your migration objects): Personalize View
Migration Cockpit ICF Services
- In the backend system call transaction /nsicf
- Activiate following services:
Migration Objects Overview
Find an overview on pre-delivered content for
On the right top corner you can access a crop-down list to choose the release you are working on.
MOM: New migration object – Create own function module:
- In general the API must be a function module (FM) – RFC capability is not required.
- OData and other techniques are currently not supported by the SAP S/4HANA migration cockpit.
- The pre-requisites are quite the same as the BAPI definitions in the BAPI Programming Guide
- The API must not execute ‘COMMIT WORK’ commands. The COMMIT control is handled by the Migration Tool
- Error Handling: All messages must be returned in a BAPIRET2 formatted table or structure.
- API should provide a test run flag to simulate the data creation
- Internal Buffers must be refreshed in case the API is called in test run mode to prevent buffer overflows and performance issues when calling in a loop
- Consistency Check: Write-enabled API methods must make all the necessary consistency checks to ensure that the modified or newly created instance is consistent.
- Plausibility Checks: All necessary plausibility checks must be done within the API
- If some of the prerequisites are not met, you can develop a wrapper (e.g. for old IDocs).
Find more details in SAP Note 2590165
MOM: Which function modules to use with newly created migration objects
- Only function modules that are released shall be used
- If a function module is released to be used by customers can be checked easily in SE37 -> „Attributes“ and “Released on” field.
- Example for a released FM:
- Example for a FM that is not released:
- You should also check the SAP Notes for the FMs they want to use to get more information and also error corrections, e.g. RFC_CVI_EI_INBOUND_MAIN: 2506041 – S4TWL – API RFC_CVI_EI_INBOUND_MAIN is obsolete in SAP S/4HANA; 2387032 – Maintain the Task field in the communication segment in RFC_CVI_EI_INBOUND_MAIN; 2518068 – Load Credit Management Data with RFC_CVI_EI_INBOUND_MAIN
- If you use SAPGUI 7.50 we recommand to unflag “SAP Fiori visual theme”
MOM: testing a migration object
When you created your own migraton object using a XML template, you may want to run a simulation/test. This report for kind of debugging funciontality is availabe from 1709 FPS01.
Please check note 2630182