Late November we’ve hosted a joint webinar with Deloitte on how you can and why you should consider digitalizing Quality Management System.

Recently, we discussed questions that might arise when changing your eClinical software provider. Today, we want to take a closer look at one of the most asked questions:
How can I migrate data from a legacy CTMS or eTMF?
Data migration is a delicate process with many moving parts. Without a well-established process, the CTMS go-live could be postponed, with your new provider wasting resources on getting your historical data into their database in the meantime.
Let’s talk about how Flex Databases manages the data migration process and share best practices based on our experience. Below is the typical data migration flow implemented at Flex Databases:
Let’s look at each step in more detail:
Historical data is carefully scoped and scrutinized on its structure, links, and accuracy. We always involve all stakeholders and ask them to verify their own data before the audit.
Before the audit begins, the following questions must be answered:
Once we determine the scope of work and initial data structure, we identify the following field-level obstacles:
Sometimes, a lack of data governance rules in the legacy system results in frustration during the data migration. Here is an example from our practice:
There are cases where a single data point would be the same across databases, but each entry would be inconsistent in terms of spelling. For example, in three databases a data point was marked as “screen-failed”, “screen failed”, and “screening failure”. Thanks to our analytical tools, we managed to triage and consolidate all siloed values, creating well-organized data.
Identifying missing links in a legacy system at the early stage is a difficult task, but not impossible. With the help of automated data, the target system does not inherit weaknesses from the source system.
Using the results of data audit and preparation, and taking into account business expectations, we define a strategy for data migration and acceptance criteria. We offer two options:
One-time transfer | Iterative transfer |
The full data transfer is completed within the pre-agreed time frame while systems are in downtime. | Continuous migration while both the source and target systems are running. |
After the migration plan and strategy are set, we identify and allocate the tools and resources needed to implement each step. Core tools that we utilise belong to the following classes:
The choice of tool depends on the complexity of the migration project and processes involved. Although the old and new systems belong to the same family (CTMS), the same feature/object can vary across different CTMS.
This concerns not only the data transfer but the data transformation and remodeling process. As such, the migration tool should also support these additional activities.
As a rule of thumb, each phase of the migration plan should be covered by tests, both automated and manual. Test scripting usually involves the following aspects:
Once the internal validation and testing is completed and all discrepancies resolved, we execute the live data transfer.
We ensure that all stakeholders are informed in advanced so that can plan their schedules and activities accordingly.
We continue to test even after the data transfer is done. The final data audit aims to ensure the completeness and accuracy of the migration and, eventually, showcase the success of the overall project.
Our approach is usually to build a final reconciliation report showing the total number of objects transferred; actual number of records transferred versus those initially targeted; and discovered inconsistencies and how they have been processed.
Tell us more about yourself and we will organize a tailored live demo to show how you can power up your clinical trials processes with Flex Databases.