Data migration: a high-risk phase in an SAP project! How to avoid errors?
Data migration: a high-risk phase in an SAP project
Alain Rivet
Broadly speaking, there are 4 main types of SAP migration that require data migration. The one that was initially recommended by the publisher, the Greenfield, with the implementation of already existing Best Practices. And the alternative, which is the migration of choice, the hybrid migration (or Data Selective Transition, the official term used by SAP).
Finally, there are circumstances of transformation or reorganisation that require a reinstallation, and obviously the new SAP installation. For these 4 types of migration, the company will have to transfer the data from the old system to the new one.
In SAP, there are data fields whose content is completely free, but there are also fields whose content is structured: these are known as ‘Drop Lists’. These can be configuration points such as VAT codes, payment terms, etc. or basic data (item, customer, etc.) on which documents, such as invoices, are encoded. The basic data is managed by the company. The configuration data was created when the system was installed and has often evolved to meet the specific needs of the business. Depending on the migration scenario, all or some of the values in these fields change, and these changes seriously complicate each SAP migration.
If the company opts for a Greenfield migration, the team in charge of the migration will have to find correspondences between the values used in all the choice lists of the old system and those proposed in the best practices of the new system. The conversion effort required to complete this transition can be considerable.
In the case of hybrid migration (the Data Selective Transition), certain elements can be retained and others will have to be rethought, depending on what the company wants to modernise during the migration.
The choice of approach does not exclude the removal of all obsolete data, such as old establishments, old VAT codes, etc. Implementing SAP S/4HANA also involves mapping all the fields to be migrated with those in SAP. Here again, this scenario suggests that it will take months of effort to complete this work.
The secret of a successful migration: the SAP Data Dictionary
To successfully complete a migration, the data must be processed exhaustively. It’s a colossal task, but the project team has an ace up its sleeve: the SAP Data Dictionary. In simple terms, this is a database that stores all the tables and fields, along with their characteristics. For each field, it is possible to find its reference table if it exists. Using this repository, you can immediately find the changes made by the company to its ERP, identify the drop lists and list the possible values. Extracting the data enables us to check which values from these drop lists are still alive, i.e. still being used in the processes in place. For example, if there are 3,000 payment conditions modelled in the ERP, only 25 of them are actually in use. Migration is the ideal opportunity to clean up all this obsolete reference data.
The advantage of an approach based on the Data Dictionary is that it can automate all these checks and provide the project team with all the fields and values that require a decision to be made about their future. Another advantage is that we can work on real production data and therefore on the real configuration of SAP and its processes. We can systematise checks on absolutely all drop lists. It’s an approach that avoids unpleasant surprises. When you carry out a traditional data transfer, these values are identified after the analysis phase. You end up with a lot of unknown data that has to be analysed afterwards. Some of this data can have an impact on entire processes.
Industrialising the migration process is the key to success
In this migration methodology, you need to identify the objects that are going to be migrated, such as production orders, orders, suppliers, etc. You need to define how to extract all this data, and plan the mapping of these objects with those in the new system. You need to define how all this data is to be extracted, and map these objects to those in the new system. If the source system is SAP, having an ETL capable of reading all the tables and checking the data structures will be a key asset. If this is not the case, the mapping will have to be done manually and all the source tables and their equivalents in the target SAP system will have to be found. We will then look at the contents of the tables, drawing up a list of the values found for all the Drop Lists. The project team can then work on this data and decide whether to keep, modify or delete it. These transformations can sometimes be very complex and require code to make the necessary adaptations. It is the business users who will decide what to do with each piece of data. In this phase, you need to work on complete data and not on samples, before starting to think about data transformation.
If one key point is to rely on an ETL to carry out all the extractions, another key point is to ensure the right transformation tool. When several million records need to be migrated, using table view transactions or writing extraction programs is a waste of time, and office tools such as Excel or Microsoft Access are no longer sufficient. Cutting files into multiple fragments is just a last resort. When there are 25 conversions to be carried out on a single table, it quickly becomes impossible to manage correctly. Today SAP has more than 30,000 tables, and even if we’re far from using them all, we absolutely must banish all home-made approaches to data processing.
In a project to migrate to SAP S/4HANA, the team in charge of data migration will carry out the entire migration several times. There will be one migration to fine-tune the tools, one or more migrations to run the configuration tests, to enable user training, plus one or more ‘dry runs’ to check that data loading goes smoothly on D-day. Generally speaking, an SAP migration project involves between 3 and 5 data extraction/transformation/loading phases. To avoid inconsistencies and blockages, it is essential to automate these operations. It is totally unrealistic to expect to repeat such complex operations 5 times or more using Excel without making mistakes…
What’s more, you need to bear in mind that in large companies, an SAP project can be spread over several years. Between the time when the consultants put the first conversions in place, and the time when the migration actually takes place, a lot of data will have evolved. Data migration is a constantly evolving process. With each extraction, we can be confronted with changes. This is all the more reason to use tools and automate data migration as far as possible.
Are you planning a data migration project?
- S4IC is the commercial name of High-SEA company
- Open from Monday to Friday - 9am to 6pm
- Avenue Voltaire 3, 1300 Wavre
- +32 (0)2 880 91 10
- info@s4ic.com
- VAT : 0806 380 893
Copyright S4IC – 2021
