The Migration That Broke the Audit Trail
A sponsor is migrating an ongoing study from EDC Vendor A to Vendor B because Vendor A is sunsetting its platform. The migration plan extracts 85,000 records and loads them into Vendor B. During user acceptance testing, the data manager notices that migrated records show 'system migration' as the creating user and the original entry timestamps are preserved only in a free-text comment field. The original audit trail from Vendor A is delivered as a flat PDF export. Vendor B's system has no field for 'original creator' or 'original timestamp.' The study has 9 months of enrollment remaining and one planned interim analysis in 3 months. The sponsor's validation SOP requires that migrated data be verified and that audit trails be preserved.
1. Is preserving the original audit trail as a PDF export acceptable? Justify your answer.
Read the worked answer
It is weak and likely non-compliant as the sole record, though it may be acceptable as a supplementary archive if the live system carries the essential metadata.
Reasoning:
- A PDF export is a static, non-queryable artifact. It cannot be searched, linked to individual records, or used to reconstruct a specific record's history in the live system. If a regulator asks 'show me every change to subject 014's hemoglobin,' a PDF dump is impractical to navigate and cannot be demonstrated as an integral part of the record.
- The essential requirement is that the electronic record remains attributable and reconstructable in the system of record. That means the migrated record should carry, at minimum, original creator identity and original entry/modification timestamps as structured, queryable metadata.
- The flat export may be retained as a supplementary archive with a documented description of its contents and how to use it, but it should not be the only evidence.
Acceptable outcome: Vendor B build adds structured fields for original creator and original timestamp (or a linked audit record), verified during migration testing.
2. What must the migration verification include before go-live, and how does the interim analysis affect timing?
Read the worked answer
Verification must include:
- Record count reconciliation: 85,000 extracted = 85,000 loaded, with exception report for rejects.
- Field-level comparison: sample (and risk-based full check for critical fields) comparing source vs. target values, including dates, units, and code lists.
- Metadata verification: confirm original creator and timestamps are preserved as structured data, not just text.
- Audit trail continuity: demonstrate that a record's history is reconstructable end-to-end across the cutover.
- Access control check: confirm role-based permissions carried over correctly and no orphaned accounts.
- Documented UAT sign-off against pre-defined acceptance criteria, with deviations logged and resolved.
Timing: the interim analysis in 3 months means the migration must be complete, verified, and the analysis dataset regenerated from Vendor B before the analysis is run - otherwise the analysis uses a dataset that no longer matches the system of record. The migration should not be rushed to hit the interim; if verification cannot be completed, the interim should be run from a frozen, verified extract with documented provenance, or deferred. The trap is letting the analysis deadline compress validation.