Management
Learn a real-world example of a resource operating model, including the roles and responsibilities — for both business and IT — in achieving a successful data migration project. Arm yourself with detailed descriptions of what each role should do, when and how they interact with other roles, and how to deliver the migration objects successfully.
Key Concept
Identifying and involving the right resources and clearly defining their roles and responsibilities can help you achieve significant success in a data migration project. Over- defining roles can mean blurring the responsibilities. Under-defining the roles can affect the migration timelines and deliverables. Involving business representatives in your migration process and ensuring their availability at various stages along the process also factor into this role definition. Normally in large transformation, implementation, and rollout projects, data migrations are run as a separate track due to the complexity and magnitude of the data involved. There are many aspects to take care of to ensure the success of such a migration project. It is important to engage the right resources and define their responsibilities accurately, communicating it well in advance. It is essential for the conversion analysts to work especially with the design team and subject matter experts (SMEs) to ensure the migrations are aligned with the desired final design for the target system. To achieve a successful data migration, it is important to define a robust operating resource model along with specifying the roles and responsibilities of various stakeholders in the overall migration process.
I’ll discuss the model we used in a three-year, large transformation program for a Fortune 500 global semiconductor company. The program involved coordination across eight business groups to deliver five major projects with more than 1,000 individual end users. I’ll explain the roles and responsibilities we defined for each role specific to migrations in the project that helped us accomplish the production migrations on time, convert clean and precise data, avoid post-go-live conversion resource costs, ensure early stabilization exit, and achieve smooth business process execution using converted data right from the day of go-live. I’ll also explain the importance of the participation of members of the business in the whole process by answering the basic questions: why, where, what, when, and how.
Involving the Right Resources
Often there is a misconception that migrations are the responsibility of the IT team. In reality, business users own the data and use it in their day-to-day transactions and should be responsible for the quality and accuracy of migrated data. For this to happen, SMEs and business users should be engaged early in the migration process.
The idea of bringing together various stakeholders as part of an operating resource model is to support data owners in making decisions and moving forward when the conversion team faces obstacles. Hence, you need to engage the stakeholders from the business community at certain critical points in the process to help alleviate the problems faced by the conversion team.
Be prudent in selecting the resources. Identify experienced users from the user community because they can bring their hands-on experience in solving actual data problems they face in their business process to the table. This experience is not only helpful as a design input but also valuable in data migrations as you have an opportunity to enrich the missing data by creating data elements not present in the legacy system as required by its business process. It’s always a good idea to pick the SME from the user community for a given functional area — for example, a lead buyer as a procurement SME, a lead commodity manager as a contract management SME, or a senior planner as a planning SME. Now I’ll look more specifically at the roles involved.
Roles
Normally, typical roles are defined for handling large migration projects. From a business perspective, these roles could include:
- Data manager
- Data business owners
- Data migration superusers
- Technical SMEs
- Business SMEs
From an IT perspective, these roles could include:
- Data IT lead
- Process track team member
- Data track team member
In our project, we did not define typical roles. We leveraged most of the existing roles along with the conversion team to address the data migration track resource requirements. This step saved a lot of cost, time, and effort because the individuals in the existing roles were already knowledgeable from a data and design perspective. The following roles were made responsible for data migrations:
- Members of each functional area (e.g., procurement, planning, finance)
- IT systems analyst lead
- Business lead
- SMEs
- Design systems analyst
- Conversion analyst for handling objects of a functional area
Figure 1 shows how we reduced the conventional data migration roles in our project into new roles. We wanted to address all roles that are needed for data migration while leveraging the existing roles and avoiding role redundancy. For example, SMEs with excellent overall knowledge played the roles of data migration superuser, functional SME, and business SME. This consolidation also helped on cost savings by cutting down some roles. Despite this, it did not result in over burdening the resources because of the duration of the project. The earlier you engage the business in the process, the more they can prepare for their responsibilities. Due to the critical nature of certain phases, additional business team members will be needed at times, but for the majority of the project the business lead ensures the optimal workload of business resources.

Figure 1
Convert conventional roles into collapsed roles
Table 1 shows an operating resource model that was defined for data migrations in our project. You can define additional roles based on the specific project requirements. You can see how the conversion objects are tied to these roles for a given functional area. All these roles for a given functional area have responsibility in delivering the object successfully.

