Data Migration and Data Integrity — The Hidden Risk in System Transitions

Every time a pharmaceutical company migrates data from a legacy GMP system to a new platform — LIMS, ELN, quality management system, stability software — it creates a data integrity risk window that most project teams are not equipped to close, and that FDA investigators are specifically trained to probe.

That sentence is not a hypothetical. It is a description of what happens inside regulated pharmaceutical operations every time a system transition is treated as an infrastructure project rather than a data integrity event. The migration itself — the act of moving records from one validated environment to another — is a GMP activity governed by 21 CFR Part 11, EU GMP Annex 11 Clause 17, and the FDA’s 2018 Data Integrity and Compliance with Drug CGMP guidance. It requires a level of validation rigor that is, in practice, rarely applied with the same discipline as the systems being replaced.

The reason this matters now, in 2026 and into the foreseeable future, is that pharmaceutical companies are migrating GMP data at an accelerating rate. Legacy LIMS platforms deployed in the 1990s and early 2000s are being replaced by cloud-based systems. Paper-based batch records are being converted to electronic formats. Stability software from one vendor is being replaced with enterprise quality management platforms from another. Every one of these transitions involves the movement of GMP records — and every one of them creates the same five categories of data integrity risk.

THE FIVE RISK CATEGORIES

The first category is metadata loss. In a GMP context, a record is not just the data value — it is the complete electronic record as defined in 21 CFR Part 11.10, which means the audit trail, the timestamp, the user ID, the sequence of changes, and the original entry. When a migration extracts records from a source system and loads them into a destination system, the transformation logic that governs that extraction and loading determines whether metadata survives intact. Migration teams focused on data values — the numerical result, the sample identifier, the batch number — will transfer the data while stripping the metadata. The destination record then shows a value without a provenance chain. An FDA investigator looking at that record during an inspection cannot determine who generated it, when it was generated, or whether it was modified after initial entry. That is a data integrity finding, regardless of whether the original system was fully compliant.

The second category is record completeness. Every GMP system contains records. A migration specification defines which records are in scope. The gap between those two populations — records that exist in the source and records that are captured in the migration scope — represents a completeness risk. This gap arises for multiple reasons: records created during system transitions, records stored in archived states that the migration logic does not reach, records associated with deprecated workflows, and records that fail transformation rules and are excluded without documentation. The critical point in the FDA’s 2018 data integrity guidance is that completeness is not a technical criterion — it is a GMP obligation. All GMP records must be retained and accessible. If a migration does not transfer them, and the source system is subsequently decommissioned, those records are effectively lost. Under 21 CFR 211.180, that is a violation.

The third category is data integrity in transit. Transformation rules — the logic that converts data from the source system’s structure and format to the destination system’s structure and format — introduce modification risk at scale. A date format conversion, a unit-of-measure normalization, a text encoding change, a numeric precision rounding — any of these can alter the stored value from what was originally entered. At the individual record level, the change may be imperceptible. At scale, across millions of records, transformation errors can introduce systematic deviations from original values. Without hash value verification at the field or record level, the destination system presents altered data as if it were original, and the audit trail in the source system is no longer accessible to verify the discrepancy.

The fourth category is audit trail continuity. MHRA’s 2018 GMP Data Integrity Guidance and EU GMP Annex 11 both require that the migration event itself be recorded. The destination system must contain a record that a migration occurred, when it occurred, who authorized it, what the scope was, and what the reconciliation outcome was. This is not a technicality. It is the mechanism by which an investigator can reconstruct the data lineage for any record in the destination system. If the audit trail in the destination does not capture the migration event, then records that arrived via migration are indistinguishable from records created natively in the destination system — and the provenance chain is broken.

The fifth category is retention compliance during the transition period. The FDA’s data integrity guidance is explicit that migrating data to a new system does not relieve the organization of its obligation to maintain access to the original records in the original system — or an equivalent validated archive — for the duration of the applicable retention period. Under 21 CFR 211.180(a), batch records must be retained for at least one year after the expiration date of the batch; the regulation’s alternative three-years-after-distribution period applies only to the narrow category of OTC drug products exempt from expiration dating under 21 CFR 211.137, not as a general “whichever is longer” standard applicable to every expiration-dated batch. Stability records, analytical method validation records, and other GMP data carry their own retention obligations. Decommissioning a source system before those periods have elapsed, without a validated archiving solution that preserves full electronic record integrity including metadata and audit trails, is a GMP violation regardless of whether the migration itself was otherwise well-executed.

WHY MIGRATION IS TREATED AS AN IT PROJECT

