Simply put, data migration is the process of transferring data between two or more storage types. The transfer can occur between different formats or different computer systems. This is a straightforward concept. But it can get complicated when the data involved has formatting requirements that may be different between the source and destination and if this data has regulatory compliance implications. In this blog, the assumption made is that the data has regulatory implications.
In today’s environment, migration can take different forms, migrating to or within the cloud, on-premise, or whether it is a database, application, or storage only migration. Whatever migration requirements you identify, a data migration plan is essential. It is rarely, if ever, a simple copy; there is almost always some data mapping and/or data transformation/conversion that must take place along with verification, all of which must be considered and detailed in a migration plan.
Consideration for a Data Migration Plan
The below image represents a simplified, visual way for you to think about your overall data migration plan.
Planning the Strategy
Things to include in any data migration plan typically take the form of requirements. Requirements will identify and detail the following;
- the sources of data that are in scope for the migration project,
- the specific mapping and/or data transformation requirements,
- how the migration of data will be verified,
- and a backup/backout plan in the case of any failures.
These activities should be outlined in a step-by-step manner.
Depending on the complexity, data migration can be included within an overall validation plan for a new system (database, storage) being implemented. It doesn’t necessarily need to stand alone. The migration can be performed as a final step in your performance qualification testing or user acceptance testing (UAT). When there are significant mapping or transformation requirements, then it is recommended that data migration be performed on its own, inclusive of the validation/verification testing that will necessarily be required.
In a cloud-based scenario, the work required doesn’t change significantly. What may be different is who performs the work (an external vendor) and how it is done. The plan outlining the details still needs to be created.
The following steps should be considered for any data migration that involves compliance data:
- Identify the data source(s).
- Review the source data for obsolete records, unused fields, etc. This will make the actual migration go smoothly.
- Perform whatever transformation/cleanse is deemed necessary.
- Schedule the migration. Often systems will be in use until the migration is completed to the new system or storage location. This must be a part of your plan to minimize down time for end users.
- Backup the source data prior to migration (as close to the date and time of the migration as possible).
- Move the data. Do not copy the data.
- Verify and validate the migrated data.
Once this is complete and testing has been performed satisfactorily, the legacy system can be shut down and retired.
Here are some final thoughts to keep in mind with any sort of data migration, whether it’s on-premise or in the cloud, and whether there are compliance implications or not. Keep your end users involved in the process. In most cases, they will be able to describe their data requirements, what to look for, and provide valuable insight. Also, keep your Quality team involved from the beginning of the project. Bringing them in at the eleventh-hour can lead to unnecessary delays, changes in requirements or scope, and overall resistance to the project.
USDM has conducted hundreds of data migration projects and is a trusted advisor for regulated data strategy and execution. USDM offers a range of solutions from oversight on project delivery to resourcing and managed services, and we build each team to meet the needs of each project. Whether you need a data analyst, a skilled team, or expert management to facilitate a data migration project on time and on budget, you can feel confident that we have the right delivery model for your unique needs. Please let us know how we can help, email@example.com.
Services: Data Integrity Services
Case Study: Improved UDI Data Integrity with Single Source of Truth
Case Study: Quality System Upgrade to Meet EU MDR and EU IVDR
About the Author
Joseph Cassella is the Director of Regulatory Compliance at USDM Life Sciences. With over 25 years of experience in the pharmaceutical, biotech, and medical device industries, Joe’s background is both broad and deep in Information Technology, Laboratory and Analytical Applications, and Quality Systems. He has led many projects inclusive of IT Infrastructure, Research & Development, QA/QC, Manufacturing, Compliance, and Sales and Marketing.
There are no comments for this post, be the first one to start the conversation!
Please Sign in or Create an account to join the conversation