Table 1
An example operating resource model
For each functional area in our project, there was a team comprising these roles. They all worked together until the cutover on several activities, such as:
- Finalizing conversion strategy
- Designing, developing, and testing conversion programs
- Coordinating master and transactional data settings
- Cleaning up data
- Driving the cutover weekend conversion and reconciliation activities.
Now I’ll describe the responsibilities they had during the project.
Responsibilities
Each of the stakeholders has a specified responsibility in the process. At the kick-off stage, the project manager clearly defines and explains these roles to the various stakeholders as part of the project meetings. This step ensures clarity of ownership for all. It is also important to communicate the migration track’s timelines well in advance so that the business team can plan its availability of resources required for various tasks (e.g., preload validation, post-load validation) supporting migrations.
Now I’ll examine the extensive responsibilities defined for roles from the business community specific to migration. Note that we leveraged most of the existing roles, and for these roles, the responsibilities are specific to data conversions.
Functional Area Business Owner
This role is a liaison between business and IT. For migrations, the functional area business owner is primarily responsible for:
- Coordinating data cleanup, data validation, and reconciliation work with conversion analysts and SMEs. This role could involve setting up periodic review meetings to check the status of data cleanup, identifying help needed for business personnel for all conversion activities and directing them to the right people for help.
- Driving cutover weekend reconciliation work for the respective functional area. This role could involve facilitating working sessions, if necessary, between the conversion team and business personnel to reconcile the converted data and taking bottom-line responsibility to ensure success for all business-supported activities during cutover weekend. This would help in a quick sign-off by the business allowing the go-live to conclude on time.
SME
A technical expert or a functional area data content expert fills this role. In our project, the SME was identified from the user community for a given functional area and for migrations primarily responsible for:
- Approving the conversion strategy for the objects in their functional areas
- Driving source system cleanup with users (e.g., cleaning up all unwanted contracts, scheduling agreements, purchase orders [POs], source lists, and quota records in the source system for the procurement area)
- Providing business rules to be applied to data extraction to avoid old, obsolete records. For example, this could mean extracting all open POs created in the last three months.
- Performing manual conversions (if any). Because of their good working knowledge, SMEs are the ideal people to involve in any low-volume manual conversions, such as closing engineering POs (low volume) in the source system and manually creating them in the target system.
- Reviewing conversion extracts and conversion reconciliation and providing approval that data content is as expected
Now I’ll look at the responsibilities defined for roles from the IT community specific to migration.
Functional Area Owner (IT Systems Analyst Lead)
This person is the team lead for all design system analysts for a given functional area and for migrations is responsible for:
- Setting up functional area conversion meetings with conversion support resources and driving conversion work to completion. For example, the procurement systems analyst lead should facilitate meetings between procurement conversion analysts and procurement system analysts.
- Ensuring master and transactional data settings (including configuration) from the functional area team are provided to conversion analysts. For example, while extending materials to plants, you might need to set up planning relevant configuration settings, such as material requirements planning (MRP) controllers, scheduled margin keys, or MRP types at the plant level where the materials are extended.
- Partnering with the business where needed to validate and reconcile master and transactional data. While performing reconciliations for a functional area, the systems analyst lead should facilitate the meetings involving conversion analysts, systems analysts, and business users or SMEs to help the business in defining the criteria for reconciliation and defining the actions that are required from the business for reconciliation.
Design System Analysts
Design systems analysts are primarily responsible for SAP solution definition and configuration. Responsibilities for migrations include:
- Defining transformation and business rules, fields, and value mappings
- Being accountable for validating conversion results during each cycle before they are passed on to the business for approval or sign-off
- Approving the conversion strategy defined by the conversion team
- Reviewing and approving detailed design functional specifications for conversion programs and supporting conversion program testing during all testing phases
- Coordinating with SMEs to define success parameters for pre-load data validation and post-load data reconciliation
- Completing successful reconciliation of data conversion
- Assisting in validating requested data settings in the system before conversion analysts run conversion programs
Conversion Analyst
The conversion analyst is responsible for:
- Finalizing the conversion strategy for an object by involving all stakeholders and owning, designing, developing, and executing conversion programs for a functional area until go-live
- Driving data cleanup for objects where relevant
- Seeking any kind of conversion-related clarifications by setting up ad hoc meetings with identified stakeholders and escalating any roadblocks to the conversion lead
- Providing deployment and stabilization support through minor conversions for supporting functional area designs after go-live. Remember, some migration issues can surface once users start using the migrated data after go-live.
Conversion Lead
The conversion lead is accountable for overall migration and data load success and is responsible for:
- Planning the conversion activities using a Gantt chart created with Microsoft Project Professional to illustrate the project schedule and track the conversion progress by publishing progress using scorecards
- Driving functional area owners (e.g., the IT systems analyst lead for each functional area) to complete conversion-relevant tasks and conversion analysts to complete conversion tasks
- Collaborating with the design team and business along with the functional area IT systems analyst lead to ensure conversions are always aligned with the final design
- Coordinating conversion intersects with affiliated teams and coordinating conversion meetings with project and site representatives
- Resolving roadblocks or escalating them to the program office
Functional Area Data Coordinator
This role is crucial in that it was identified during the course of the project after some tough experiences in the initial phases of the project. Examples of such experiences include a schedule delay in conversions causing a delay in functional testing, data integrity issues, and unwanted data relationships resulting from improper data identification and improper execution sequence of conversion activities.
The benefits of this role are twofold. One is in coordinating to identify the correct data for migrations. The other is in setting up required master data for various testing phases. Normally, large companies have multiple systems involved in their IT landscape. For example, they could have SAP Supply Chain Management (SAP Advanced Planning & Optimization, specifically) as a planning system and SAP ERP Central Component (SAP ECC) as the execution system. Identify a person who has good knowledge across multiple functional areas. For all practical purposes, a person from the planning functional area is the most suitable one for this role because of their good knowledge of the supply chain model to be set up in SAP SCM, various data touch points, and the core interface (CIF) model set up between SAP SCM and SAP ECC. By performing defect-free migrations in SAP ECC, you can ensure a high-quality data transfer to SAP SCM and consequently establish the correct supply chain relationship among various entities in SAP SCM. Also, the basic premise for data migrations is to identify active materials that had, have, or may have customer demand. All migrations across functional areas are performed only for data pertaining to these active materials.
At times, the active data identified by each individual functional area may not be complete when you look at a larger picture. For example, certain materials that do not have active demand still need to be considered for conversion because there could be some inventory on them. These materials qualify to be converted into the target system unless the inventory is depleted in the legacy system before migration.
The person in this role should contribute to:
- Driving to identify the active materials coordinating with the planner community across business units
- Coordinating with other functional areas to identify additional active materials based on open documents and inventory
- Coordinating with IT teams for each functional area to build the data spreadsheet for master data supporting the supply chain model for various conversion phases
- Coordinating in performing CIF activities to transfer migrated data from SAP ECC to SAP SCM in the proper sequence
- Support cutover weekend for any SAP ECC or SAP SCM CIF issues
Most of the migration activities have a joint responsibility between roles. Still, it is absolutely essential to attach these activities to primary and secondary roles. Some of the important data migration activities are summarized in Table 2 highlighting the primary and secondary roles within an IT team.

