Data Migration Plan – People and Technology

While the first two components of the Data Migration Framework focus on the scope, segments and regulations of data, leverage the third component of the framework to liaise with stakeholders in identifying and mitigating risk related to resource availability in the project’s discovery phase. I recommend determining the right technology for data migration in the discovery phase so you can evaluate the availability of technical experts who could use the selected tools to execute data migration.

Choose the right people and technology for data migration

Decommissioning a legacy system is more of a people problem than a technology problem. When a business system runs over decades and manages core business transactions, various business units/departments in an enterprise could be highly dependent on the legacy system with multiple system matter experts (SMEs). Therefore, in this foundational component of the plan, assess the availability of people and technology support from the business-as-usual (BAU)/Operational teams for the migration project.

Business Experts

Collaboration and input from the business SMEs are essential for forming business rules, mapping rules, and data cleansing approaches to execute robust data migration and ensure smooth business continuity post-decommissioning. Business SMEs could be light on the technical side and may need to learn the nuances of managing the database or backup. However, they have answers for how a business system is used, what downstream dependencies pose a significant risk for business continuity post-decommissioning, any possibility of regulatory violations due to data migration activities, and much more about the business impact of the legacy system.

Technical Experts

If the target system is known for the decommissioning project, assess the level of support and resources available for data migration activities from the new system vendor. In some cases, the vendor can provide complete data migration activities as a managed service, given the raw source data is made available to them. In other instances, the vendor would provide a means to load data into the target system, which includes:

1. CSV or Excel files to load the final cleaned data to be migrated,
2. SQL database with pre-defined tables to be loaded with the data for migration
3. RESTful APIs to push data in target system as JSON objects.

Based on the available load method in the target system, choose potential tools for data migration where you need to execute data transformation of source data from the legacy system into the data structure required by the load method of the given target system. Even for the managed data migration services by the vendor, one would need support from in-house data custodians such as DBAs, IT engineers, and data governing teams to move raw source data securely and conform to data privacy regulations. One can also choose to onboard specialised data migration software such as hopp or consultants for managed services based on the severity of the risk stemming from unplanned data migration.

Technology or People Driven Migration

I am not surprised if you find this component the most challenging out of the ten components of the Data Migration Framework because it deals with the dilemma of the organisation’s culture and tech maturity – Older the legacy system, Darker the fun of decommissioning it. It would not harm to undertake a Data Management Maturity Assessment (DMMA) to assess maturity level of current data management practices. Outcome of the maturity assessment should identify critical improvement areas and make sound choices for the right balance between business and technical resources required for successful data migration.

While navigating the most cost-effective path that ensures smooth data migration on the decommissioning night, as a program or project manager for legacy decommissioning, you should also evaluate the need and extent of capturing metadata generated by the data migration, which mainly includes the choices and decisions made on and about legacy data (business rules, data cleansing rules). Immediate, smooth continuity of business operations is the primary measure of success or failure of data migration. However, decision support, A.K.A. operational or business intelligence operation, could refer to the metadata generated by data migration for the next few years post-decommissioning.

In a technology-driven approach, database developers (ETL developers) lead data migration and liaise with internal S.M.E.s and technical(I.T.) teams, vendor consultants and the project team. With this approach, remember the documentation, as you may risk losing knowledge about codified business rules for data migration (i.e., the metadata generated by data migration). On the other hand, In the People Driven Approach, data migration could be led by managed services from the vendor of target system or a third-party consultants such as hopp who would work closely with S.M.E.s and stakeholders for smooth data migration with coherent metadata capture and retention.

In Summary

The third component of the plan, which focuses on people and technology, is crucial for resource planning. Its depth of information will vary depending on the current state of the project, such as the selection of a target system and the level of vendor support. This component addresses the following questions of stakeholders:

• Which specific tools and personnel are essential for executing a successful data migration?
• Does the vendor provide managed services for data migration?
• Can we use our current Extract-Transform-Load (ETL) solution and resources for the data discovery and transformation processes, considering the potential cost and time savings?
• Shall we host the data migration solution on-prem or in the cloud?
• What are the licensing cost and consulting costs for data migration tools?
• Have we evaluated the availability and skillsets of SMEs and technical team members to support data migration?
• Which toolset should we choose for ETL, such as SSIS, Informatica, Python, etc?
• Should we onboard specialist consultants and end-to-end Data Migration software such as hopp to manage data migration professionally?
• What is the risk and possible impact due to limited in-house resource availability for data migration?
• When was the last time data management maturity assessment was done , and what was the outcome?
• As a part of project preparation, shall we undertake a professional data management maturity assessment?

Next:

Information gathered and risk addressed (mitigated) in the first three component of the plan sets the right foundation for successful data migration. Questions addressed and decisions made during the project discovery phase in the first three components will drive the remaining components of the Data Migration Framework with the project progression. In the next blog, I will cover the fourth component — Business Rules. Please reach out in comments if you have any question, feedback or suggestion. I am also preparing Excel and Word templates for my readers who want to kick-start drafting a data migration plan based on my questionnaire across ten key components.

I hope decision makers (tech or business) who are directly or indirectly associated with legacy system migrations will find my legacy data migration plan series helpful. I highly appreciate constructive comments/feedback and questions. Feel free to share your thoughts and reach out for early access to data migration plan templates.