The organizational dynamic that produces these five risk categories is not negligence — it is structural. System transitions are managed by IT project teams. The project charter is framed around go-live date, budget, and functional equivalence. Quality is invited to review and approve, but the technical execution — the extraction logic, the transformation rules, the loading process — is developed by database administrators, system integrators, and software vendors who are not GMP practitioners. The migration specification is written in technical language, reviewed under time pressure, and approved by quality personnel who are not always positioned to evaluate transformation risk at the data field level.

The result is a migration that passes IT acceptance testing — data appears in the destination, the system goes live, users can access their records — but has not been validated as a GMP activity. The record count in the destination is close to the record count in the source, but has not been formally reconciled. Spot-checks were performed but not documented in a protocol-driven manner. Metadata completeness was assumed rather than verified. The source system is decommissioned on schedule, and the migration documentation — if it exists at all — is filed in the IT project folder rather than the quality management system.

This is the scenario that FDA investigators encounter. The 2018 FDA data integrity guidance specifically identifies data migration as a risk area. Investigators trained in data integrity review know to request migration documentation, compare record counts between source and destination, and ask whether metadata including audit trails was verified in the destination system after migration. Organizations that treated migration as an IT project discover the exposure not during the project, but during the next FDA inspection.

THE GMP REFRAMING

The correct framing, established in GAMP 5 (ISPE, 2nd Edition, 2022) and reinforced in WHO Technical Report Series 1033, Annex 4 (2021) — the Guideline on Data Integrity, which superseded the 2016 WHO TRS 996 Annex 5 guidance on good data and record management practices — is that data migration is a GMP data integrity activity. It requires a migration specification that defines scope, transformation rules, and validation approach — reviewed and approved by quality before execution. It requires a trial migration with a full reconciliation report comparing source and destination record counts. It requires a data integrity verification protocol that confirms metadata completeness, audit trail integrity, and hash value equivalence for a statistically justified sample. It requires performance qualification with documented acceptance criteria and a completed reconciliation demonstrating that all in-scope records transferred with full integrity. And it requires a post-migration legacy access maintenance plan that confirms the source system remains accessible — in a validated, readable state — until every applicable retention period has elapsed or a validated archiving solution is in place.

THE XGENE GMP DATA MIGRATION VALIDATION FRAMEWORK

Migration Specification Development Define scope: which systems, which record populations, which time ranges. Document all transformation rules — date formats, units of measure, text encoding, numeric precision. Define the validation approach, reconciliation methodology, and acceptance criteria. Quality review and approval before any execution.

GMP/Regulatory Review Before Execution Quality and regulatory review of the migration specification confirms that scope captures all GMP records subject to retention obligations, that transformation rules preserve metadata integrity, and that the validation approach satisfies 21 CFR Part 11, EU GMP Annex 11 Clause 17, and the applicable FDA data integrity guidance.

Trial Migration with Full Reconciliation Execute the migration against a representative data subset. Generate a reconciliation report comparing source and destination record counts at the record type level. Identify transformation failures, exclusions, and metadata gaps. Remediate transformation rules before performance qualification.

Data Integrity Verification Protocol Protocol-driven verification of: (1) metadata completeness — audit trail fields, timestamps, user IDs present in destination for all migrated records; (2) record count reconciliation — source vs. destination counts with documented explanation of any variance; (3) hash value comparison — field-level or record-level hash verification for a statistically justified random sample; (4) spot-check review — human review of randomly selected complete records comparing source printout or export to destination record.

Performance Qualification with Documented Acceptance Criteria Execute the full production migration against pre-defined acceptance criteria. Generate and approve the reconciliation report. Document all deviations, their investigation, and their disposition. Qualify the migration as complete only when all acceptance criteria are met.

Post-Migration Legacy Access Maintenance Plan Document the retention periods applicable to all migrated record populations. Establish and validate the mechanism for accessing source system records — whether the source system remains operational in read-only mode or a validated archive is deployed. Do not decommission the source system or archive until every applicable retention period has elapsed and decommissioning is documented as a quality decision, not an IT decision.

Decommissioning Decision Framework Decommissioning requires documented confirmation that: all retention periods have elapsed or a validated archive with full electronic record integrity is in place; the decommissioning decision has been reviewed and approved by quality; and the decommissioning event is recorded in the quality management system with supporting documentation.

If your organization has migrated GMP data from a legacy system in the past five years, locate the data migration validation report and verify: does it include a record count reconciliation, a metadata integrity verification, and a post-migration audit trail review — or was it treated as an IT migration with no GMP validation documentation?