Table 2
The IT team’s primary and secondary roles
SME and Business Representatives' Involvement
The key questions that explain the involvement of the business representative are:
- Why the business reps’ involvement is critical for data migration
- Where you need their involvement
- What precisely their role is
- When they need to dedicate more time than usual
- How much time they need to spend to support the migration
Why the Business Reps’ Involvement Is Critical for Data Migration
Involving business users and data experts in the data migration project is the single biggest factor to driving success. Table 3 shows the top risks that could be mitigated with business involvement and their impact to migrations in the absence of business involvement.

Table 3
Top risks to be mitigated by SMEs’ and business reps’ involvement
Where You Need Their Involvement
Table 4 explains the various activities the SMEs and business reps can support by their involvement and the tasks that help support those activities.

Table 4
Activities that SMEs and business reps support
What Precisely Their Role Is
There are seven key aspects to the SME or business rep role:
- Understand the data coming from the legacy system
- Be able to validate extract file data (validate the content)
- Understand mapping logic for transforming legacy data into SAP data
- Understand defaults applied by business rules for SAP fields
- Participate in documenting migration process steps (focusing on legacy business processes)
- Log and help resolve identified issues. Resolution of issues is an excellent source of training.
- Add additional support to a project. In specific areas in which your SMEs lack a depth of knowledge for the validation effort, other SMEs from the business track can help.
When They Need to Dedicate More Time Than Usual
They need to spend more time on the project during two different phases: prior to deployment and during go-live.
Prior to deployment, there are two key phases to keep in mind:
- Initial stages when data mapping starts. In those stages, SMEs and business reps provide the following support:
- Helping the conversion analyst understand content of legacy data
- Helping the conversion analyst understand current processes
- Helping develop migration business processes by working with the conversion team
- Helping drive extraction, collection, transformation, development, and cleaning of source data for conversion. No one else has better knowledge of data than the business themselves.
- Participate in testing and solution testing on converted data (QA, UAT, and system integration)
- Validate data loaded in the SAP system: Check sample data records and run processes and reports. This step is to ensure the converted data is in line with the business requirements.
- Identify and help resolve issues. The closer SMEs and business reps work with the conversion team, the better the quality of converted data.
During the go-live, SMEs and business reps work on three key tasks:
- Ensure final preparation of the source file is accurate. This step is possible through excellent data clean-up activity and by applying proper criteria in identifying active data for conversions.
- Assist with validating final source data for approval to load. Provide a sign-off for data load.
- Assist with validating the data load in the production client. For example, work with buyers to reconcile their respective open procurement documents converted into the target system, obtain internal buy-in, and finally provide sign-off to the conversion team.
How Much Time They Need to Spend to Support the Migration
Table 5 highlights the various stages in which the business reps and SMEs need to be involved as well as the tasks they should be performing and the duration for those tasks.

Table 5
Stages in which business reps and SMEs should be involved
This operating resource model and the stated roles and responsibilities for any migration project help align the various stakeholders to their respective responsibilities in the whole migration process and achieve the correct results in a specified time frame. They set the right expectations for everyone involved in the process and help achieve excellent results while saving on effort and additional resource costs. The post-go-live data issues and stabilization support would also be minimal.
Ramachandra Chemudupati
Ramachandra Chemudupati is a lead consultant at Infosys Ltd. His areas of expertise are SAP materials management, sales and distribution, plant maintenance, and project management. He has more than 12 years of consulting experience and has worked on multiple implementation, rollout, transformation, and data migration projects for several global Fortune 500 companies.
You may contact the author at cramac2011@yahoo.com.
If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.