Mitigating Risk in a Data Migration Project

The Risk Mitigation Plan

The Risk Mitigation Plan is a framework for reducing the impact of potential project risk. Risk, like the project’s schedule, budget and available resources, is a project constraint and must be proactively managed throughout the course of the project. Risks detected and addressed in the planning and design phase of a project are significantly less costly than those discovered during the implementation phase.

Though data migration projects might have risks similar to previous migration projects, it is important to keep in mind that each data migration project is unique. Thus, each migration project will have its own set of unique risks and risk mitigation strategies. This post will highlight some of the more common risk mitigation strategies in a data migration project.

Common Risk Mitigation Strategies

  • Clearly define the criteria for project success. Are key stakeholders, for example, willing to accept a margin of error in the migrated data? Quality cannot be managed unless the parameters are clearly identified.
  • Identify risks and challenges early in the project. Proactively manage risk and opportunity.
  • Develop and use a project Communications Management Plan. This plan should include reporting specifications, which ensures that key stakeholders and the project team are aware of the project status. Any issues with the data can be immediately identified and possible impacts to project schedule or budget can be quickly addressed. The communication plan should also include an issue escalation plan, which would assist in the management of project issues discovered during the migration process.
  • Ensure that data privacy and security requirements are maintained throughout the course of the project. If the data is subject to restrictions, these must be fully documented. Any resources dealing with the data must be fully vetted.
  • Thoroughly document both the existing data structure and the data structure of the new platform. Even in areas such as basic customer contact information, database schema and field types can vary greatly. In documenting both platforms, the project team will have an understanding of how data needs to be cleaned, consolidated or otherwise manipulated. This information is also a key input into the software selection process, if the migration team is considering using a commercial data migration tool.
  • If the project team intends on using a commercial data migration software tool, ensue that the product is properly vetted and can fulfill the project’s requirements.
  • Allocate project resources that will be responsible for the data migration after the data structures have been documented. This will align the proper resources with the complexity of the task.
  • When possible, use resources which are already familiar with the data and existing data structures.
  • Migrate only the data which is required to run the application. When migrating data into a new billing platform, for example, consider minimizing the amount of historic data migrated. If the legacy system remains operational (and there are minimal costs of maintenance and support), it may be possible to store historic data in the old platform.
  • Develop and employ a comprehensive Quality Management Plan. A data migration Quality Management plan must include a data validation and test plan. Key stakeholders should define the quantity of data to be tested.
  • Ensure that data changes made to the production platform are accurately captured and input into the new platform. This is especially important in a billing system data migration project, where customer package and service levels, as well as payment information, are updated frequently.
  • Plan on multiple iterations of the data import process and thorough testing of each iteration. The process of migrating data is usually time consuming. This is not part of the project that should be rushed.
  • Maintain the legacy system for as long as is possible (keep maintenance, infrastructure and costs in mind). Do not cut decommission the legacy system without sign off from the project sponsor.

Please comment if you have additional information or suggestions.

You may also like...