- SAP Managed Tags:
In this blog there are insights to how is possible to consolidate n-ERP instances in a single one in a single client including historical data.
As you know the importance of business data has increased in the years and it happen often that customers ask to consolidate systems to reduce their footprint costs but also to keep the historical data from the original systems online in the new instance.
To migrate historical data it cannot be used traditional data load technologies but database (DB) loading technologies are required . Using this method data is migrated table by table directly in the database and the application layer is skipped. By design this approach increase the migration throughput but it doesn't guarantee the data consistency that must be verified at the end of the migration activities. To guarantee the data consistency data models and intelligent tools are used during the migration and transformation process.
The main challenge is that data needs to fit the underlying settings. When you have data from several sources the customizing settings of the target instance must consider the respective settings of the source systems. So before the data migration happen you need to create an harmonized shell (repository and customizing settings). This means if you move FI Data from system A and B you need to guarantee customizing in the target will be able to accept data from both systems. It means that the FI configuration in the target system is somehow a merge of the 2 configurations from system A and system B
but then it means...
if the configuration is deeply different you may not be able to merge 2 systems. For example migration among client A using Classical GL and client B using New GL can be very complex or nearly impossible. For this reason we strictly recommend a customizing comparison to understand how much are similar the systems you want to consolidate. If conflicts among customizing settings are critical it's maybe better before align the system (i.e. convert the classical GL to new GL)
You can display an ERP system like a "sandwich":
The orange part is the system template. In order to be able to run the data migration on DB level you should:
The outcome of the preparation activities are:
but you can include more....
based on specific limitations you can additionally improve the final results including more transformations to make the system lean:
Once you have defined and implemented the transformation rules to fit the target template you can proceed with the migration. Here the main challenge is to apply the rule consistently over the tables. The guiding principles to execute the migration are:
It means for example: I define a rule to rename the company code from A to B. The migration process must assure that the rule will be applied in all tables where the company code information is stored. The respect of those principles will safeguard the data consistency.
Rule cardinality has a very importance on these steps:
The correct application of rules to table fields and respect table dependencies is crucial to have a successful migration. Relation among table and table fields in an ERP system is very complex and even a simple mapping rule can generate high level of complexity. To perform the migration activities smoothly without errors data models to respect table dependencies and intelligent tools to apply rules to the right table fields are used.
I invited you to share this post if you liked and to leave a comment you will get at least a first level answer if you need more information about this blog please send an email to: mailto:sap_dmlt_gce@sap.com
As you know the importance of business data has increased in the years and it happen often that customers ask to consolidate systems to reduce their footprint costs but also to keep the historical data from the original systems online in the new instance.
To migrate historical data it cannot be used traditional data load technologies but database (DB) loading technologies are required . Using this method data is migrated table by table directly in the database and the application layer is skipped. By design this approach increase the migration throughput but it doesn't guarantee the data consistency that must be verified at the end of the migration activities. To guarantee the data consistency data models and intelligent tools are used during the migration and transformation process.
The main challenge is that data needs to fit the underlying settings. When you have data from several sources the customizing settings of the target instance must consider the respective settings of the source systems. So before the data migration happen you need to create an harmonized shell (repository and customizing settings). This means if you move FI Data from system A and B you need to guarantee customizing in the target will be able to accept data from both systems. It means that the FI configuration in the target system is somehow a merge of the 2 configurations from system A and system B
but then it means...
if the configuration is deeply different you may not be able to merge 2 systems. For example migration among client A using Classical GL and client B using New GL can be very complex or nearly impossible. For this reason we strictly recommend a customizing comparison to understand how much are similar the systems you want to consolidate. If conflicts among customizing settings are critical it's maybe better before align the system (i.e. convert the classical GL to new GL)
Create a new harmonized template
You can display an ERP system like a "sandwich":
The orange part is the system template. In order to be able to run the data migration on DB level you should:
- Compare the repository object over the system and harmonize the repository in the target system:
- Review your custom program and define which ones are requested in your system. If required you can rename programs or update programs to the last version.
- Analyze your enhancements and be sure that they will continue to work in the new consolidated system. Consider the same user exit can be active in more than one system with different purposes.
- Check your DDIC structure and verify that all data you need to migrate have a proper recipient. Here it can happen that different appends are active in standard tables.
- Analyse and compare customizing data among systems. Customizing data defines the processes and the shape of your data and this task is strictly related to process mapping. In general you have the following cases:
- Identical processes: in this case underlying customizing can be copied in the target system
- Similar processes: underlying customizing can be harmonized to create a version that fits all systems
- Different processes: underlying customizing must be renamed to create different processes in the target system
- Review your number range set up.
- Migration will require to apply renumbering rules in order to migrate documents that have the same key in different systems
- Same or similar processes they may use different interval settings on the system and you have to harmonize it
- You may want to have special renumbering rules in some areas in order to make it easy to recognize migrated documents.
Output of the harmonization activities
The outcome of the preparation activities are:
- A new template is applied to the target system
- Transformation rules
- Mapping rules to support the customizing harmonization
- Renumbering rules to overcome the technical limitation to store entries in the database with the same key
but you can include more....
based on specific limitations you can additionally improve the final results including more transformations to make the system lean:
- remove duplicates from your master data
- exclude data related to inactive organizational units like company codes and plants
- introduce new naming conventions
- consolidate organizational units like company codes
Migration Activities
Once you have defined and implemented the transformation rules to fit the target template you can proceed with the migration. Here the main challenge is to apply the rule consistently over the tables. The guiding principles to execute the migration are:
- One information one rule. An input value rule should behave always in the same way.
- A rule must be applied to all tables
It means for example: I define a rule to rename the company code from A to B. The migration process must assure that the rule will be applied in all tables where the company code information is stored. The respect of those principles will safeguard the data consistency.
Rule cardinality has a very importance on these steps:
- 1:1 rules are always applicable (A -> B)
- n:1 rules must be verified with the application. If you merge plants A and B you need to consider the consequences
- 1:n - n:m rules are usually very complex and it must be verified by application and technical team. The reason is very often because splitting rules 1:n cannot respect the principle to apply the rule at the same way to all tables.
The correct application of rules to table fields and respect table dependencies is crucial to have a successful migration. Relation among table and table fields in an ERP system is very complex and even a simple mapping rule can generate high level of complexity. To perform the migration activities smoothly without errors data models to respect table dependencies and intelligent tools to apply rules to the right table fields are used.
Conclusion
I invited you to share this post if you liked and to leave a comment you will get at least a first level answer if you need more information about this blog please send an email to: mailto:sap_dmlt_gce@sap.com
