The successful implementation of new systems such as SAP S/4HANA is closely related to the quality of the data. No data, no go-live. For that reason, it is wise to give data migration the attention it deserves and to carefully organize the transfer of data from the old systems to the new environment. If you want to learn more on that subject (and the importance of preparation), please check out my earlier blog on Data Migration.
In this blog, for this blog I’ll focus in on the team structure. This is quite a complex topic. To keep this blog concise, I’ll only scratch the surface of team structure in the context of data migration. (And if you need more details than this brief blog conveys, feel free to contact me. Or discover our insights and lessons learned on moving to S/HANA.)
Data Migration isn’t a side project
I was involved in various data migration projects in recent years. It strikes me every time that people underestimate how much time a migration project takes. And I don't just mean the time it costs the IT partner, but also the time it costs the customer. Although people often think otherwise, you can't do data migration 'on the side'.
This has everything to do with the fact that correct data is essential for the adoption and successful use of the new system. Technically, the system can be completely in order. But when orders are delivered incorrectly, products are not configured correct, and the wrong items are purchased, colleagues will start complaining about the new system. You’ll lose trust, and maybe even customers. That’s why we say: no go-live without data. Ninety percent of a data migration project is preparation.
Especially for companies that offer a wide range of products and services to customers, data targeting needs are quite complex in nature and volumes are quite important. That means that data migration involves coordination with various operational functions, plants, and external agencies. That means that you really need to plan and to prepare. It also means that your project needs a smart structure that helps you to involve the right people.
Building the triangle
Recently I was involved in a project where the information from 100+ different objects had to be migrated to the new environment. Objects like materials for example. We migrated over 4500 different materials from the old to the new system.
The job before that revolved around millions of records that had to be transferred.
Despite the difference in size, the approach is similar. You take the same steps, following the ETL approach. ETL stands for Extract, Transform and Load. First you extract the data from the source systems. Then you transform the data based on business and mapping rules. After that step, the data is loaded to the target system. Ideally the data cleansing will take place in the source system, but in many cases must also be taken care of in the extract or transform step.
A successful data migration project benefits from a good division of roles in which it is very clear how the responsibilities are divided. In our approach we like to involve the business, functional people, and technical people. This translates to a triangle that consists of the Data Migration team, working closely together with the functional core team structure and the local team structure.When building that structure and setting up the project, it’s key that you make sure that each part of your triangle knows it’s responsibilities. In most steps of the migration project, at least one team is accountable and responsible, while the other two teams need to be informed and/or consulted. This balance shifts from step to step of course.
A key aspect of a successful data migration is the selection of the data that is to be loaded into the new system. This is where the local team structure comes in. This part of the triangle for example, needs to decide on the data. Of course, you can take ‘customers with whom we have been doing business the last three years’ as a rule. You can also use a more elaborate scoring model to decide on the data that needs to be uploaded to the new system. Such a model works best for the migration objects customers, vendors, and materials. It can, however, also be used successfully for other migration objects.
The local team is not only responsible for defining the migration selection rules. It’s also responsible for the extraction itself and any associated developments to extract that data. Also cleansing, harmonizing, and enhancing the data is done by the local team. After the data is loaded to the new environment, the local team validates the loaded data and possibly performs manual or semi-automatic corrections.
The functional people of course, can translate the requirements of the business to the IT system. This team is responsible for the functional operation of the new system. Does the new solution do what it's supposed to do? Do we deliver what the business needs? They also play an important role in the data migration process. It’s their job to make sure that the scope and structure of the data to be uploaded to the system will perfectly fit the scope of implementation and the relevant business processes. Further on in the project, the functional team will also analyze the result per object, and suggest changes like additional validation rules, additional error messages, additional conversion rules, etc.
Data Migration team
The Data Migration Team will carefully plan all data migration activities as part of the global implementation planning, in coordination with functional core team. The migration plans of the various sites involved can of course be derived from client’s implementation roadmap. The team will also develop the tools for data upload to client’s system. And they are responsible for the activities of unit test and one or more trial migrations. During the final go-live, the data migration team pushes the master data and transactional data into the system, according to a careful composed cutover plan.
Connecting the dots
In the middle of that triangle is the director who allows all these parties to interact with each other and who can also quickly switch with important stakeholders and decision makers in the organization. Often, we take this central role and function in the middle of the triangle, connecting the Data Migration Team, Functional Core team, and Local team. My colleagues and I have a real passion for being the cement between these different teams. If needed, Expertum can of course be part of all triangles. Next to being the conductor of the project, we can offer supporting knowledge and operational skills in the relevant teams, helping to ensure the success of our customer’s project.
Even if all the different responsibilities are spread over the different teams in the triangle and everything is conducted from the center, one thing needs to be very clear… To make the data migration project a success, the different teams need to act and to work together as ONE team.
And if everything is done right, you’ll experience the joy of pushing the button and discovering how your data smoothly transfers to the new environment. It will be something you haven’t done alone, and on the side, but together with a multidisciplinary team. Enjoy!
Get more insights
Are you curious about how you make data migration a success? Feel free to contact us. Or download our lessons learned on moving to SAP S/4HANA if you are curious to learn from our experiences on recent projects.