How do you validate a data migration from one GxP system to another?

A data migration moves records permanently from one system into another, for example when the old one is losing vendor support. EU GMP Annex 11 asks that validation “include checks that data are not altered in value and/or meaning during this migration process”.¹

1The steps, and the record each produces.

Owners are a suggested split, using Annex 11’s process owner and system owner.¹ Where a client owns the data, as at a CDMO, EMA’s clinical text is a useful analogy. On keeping data linked to its metadata, it says: “If several parties are involved, agreements should be in place to ensure this.”²

EMA’s clinical trial guideline also adds a rehearsal in which “the intended procedure should be validated with mock data”, and a check afterwards “focused on key data”.²

2Data migration validation checklist.

Hash a normalised form, applying the documented transformation to the source value first, so a new date format is not a false mismatch. Keep the scripts and outputs as evidence.

3Migration plan and report template.

3.1Plan.

1. Scope: source and target versions, the reason, what is excluded.
2. Roles: owners, QA, IT, any vendor, who approves each run.
3. Data inventory: each object, count, criticality, key data fields, retention period.
4. Risk assessment: failure modes per object and the check for each.
5. Mapping specification: controlled mapping, transformation rules, value lists.
6. Method and tools: scripts or the vendor’s utility, and how each is tested.
7. Verification: checklist rows that apply, sample sizes, acceptance criteria, no tolerance for key data.
8. Runs: mock data, dry runs, freeze, final run, delta, cutover, rollback criteria, a rehearsed restore.
9. Audit trails, signatures, metadata: which option from the decision table applies.
10. Source disposition: read-only period, archive format, decommissioning, approver.

3.2Report.

1. Conclusion: whether the data are complete, unaltered in value and meaning, and fit for use.
2. Execution: run dates, tool versions, freeze time, delta counts.
3. Reconciliation: one row per checklist item, counts on both sides.
4. Sampled review: size, how drawn, findings.
5. Deviations: each one, cause, fix, confirming rerun.
6. Data not migrated: what, why, where kept.
7. Source status and sign-off: read-only date, archive verification, decommissioning plan, approval by system owner, process owner and QA.

3.3Example mapping specification row.

3.4Example test cases.

Drawn from the worked example below.

4How many records to check by hand?

The automated comparison shows values arrived unchanged; the sampled review shows the target presents them with the same meaning. A random sample with zero errors lets you say, at a chosen confidence, that fewer than a proportion p of records are wrong, when its size is at least n = ln(1 − confidence) / ln(1 − p).

These hold for populations much larger than the sample; check a few hundred records in full. Add hard cases on top, such as invalidated out-of-specification results and retests; they find defects but do not count towards the claim. One error voids the claim: find the cause, fix the mapping, rerun and draw a new sample.

5Audit trails and metadata: migrate, keep or copy?

Metadata are part of the record. EMA: “Data, contextual information, and the audit trail should not be separated.”²

The static row is narrow. FDA says a printout of dynamic data “does not preserve the dynamic record format that is part of the complete original record” and “would not satisfy CGMP requirements to retain original records or true copies (§ 211.180(d))”.⁹ MHRA accepts a static record only with verified copies of “all raw data, metadata, relevant audit trail and result files”.⁶ For clinical audit trails FDA and EMA split. FDA’s 2024 Q&A recommends a searchable, sortable format and adds: “If this is not practical, audit trail files should be retained in a static format (e.g., PDFs) and clearly correspond to the respective data elements and/or records”.⁸ EMA, on decommissioning: “Static formats of dynamic data will not be considered adequate.”² A PDF trail is a fallback for FDA and not acceptable to EMA.

6Example: a LIMS-to-LIMS migration.

All names are invented. Vellacombe Biologics is replacing LIMS-A, whose vendor support ends on 31 December 2026, with LIMS-B in its quality control laboratory. Its key data are results, units, qualifiers, specification limits, the sample-to-batch link and each sample’s two signatures, review and approval.

A 2,000-record mock-data run, built to hit every mapping rule, found three mapping defects. Dry run 2, on a copy of production, found three more problems.

