As long as there are SAP systems in existence, the question of data migration will remain a core issue in virtually all SAP implementation projects. Starting with the quotation phase and the awarding of the order, the full scope of the data to be migrated, the complexity of the source data, and changes in the requirements for the data in future processes make the whole picture unclear. Nonetheless, an estimation of the expected costs is indispensable for the customer and the service provider.
This blog will consider and take a closer look at a few of the questions that are likely to be asked by project managers and sub-project managers on the part of both the customer and the service contractor at the beginning of an SAP S/4 HANA On Premise implementation project concerning the project and costs planning for the data migration.
Figure 1: Migration objects on master data level
The apparent and the real scope in data migration
An initial listing of the data to be migrated usually turns up even in the first project documents when drawing up the quotation (request for proposal). If that is not the case, the project description must be carefully looked through on the basis of process areas, functionalities and source systems so as to gain a starting basis for the scope. Basically speaking, the entire project scope should be looked at to obtain an estimate, since it is always necessary to reckon with the fact that the process areas either need to be restructured, set up on a completely new basis, or else the time is ripe for adding additional functionalities in an implementation project. The starting point is thus only an apparent scope.
The initial list only gives you a Y axis. The list becomes longer if the data is to be taken over from multiple source systems into an object. It is then necessary to take into consideration how the tasks are to be split up between the customer and the service contractor on the X axis. For that reason, an estimate requires a clear line of responsibilities on the horizontal level. As a minimum, the provision of data from the source systems (extraction activities), the data purification activities and the clarification and documentation of all open items should have conversion rules assigned to them. Ideally, the coordination of the sub-project areas of data migration should be split equally between the two parties.
A further point is the number of migrations runs and the supplying of the newly created system landscape with master data from the source systems. The classical approach to data migration envisages functional tests with an increasing number of datasets and a major test run (test run, close to production loads). However, it is advisable to bear in mind how the individual test phases of the process areas are to be fed with master data in any case. Regarding this point, the expectations of the project participants from the various sections often differ greatly. Nonetheless, part of all this is that the data migration receives feedback concerning the quality of the migration. An effective benefit is therefore gained with migration runs in which data is provided for the test phases. This gives you an additional (Z) axis for the scope that in turn must be oriented chronologically towards the overall project plan with loading activities.
Figure 2: Dimension illustration – scope of the data migration
Which dynamic and progressive factors need to be taken into consideration in the data migration?
A project lives from its progress. The progress trend is in turn highly dependent on the basic knowledge, experience and positively constructive motivation of the individual participants in the project on the part of the customer. At the beginning of the project, the gaze is directed forwards and employed in the structured setting up and depiction of the required functionalities and, if applicable, a redesign, in the future processes of the individual process areas. In the data migration, it is important—and even crucial—to not work in isolation from the sections and departments but instead to set up a regular exchange of ideas. Exchanging from the very beginning is a detailed inventory with the sections and departments of migration-relevant objects, the existing source data and its quality. In the second step, this goes one level deeper to the field level for the individual objects so as to set up structural field mapping. In the third step, this goes yet one more level deeper in the setting up of the mapping of values to the relevant field values. If a SAP system is a new territory on the customer side, then these steps will be all the more difficult, since the basic future data structure of the individual objects first needs to be conveyed, which is not exactly easy on the drawing board and in Excel spreadsheets. It needs to be taken into consideration that the data migration cannot wait with these steps, and the understanding and support for a continuous exchange must come from the very beginning through the project managers and the project participants.
The dynamism in the data migration constantly increase in the subsequent course of the project and requires a high degree of resilience, since the process areas progress in the design process of the future functionalities. What comes out of this is adaptations in the target system that initiate changes, extensions and modifications for the data migration. The change dynamism consequently goes on until the functionalities and processes have been completed. On the one hand, the data migration must remain ahead to be able to supply data for the tests, and on the other hand it lags behind so as to integrate the progress of the project into the data migration. In addition, there are surprises on a regular basis when data is extracted from the source systems and values in it that cannot be mapped and loaded turn up, because values in the settings of the lists of values in the target systems had not been taken into consideration at all up to now or else have not been clarified yet and therefore have not been set yet.
A further progressive factor is the increasing complexity if the interaction of individual functionalities is examined and tested in an integrative way. Not uncommonly the details for the migration need to be examined, clarified and reconciled again in an integrative way. This is the readjustment in the fields and values mapping program in the case of migration objects that have a supra-project character.
The time required in the data migration for the regular and highly necessary exchanges for clarification, reconciliation and readjustment is generally greatly underestimated.
Figure 3: Phase plan in the data migration
Which qualifying tasks and factors need to be taken into consideration in the data migration?
Qualifying factors are the requirements for documentation and the requirements for the verifiability of the results over the entire course of the project. This concerns the data migration to a special extent, since at the end, the result of the migration must be a result that can be traced back.
In the data migration, trackability and discipline in the documentation is a continuous task to retain: on the one hand to keep track in a dynamic environment, and on the other hand to be informative and effectively replaceable, delivering documentation in which the scope, methodology, selection rules, conversion rules and depiction of the results are clear and trackable. The quality of the documentation must lead to it being possible to verify and assess the results of the migration by the sections and departments of the customer. This aim can also only be achieved through collaboration and exchanges between the migration team and project participants from the sections and departments.
In addition, risk assessment and auditing must not be forgotten, since the data migration involves the core data of the company in the form of the master data and the transaction data concerning the basis for the continuation of the operative business in the new system environment.
If ,in addition, due to the regulatory requirements a qualification or a verification of the new system is required, there is an additional reconciliation-intensive level over the entire course of the project ,and in particular in documentation control while preserving defined test and release procedures.
Figure 4: Documentation requirements in the data migration
How is the data migration to be integrated into the project planning?
When looking at the tasks in the data migration— in particular an early beginning of the exchanges with the project—, participants from the sections and departments should be supported.
If also in the first phase of the project the focus is on the future depiction of the required processes, the data migration cannot wait until the implementation phase is initiated. The concept for the data migration needs the findings from early exchanges and the detailing of the scope of the migration-relevant objects.
It is advisable that within the project planning that the provision of the new development system should not be oriented solely towards the implementation of the customizing point of view, but instead take into consideration a previous form of access for preparatory work activities of the data migration.
The basic framework for data conversion must have been set up in advance and brought to life so that the data migration for tests and detail work in the process areas can supply data.
In the same way, the provision of the test system and subsequently the production system must be examined in the project planning with due regard for preemptive access for the data migration.
The data migration should never be completely concluded at the time of the go-live data with regard to the cutover and go-live scenarios. Transaction data for financial accounting always follows the specific conditions of a quarterly or annual statement of accounts of the financial accounting in the cutover process. If necessary, a master data delta for this should not be forgotten shortly before the go-live deadline. And in the first days after the go live, once again intensive teamwork for the smooth starting up of the financial accounting in the new system should be expected.
Likewise, it should not be forgotten in the planning that the sections and departments of the customer should check and release the extracted data before the migration and must check and confirm the results in the new system after the migration. A test run for the release and testing process is greatly to be recommended to realistically assess the that will actually be required for the production load and to have the procedures for all those involved clearly defined beforehand.
Figure 5: Approval and testing procedures
What aids can be used in the planning of the efforts?
It is risky to make a full and bulletproof estimate of all the aspects given in this blog before the beginning of the project. All the tasks of the X axis and Z axis on a horizontal plane can be put into a matrix and the known scope of the objects at the time of the estimation can be listed and estimated at a vertical plane. However, some hitherto unknown factors, obstacles and trend graphs will initially still remain unknown here. No project runs smoothly without extra polishing in the matching and without modifications in the details. Master templates for this can be found in the SAP information libraries or from the publishers of SAP-related books.
An approximate guideline value can be produced with a matrix of this type if the X and Y axes give plausible results.
Figure 6: Planning aids for the data migration
How can the efforts for the data migration be structured in a clear way? The simplest principle is a successive estimation of the costs. Separated from an overall cost, which in any case is usually expected when drawing up quotations, the context of the entire course of the project is a trend that suggests an estimation in stages. In an ideal case, it is best to split it into three phases. The preparation and conceptual planning phase, which extends into the implementation phase of the project, the test and adaptation phase, which extends from the implementation phase up to the integration and user acceptance test, and the deploy phase, which in the area of the data migration lasts from only comes to an end after the go-live deadline.
A basic rule of thumb could be this: taking the costs planning of the service contractor for the data migration, data purification and reconciliation topics in the same was as for the costs of the customer, since this is an overall service in the data migration. This is the only way to ensure that the results are sustainable, that data purification topics are tackled, the resources and costs for the required reconciliation taken into consideration and the knowledge of the data base and its transformation on the way to the new system remains in the company.
Summary
A data migration sub-project should not be seen in isolation as purely a data supplier for the project. The structure of the actual scope, the selection criteria, the transformation rules and the data checks go through a dynamic process that depends on the exchanges between the sections and departments on the one hand and the consultants on the other hand. Time should be allowed over the entire course of the project for settling the topics, detailed questions and dynamic adaptation requirements of the data migration. Access is required to the new system at an early stage to be able to structure the data for the relevant test scenarios for the integration of the data migration into the project planning. The costs planning can correspond to an estimated value at the start. Here a modular, phase-oriented structure with the corresponding reviews is advised on the way to a successful migration.
