Most consultants with Legacy System Migration Workbench (LSMW) experience have never added ABAP code within their projects. As soon as you realise you can include complex decision making within data migration loads then a new world of possibilities emerge.

Before diving into the wondrous world of LSMW, this tool is not recommended on the S/4 HANA platform. Still, everything discussed in this blog post can also be applied in the new Data Migration Cockpit, allowing you to add your own data validation rules with BRF+. You need to realise that Business Rule Framework can be applied as soon as you execute ABAP code.

The LSMW step “Define Field Mapping and Conversion Rules” allows you to see the various locations to add ABAP code when you press Control+F7 and select all the “Determine Layout” checkboxes.

You see that every LSMW project has the following sections:

• Global data: Ideal for declaring constants, local variables, internal tables as well as adding parameters on the selection screen when you execute the “Convert Data” step.
• Begin of processing: Code that you can execute before processing any transactions, which is perfect for opening the application log.
• Begin of transaction: Use BRF+ to validate the data to prevent that bad data is processed and add messages into the application log.
• End of record: Save the individual record data to be processed within a single transaction. Normally you do not change any code in this section.
• End of transaction: Save the transaction data to be processed. Normally you do not change any code in this section.
• End of processing: Close the application log and display the application log after all transactions have been processed.
• Form routines: Location to maintain forms that can be called using the PERFORM statement.

Adding code within LSMW projects is extremely effective when you have to load a very high volume of IDocs with a high potential for failure during processing.

Imagine you need to migrate 1 million pricing master data records using IDocs triggered by the LSMW project and 1% will fail. Then you manually need to verify, update and reprocess 10 thousand IDocs. This is not humanly feasible at a project go-live. Instead, you need to make sure that only good data is processed and bad data is returned with specific instructions about why the data failed the validation step.

Handling this volume of data also requires the ability to run the “Convert Data” step in test mode and collect all warnings and errors without generating IDocs. That is why it is useful to all the test mode parameter to the selection screen when executing the “Convert Data” step, which is possible in the global data section of the LSMW project.

Integrating BRF+ functions within LSMW projects will allow you to scan the data and return messages that can be saved in the application log. The application log is can exported and used as a checklist to clean up bad data. You can design the project that only data is moved to IDocs when all records within a transaction passed the BRF+ validation. This way you can be sure that a high volume of IDocs will be loaded without defects. This will eliminate unnecessary stress during a project go-live.