Question 15 of 20 Intermediate Scenario
How would you handle migrating a study to a new EDC system mid-trial?
Short answer
Treat the migration as a validated process: plan it, assess risks, map every field and its metadata, rehearse with mock data, then verify key data after the move. The audit trail and history must stay traceable, and the old system's data kept readable for the retention period.
Why
EMA's computerised systems guideline says validating a data migration deserves no less focus than validating the system itself. It asks for a detailed plan, a risk analysis, a rehearsal with mock data, and verification focused on key data after migration, with every transformation traceable. Useful checks include record counts, checksums and quality control of a sample.
E6(R3) section 4.2.5 asks for validated or reconciled processes when data and metadata move between systems. The hardest part is metadata. Values move easily, but audit trails, query histories, signatures and timestamps often do not map cleanly.
If the new system cannot import the old audit trail, the old one must be preserved and linked, so an inspector can still see who changed what. Timing matters: migrating just before an interim analysis or database lock is risky. Sites need training and a clear cut-over date so no data are entered in both systems.
Data that fail mapping, such as free text longer than the new field allows, need a documented decision rather than silent truncation.
A strong answer covers
- Migration validated with the same rigor as a new system
- Field and metadata mapping
- Mock data rehearsal and post-migration verification
- Preserve and link audit trails
- Clear cut-over and site training
Common mistakes
- Moving current values only and losing the audit trail.
- Allowing sites to enter data in both systems during cut-over.
- Truncating fields that do not fit without documenting it.
The interviewer might ask next
What checks would convince you the migration did not change any primary endpoint data?