Data Migration

Get Started. It's Free
or sign up with your email address
Data Migration by Mind Map: Data Migration

1. People & Organization

1.1. Ressources

1.1.1. Identiy the Stakeholders

1.1.1.1. Key Data Stakeholders

1.1.1.2. Appoint a data migration specialist

1.1.2. Train / Ramp-up the "Juniors"

1.1.2.1. Resources need to be familiar with concepts of data management, migration, and governance apart from the technical/functional skill sets

1.1.3. Pitfalls

1.1.3.1. Turnover of team involve ramp-up and cost impacts

1.2. Gouvernance

1.2.1. clearly establish governance structure and policies defining “Who is accountable? To Whom? For what? How?”

1.2.2. Define a Communication plan

1.2.2.1. with periodic project meetings with key stakeholders

1.2.2.2. Use Dashboard and KPI to follows the progress status

1.2.3. Define a clear scope statement

1.2.3.1. with baseline/inputs statement

1.2.3.2. and an impact assessment,

1.2.4. Create a realistic budget

1.2.4.1. Estimating Effort

1.2.5. Create and share a planning

1.2.6. Implement a Risk management strategy

1.2.7. Ways of working

1.2.7.1. Collaboration

1.2.7.2. Prioritisation

1.2.7.3. Agile mode project

1.2.8. Pitfalls

1.2.8.1. Poor Communication

1.2.8.2. Scope and Priorities in constant move

1.2.8.3. Targets and Deadlines not reachable (workload and scope not re estimated when changes)

1.2.8.4. Budget and Planning not secured

2. Tools & Products

2.1. Tools / environments

2.1.1. 4 distincts plateforms ( 1 dev, 3delivery/test plateforms)

2.1.2. use a technical environment (with 3 silos) to transform data and check each steps

2.1.3. use Talend to transform data between legacy and SILO3

2.1.4. support MOA by providing tools and queries to check the datas

2.1.5. JIRA implementation to manage the changes and bugs / remain to do

2.2. Pitfalls

2.2.1. Migration in parrallel of Product development (Product not mature)

2.2.2. Hardware fiability

2.2.3. Tools not used in the right way (JIRA Agile version should be used)

3. Process & Method

3.1. Migration method

3.1.1. Phase : Understanding the Data

3.1.1.1. develop a thorough understanding of the source/legacy systems

3.1.1.2. Cleanse Data by MOA

3.1.1.2.1. Review content – ensure only valuable content is migrated

3.1.1.2.2. Manually doing this is possible, but many times is unrealistic / Automated approaches (linked to volumetry)

3.1.1.3. Pitfalls

3.1.1.3.1. A shared misunderstanding of the legacy system architecture, business rules and logic related to how the information is stored within the source/legacy systems results in migration projects being at risk

3.1.1.3.2. Inconsistent data in source/legacy system

3.1.2. Phase : Design

3.1.2.1. Review and redefine business rules

3.1.2.1.1. Identify gaps and dependencies in legacy data in collaboration with business

3.1.2.1.2. MOA need to make sure that data mapping rules from a legacy system to a new system has been reviewed and validated by Business

3.1.2.2. publish the transformations and rules to increase transparency and ease communication.

3.1.2.2.1. create a thorough specification of how the source and target objects will be mapped, down to the attribute level.

3.1.2.3. Have a clear vision of the origin and target environements to migrate data in a secure way.

3.1.2.4. Pitfalls

3.1.2.4.1. Needs and solution definition not mature (too may specification changes and CR)

3.1.2.4.2. Business Priority not aligned with Technical solution (planning)

3.1.3. Phase : Extract, Transform, Load

3.1.3.1. Transform data and check each steps

3.1.3.2. implement report to highlight problem of data consistency

3.1.3.3. check data transformed in Silo2 by MOA ( key milestone before test)

3.1.3.4. Pitfalls

3.1.3.4.1. Data quality issue detected only in acceptance phase because Silo2 milestone was not performed

3.1.4. Phase - Test

3.1.4.1. identify all data required for validation ( ex with UAT)

3.1.4.2. implement pre-acceptance with MOA to secure acceptance done with Business afterward

3.1.4.3. execute test described in JIRA

3.1.4.4. Pitfalls

3.1.4.4.1. without pre-acceptance phase : bugs are detected by key users during accetance phase and negative impact

3.1.5. Phase - Go Production

3.1.5.1. Team available to support post Go Prod period : 3 weeks (with dedicated support ticket)

3.2. Transversal processes

3.2.1. Change Management

3.2.1.1. For each new CR : impact analysis and feasability proposal

3.2.1.2. all the changes are validated in management meetings, and planned in a new sprint

3.2.1.3. Pitfalls

3.2.1.3.1. it's risky if changes are not managed with the planning and budget priorities

3.2.2. Quality Management

3.2.2.1. Adopt a thorough data quality management strategy

3.2.2.2. implement dedicated meetings with IT and Business stakeholders

3.2.2.3. Implement KPI to follow Quality results

3.2.2.4. Pitfalls

3.2.2.4.1. Data quality management implemented late due to strategy "priority quantity and not quality"