1. The tool rejected 11 results whose test codes were retired in LIMS-A in 2019 and had no mapping. The fix mapped retired codes to inactive methods.
2. The hash comparison flagged 1,876 results with a qualifier, such as <0.05, which had loaded as the number 0.05. The fix added a qualifier field to the mapping.
3. The sampled review found approvals made during British Summer Time shown an hour late: LIMS-A stored local time without an offset and LIMS-B read it as UTC. The hashes matched, because the stored value had not changed, only its meaning. The fix recorded the time zone; the review added 40 records either side of each clock change.

The final run followed a freeze at 18:00 on Friday 16 October 2026. The delta since the dry-run copy was 32 samples and 378 results.

A random sample of 299 results across the laboratory’s 14 products, plus 25 hard cases, found no errors. That supports a claim, at 95% confidence, that fewer than 1% of results are presented wrongly for the attributes reviewed. LIMS-A stays read-only in a virtual machine, open only to named reviewers, until an archive restore has been tested; then it is decommissioned.

7What an investigator asks for after a migration.

None of the regulators cited here publishes a step-by-step migration checklist. PIC/S’s guidance, written partly for inspectorates, says what to check: “appropriate verification of the complete migration of data”.⁷ From those and Annex 11, expect to be asked for:

8How US and GLP rules apply.

Neither Part 11 nor Part 211 uses the word migration, but their record rules apply, and FDA’s 2024 clinical Q&A names “Data migration, data retention, data backup, data recovery, and contingency plans” among procedures to document, where risk warrants, and keep “available for inspection by FDA”.⁸ 21 CFR 211.68(b): “Input to and output from the computer or related system of formulas or other records or data shall be checked for accuracy.”³ Part 11 protects records “throughout the records retention period” (11.10(c)).⁴ For GLP laboratories, OECD’s Advisory Document No. 17 says: “Conversion of data to a different format should be considered as data migration (e.g. from a proprietary data format to PDF).”¹⁰ ISPE’s GAMP 5 second edition, industry guidance and not a rule, has Appendix D7 on data migration.¹¹

9What inspectors cite.

The closest FDA warning letter we could find concerns what a static copy cannot replace once the original dynamic data are lost. To BBC Group Limited in 2021, under 211.68(b):¹²

According to firm management, the data is unrecoverable. While your firm retained a static copy of laboratory records for review (i.e., paper record), they were inadequate as they did not preserve the dynamic record format of the full chromatographs to support test results and they did not include system suitability documentation that are part of the complete, original record.

10Retiring the old system.

Retire the source only when every record it holds is migrated and verified, or archived in a form that stays readable for its retention period. MHRA: records of an unsupported system “should be archived according to a documented archiving strategy prior to decommissioning the computerised system”. PIC/S says that where conversion is not possible, “the old software should be maintained”.⁶⁷

Record the archive location, its checksums, how to restore it and who may approve destruction. Annex 11 clause 17 asks that archived data “should be checked for accessibility, readability and integrity”.¹

11What changed in 2024 to 2026.

The European Commission’s draft Annex 11, prepared with PIC/S and open for comment from 7 July to 7 October 2025, adds three relevant clauses.¹³¹⁴ Clause 10.3 says a migration “should be based on a validated process”. Clause 17.2 asks for integrity verified “by a high degree of certainty before any data is deleted, e.g. by means of a checksum”. Clause 15.11 says migration of data “should be planned and completed in due time prior to the expiry of the vendor’s support”. Until a final text is published, the 2011 annex, still listed in EudraLex Volume 4, applies.¹⁵

12How it runs in Seal.

A matched record count does not show that history and relationships survived. Neil can reconcile a controlled-document migration: it matches source documents, revisions, approvals and references against the migration inventory and drafts a gap list, such as prior revisions with no mapping. The migration and quality owners verify fidelity and decide whether to accept the target.

For laboratory data, Seal’s scientific data management keeps each instrument acquisition linked to its result, batch and investigation, puts format, parser and mapping changes under change control with their own verification, and expects restore and readability of archived files to be tested rather than assumed from storage. Each release of the new system is checked against the configuration actually deployed, as described in computer system validation with CSA.