GxP Data Migration Validation: Cutover Evidence Pack

GxP data migration validation is documented evidence that a defined migration preserves the records required for regulated work, including their context and meaning. A successful import is insufficient. The European Union's Good Manufacturing Practice (GMP) Annex 11 calls for checks that migration does not alter data value or meaning; the United Kingdom's Medicines and Healthcare products Regulatory Agency (MHRA) similarly expects justified, robustly designed, validated procedures. (^[1]) (^[2])

The recommended cutover evidence pack connects an approved inventory and transformation specification to reconciliation results, record review, exception decisions, rollback evidence, and source disposition. Acceptance criteria belong in the approved protocol before execution, consistent with Annex 15's protocol expectations. (^[3]) Full automated checks should cover the defined population wherever technically feasible; risk-based review then evaluates interpretation, rendering, and workflow context. This division is an implementation recommendation, not a prescribed universal test percentage. Health Canada expects the extent of validation documentation and criteria to be justified through risk assessment. (^[4])

Sampling cannot establish zero-error assurance. In the hypothetical calculation developed below, no failures among 300 independent random observations yields an approximately 0.994% one-sided upper failure-proportion bound at 95% confidence. The inputs are illustrative, and the calculation depends on binomial assumptions; it does not apply directly to purposive high-risk selection or correlated transformation defects. (^[5]) (^[6]) (^[7]) Audit history and signatures also require substantive checks: applicable electronic signatures must remain linked to their records, and clinical-trial migration guidance says data, context, and audit trails should remain together. (^[8]) (^[9])

This report's regulatory check is dated 21 October 2026. It uses the Commission-listed Annex 11 text operational from 30 June 2011, while treating the separate consultation revision as a draft. (^[10]) (^[11]) (^[12]) The final decisions are distinct: authorize target operation, retain or retire source infrastructure, and authorize eventual record destruction. Backups do not substitute for an archive; retained records must remain retrievable and readable. (^[13]) (^[14]) A defensible release therefore records unresolved limitations, their effect on intended use, accountable approval, and continuing access arrangements, rather than claiming that a matching count proves preservation.

Migration changes the environment in which regulated records are stored, interpreted, or used. For life-science information technology (IT) leads, data owners, quality teams, and decommissioning owners, the central question is whether evidence supports continued reliance on those records. MHRA distinguishes transfer between storage types, formats, or systems from migration between durable storage locations, potentially involving format change without changing content or meaning. (^[15])

The term GxP groups applicable good-practice regimes; it does not identify a single retention schedule or validation obligation. Good Laboratory Practice (GLP), GMP, and Good Clinical Practice (GCP) require an explicit scope decision. The United States (US) Food and Drug Administration (FDA) Part 11 guidance links electronic-record applicability to underlying predicate rules, meaning the regulations that require the records in the first place. (^[16]) For United Kingdom (UK) GLP, MHRA states that the Organisation for Economic Co-operation and Development (OECD) data-integrity advisory document takes precedence over its own guidance. (^[17])

This report uses an adjacent advisory perspective for IntuitionLabs' audience: evaluate the evidence supporting implementation and source disposition. It ranks no products and assumes no particular platform. Its matrices, formulas, ownership assignments, and release recommendations are editorial implementation choices, not regulator-issued templates. The International Council for Harmonisation (ICH) supports risk-proportionate effort and documentation, while preserving the obligation to meet applicable requirements. (^[18]) (^[19])

The practical boundary is the complete record, rather than a database row or exported document alone. FDA describes metadata as information needed to understand data. (^[20]) Australia's Therapeutic Goods Administration (TGA) likewise includes relevant metadata in a complete electronic record. (^[21]) The following framework turns those principles into reviewable decisions, without promising regulatory acceptance or assuming that software retirement permits destruction of its records.

Transfer, migration, and preservation of meaning

Transfer may preserve the same representation while moving data; migration may introduce a different representation and interpretation environment. The distinction changes testing. An unchanged attachment can be checked byte for byte; a converted result needs checks of mapping, precision, units, and interpretation. MHRA's migration definition expressly allows format change while preserving content and meaning. (^[15]) Health Canada independently states the value-and-meaning expectation. (^[22])

For this framework, the proposed acceptance argument has three layers: population completeness, attribute and relationship integrity, and fitness for intended use. These are analytical categories rather than regulatory terminology. Each connects source expectations to observable target or archive behavior. The World Health Organization (WHO) data-integrity guideline supports a rationale and validated transfer or migration procedure. (^[23])

Meaning requires more than identical visible characters. As an implementation example, a result may depend on its units, applicable specification, method version, and status. A timestamp may depend on its timezone reference; FDA specifically discusses establishing that reference clearly. (^[24]) These dependencies should become explicit requirements rather than assumptions left to a record reviewer.

Establish the applicable baseline

At the publication check, the Commission catalog identified the established Annex 11 revision. (^[10]) The separately published revision remains consultation material; its proposed explicit treatment of ad hoc migrations is useful horizon scanning, not an additional operative requirement asserted here. (^[25])

For US records, document the Part 11 scope decision and applicable predicate requirements before choosing the export and archive model. FDA's guidance retains predicate-rule retention and availability obligations. (^[26]) Clinical work also has specific guidance: FDA's final electronic-systems guidance issued in October 2024 addresses clinical investigations, while the European Medicines Agency (EMA) clinical guideline addresses migration and decommissioning directly. (^[27]) (^[28])

The protocol should distinguish the authority of each statement: applicable requirement, regulatory guidance, voluntary technical guidance, or project acceptance criterion. Public International Society for Pharmaceutical Engineering (ISPE) material describes lifecycle guidance for complete, consistent, accurate, available records; it is a voluntary reference rather than a substitute for applicable rules or access to the full underlying guide. (^[29])

Define the population before extracting it

Start with a signed scope manifest covering source environments, record classes, retention status, date boundaries, business owners, and destination. Include records retained only in an archive and exclusions with rationale. This operationalizes the OECD expectation that sender and receiver define the migration protocol before execution. (^[30])

An expected target population should be derived from the frozen source and approved transformation rules. It need not equal the raw source row count: approved consolidation, record splitting, or exclusions may change cardinality. The specification must explain each difference. Annex 11's lifecycle traceability principle supports linking these expectations to tests. (^[31])

Table 1 proposes a record-class evidence matrix. Risk labels below are illustrative and require project assessment; none is a universal classification. Complete-record and metadata principles inform its scope. (^[32]) (^[21])

Record class	Risk and transformation	Reconciliation	Test	Evidence	Accountable owner
Results and observations	Decision-critical; units or precision mapping	Keys, expected values, population and status	Boundary values and reconstructed interpretation	Rule version, comparison output, review record	Data owner
Master data and code lists	Context-critical; code translation	Mapping coverage and referential integrity	Obsolete codes and effective dates	Approved dictionary and mapping exceptions	Process owner
Attachments and raw objects	Context-dependent; unchanged or converted	Manifest, byte size, hashes where unchanged, record links	Open, render, navigate, interpret	Object manifest and retrieval evidence	Record custodian
Audit histories	History-critical; event-schema translation	Event attributes and links to retained record versions	Actor, sequence, time, reason and prior value	Event reconciliation and review evidence	System owner with quality
Electronic signatures	Approval-critical; identity/status mapping	Required signature attributes and linkage	Display meaning and identify signed version	Signature inventory and linkage results	Business process owner
Configuration and methods	Interpretation-critical; version mapping	Required versions and dependency coverage	Reconstruct a selected historical decision	Configuration baseline and dependency tests	Application owner

The matrix separates a successful load from a successful record reconstruction. For example, an attachment may exist but point to the wrong parent; a signature may display but identify the wrong version. FDA requires applicable signatures to remain linked, and Health Canada's guidance likewise expects a permanent relationship. (^[8]) (^[33])

The following profiling checklist is a proposed implementation baseline, not a prescribed regulatory list. FDA's contextual-metadata principle explains why profiling should extend beyond business values. (^[20])

• Keys: quantify missing identifiers, duplicate identifiers, and conflicting natural keys before assigning new keys.
• Fields: distinguish null, blank, default, unknown, and not-applicable values in the comparison specification.
• Relationships: identify orphan links, attachment parents, version chains, and dependencies on external repositories.
• Representations: inventory encodings, precision, timezone conventions, units, and historic code values.
• Histories: profile audit and signature exports against the actual retained source population.
• Baseline defects: separate existing source defects from defects introduced by transformation or loading.

The GxP data migration validation protocol should then identify scope, intended use, risk assessment, mapping version, test datasets, automated checks, review rationale, acceptance criteria, deviation handling, and approvals. Health Canada links protocols and their justification to risk. (^[4]) Record each transform's input, output, exclusion logic, dependencies, and expected cardinality. Obtain vendor documentation or contractual clarification of export semantics, especially omitted metadata, attachment payloads, and historical versions; FDA recommends written agreements addressing service-provider requirements. (^[34])

Proposed acceptance criteria, to tailor and approve before execution, can be stated as reviewable conditions rather than an unexplained overall pass percentage:

• Completeness: every expected key is accounted for in the target or its approved retained destination, with exclusions individually traceable.
• Transformation: values and relationships conform to the approved rules, including documented handling of source defects and cleansing.
• Record usability: required context, attachments, history, and signatures can be retrieved and interpreted for the defined intended use.
• Exceptions: discrepancies have documented impact, disposition, and retest evidence; material unresolved gaps prevent the affected release.
• Recovery: the tested recovery path meets the project's approved operating and data-recovery needs.

These are example project criteria, not universal regulatory thresholds. Risk acceptance cannot waive an applicable requirement. (^[19])

Use full checks where the population is machine-comparable

Full automated reconciliation should mean checking every object in a specified eligible population against a defined expectation. It does not mean that every possible property was checked. Enumerate eligible keys and run full count, key, field, relationship, and object checks where feasible, then document uncovered properties. This is an implementation of the preserved-value-and-meaning objective, rather than a regulator's universal percentage rule. (^[22])

Do not accept count equality alone. A missing record and an extra record can cancel. Use source-to-target and target-to-source key comparisons, approved exclusion manifests, grouped totals, and transformation-aware expected values. Reconcile by meaningful partitions so a problem cannot disappear inside a global aggregate. ISPE describes complete, consistent, accurate, available records as a lifecycle objective. (^[29])

For unchanged objects, use an approved cryptographic hash and retain comparison scope. The US National Institute of Standards and Technology (NIST) describes message digests as detecting changes since digest generation; that supports byte-integrity checking, not proof of correct clinical or scientific interpretation. (^[35]) Intentionally transformed files need different evidence and a new post-transformation fixity baseline, consistent with Digital Preservation Coalition guidance. (^[36])

Add review for meaning and behavior

FDA distinguishes static records from dynamic records permitting interaction; a document rendering may therefore leave intended use untested. (^[37]) This proposed review plan concentrates on interpretation and failure modes:

• Critical decisions: reconstruct selected approvals, calculations, or conclusions using the migrated record and its dependencies.
• Transformation boundaries: cover extreme values, historical methods, obsolete codes, and precision changes.
• Record variation: include attachments, multilingual content where present, superseded versions, and status transitions.
• Audit reconstruction: verify event order, original identity, time reference, prior values, and reason fields where applicable.
• Signature reconstruction: verify signer, execution time, signature meaning, and the exact signed record version.
• Selection rationale: retain the sampling frame, strata, selection method, planned size, exclusions, and expansion rules.

The signature attributes arise from Part 11's applicable manifestation requirements; review must also retain linkage. (^[38]) (^[8]) Audit-trail review should preserve prior information, consistent with the applicable Part 11 control, and retained history, consistent with WHO guidance. (^[39]) (^[40])

Sampling cannot replace feasible full checks of enumerated keys, required relationships, or unchanged-object integrity. This is the report's risk-control recommendation. A purposive sample reveals selected risks; it cannot support a statistical population confidence claim. NIST's binomial definition requires independent experiments and fixed event probability. (^[41]) (^[7])

Make dry runs reproducible

Use a controlled rehearsal dataset, execute the runbook, and retest corrections. EMA recommends detailed advance planning and post-migration verification focused on key data. (^[28]) (^[42]) Preserve extraction boundaries, software and mapping versions, logs, reconciliation outputs, and elapsed-time observations. Deliberately exercise rejected records and interrupted execution so that restart behavior is visible. Approve consequential protocol changes as deviations with justification, rather than rewriting criteria after observing results. (^[43])

Also challenge the reconciliation logic with deliberately missing, duplicated, and altered test records. This recommended check tests whether the comparison itself can detect the errors it reports on. Preserve stable source-to-target identifiers, and demonstrate that rerunning a batch does not create unintended additional records. The final report should index the approved protocol, executed test evidence, actual coverage, deviations, residual limitations, cutover decision, recovery evidence, and source-disposition decision. Its conclusion should state which intended uses the evidence supports.

Freeze and delta are evidence boundaries

Recommended cutover checklist: FDA's clinical guidance includes migration, backup, recovery, and contingency documentation among risk-dependent system documentation topics. (^[44]) The checklist makes these controls operational:

• Authorize: identify the release decision owner, quality approval route, and explicit stop conditions.
• Freeze: record write restrictions, source extraction time, in-flight transactions, interfaces, and scheduled jobs.
• Capture delta: identify changes since the rehearsal or initial extraction using a defined, testable boundary.
• Reconcile: rerun approved checks on the final population and delta, including deletes and status changes where relevant.
• Resolve exceptions: close defects or approve specific residual limitations with impact and compensating controls.
• Verify operation: demonstrate access, authorized writes, retrieval, workflow continuity, and required exports.
• Test rollback: retain evidence of restoration, data recovery, dependency recovery, and interface coordination.
• Release: record signatures, exact released configuration, retained-source state, and post-migration monitoring ownership.

Choose continuity and restoration arrangements by risk. Health Canada's guidance expects restoration capability to be checked and continuity arrangements to be documented and tested. (^[45]) (^[46])

Define delta semantics before choosing the extraction tool. A timestamp boundary may miss records when source clocks, precision, or update behavior differ. The proposed specification should explicitly address insertions, updates, deletions, retries, and late-arriving attachments, with available event or snapshot identifiers. Maintain the timezone convention used in both evidence and comparisons; FDA emphasizes a clear time-zone reference. (^[24])

Table 2 separates release decisions from infrastructure and record disposition. Its proposed criteria operationalize distinct continuity and archiving expectations. (^[46]) (^[47])

Decision	Evidence required by this framework	Unresolved condition	Decision owner
Open target for regulated use	Approved final reconciliation, intended-use tests, exception decisions, trained support	Material record loss or untested interpretation	Business owner and quality
Invoke rollback	Trigger reached, tested restoration path, accepted recovery boundary	New target writes cannot be recovered or reconciled	Cutover authority
Close rollback window	Stable operation, reconciled target transactions, approved recovery handover	Open dependency or recovery uncertainty	Operations and process owners
Retire source infrastructure	Verified archive or retained environment, dependencies, access and retrieval evidence	Required history or functionality remains source-only	System owner and record custodian
Authorize eventual destruction	Applicable retention completed, disposition authorization, holds checked, destruction evidence plan	Retention or access obligation remains unresolved	Regulatory/quality owner and custodian

The table's significance is that target release does not authorize source destruction. Clinical-record guidance expressly prohibits destruction before retention ends. (^[48]) An approved read-only source may remain necessary while archive evidence is completed; its ownership, access control, maintenance, and eventual exit criteria should remain explicit.

Test the rollback decision, not only the backup

A rollback rehearsal should demonstrate recovery and subsequent business operation. Define the reversal boundary, who can invoke it, which systems must reverse together, and how target-created transactions survive or are reconciled. Retain measured restoration evidence against project-approved recovery criteria. The guidance supplies no universal migration rollback duration. (^[45]) (^[46])

On rollback, preserve and reconcile target-created transactions. Use an approved recovery procedure, preserve their history, and reopen affected reconciliation checks. The backup mechanism, migration archive, and operational recovery process serve different purposes; OECD expressly distinguishes recovery backups from archival preservation. (^[13])

Prove that a person can reconstruct the record

A retrieval demonstration should start from a business identifier and end with an understandable record, its dependencies, and an export where required. Applicable Part 11 controls address accurate, complete copies in human-readable and electronic form. (^[49]) FDA's scope guidance also discusses preserving content and meaning in copies. (^[50]) The proposed test therefore assesses what an authorized user can retrieve and interpret, rather than merely demonstrating that a storage service responds.

Audit trail verification should establish continuity between historical events and the retained business record. Retain original actors, event times, event types, prior values where relevant, reasons, and version references as defined by scope. A migration-generated import event should not be presented as the original approval event. EMA says data, context, and audit trails should not be separated. (^[9]) FDA similarly calls for secure, traceable links between data and metadata. (^[51])

For dynamic records, test required interaction or restoration of functionality. EMA states that static formats of dynamic data are inadequate in its clinical decommissioning guidance; TGA also says dynamically captured information should remain available in that state. (^[52]) (^[53]) A readable image alone may therefore leave a preservation gap when analysis or navigation is necessary to understand the record.

Choose and verify the source disposition

The proposed disposition record should distinguish continued live operation, controlled read-only retention, validated archival migration, and infrastructure retirement with retained records. OECD expects a documented archiving strategy before decommissioning a system that cannot be maintained. (^[47]) Use this implementation checklist:

• Retention: map each record class to the applicable rule, trigger date, owner, and approved disposition date.
• Dependencies: retain schemas, dictionaries, code lists, renderers, and access arrangements needed for interpretation.
• Retrieval: demonstrate authorized retrieval of records, history, signatures, attachments, and required contextual material.
• Preservation: record fixity values, storage arrangements, verification schedule, and migration history.
• Destruction approval: require separate regulatory/quality authorization and retained disposition evidence when eligible.

Do not assign a single retention term to all GxP data. For example, current MHRA clinical guidance distinguishes applications submitted before and on or after 28 April 2026. (^[54]) Applicable rules, record classes, study circumstances, and retained obligations need their own assessment before destruction. (^[26]) (^[48])

Archival engineering sources add useful, explicitly non-GxP-specific practices. The US National Archives and Records Administration (NARA) retains ingest manifests and fixity values; its transfer guidance includes dictionaries and schemas. (^[55]) (^[56]) The Library of Congress identifies software and hardware dependencies as sustainability factors. (^[57]) Incorporate these controls where appropriate, but do not present federal archival practice as pharmaceutical law.

Reconciliation formulas with explicit denominators

The formulas in Table 3 are proposed operational definitions, not published regulatory thresholds. Define the eligible source snapshot and expected transformed population first. Hash checks address byte changes, while migration validation addresses preserved value and meaning; those measures answer different questions. (^[35]) (^[1])

Measure	Proposed calculation	Interpretation and required evidence
Record-count delta	Target count minus expected transformed count	Report by record class; retain key anti-joins and approved exclusions, since net equality can hide differences.
Field population delta	Target populated applicable fields minus expected populated applicable fields	Define applicable, populated, blank, and default before counting; add value comparisons.
Key uniqueness	Distinct eligible keys divided by eligible records	Also report null keys and duplicate groups; define composite-key scope.
Hash-match coverage	Verified matching unchanged objects divided by expected unchanged objects	Missing and untested objects remain in the denominator; retain algorithm and byte representation.
Orphan rate	Unresolved required references divided by eligible required references	Exclude optional absent references only under the approved schema.
Duplicate rate	Excess records in duplicate-key groups divided by eligible records	Excess means group size minus one; retain group identities and the key definition.
Attachment/link coverage	Verified retrievable, correctly linked attachments divided by expected attachments	Count missing payloads and incorrect parents; record rendering tests separately.
Audit/signature/metadata coverage	Verified required artifacts divided by expected required artifacts, calculated separately by artifact class	Existence checks alone do not establish historical accuracy or signature meaning.
Sampled-record pass rate	Passed reviewed records divided by reviewed records	Report planned size, selection method, unavailable selections, failures, and unresolved reviews separately.
Exception aging	Assessment timestamp minus exception-open timestamp	Show unresolved age by severity, owner, and due date; retain closure and reopening history.

Each ratio should expose its numerator and denominator alongside the displayed result. An empty eligible population is not applicable, with justification, rather than an automatic pass. For audit and signature coverage, distinguish automated presence checks from substantive attribute and linkage verification. Applicable signature-linkage requirements illustrate why an inventory alone is insufficient. (^[8]) (^[33])

What a clean sample can and cannot support

(Hypothetical Example) Choose a simple binomial illustration: 300 independent random observations, zero failures, and 95% one-sided confidence. From the binomial probability of no failures, (1 - p)^n = alpha, the upper bound is p = 1 - alpha^(1/n). With the chosen inputs, 1 - 0.05^(1/300) = 0.00993608, approximately 0.994%. This is an analyst calculation derived from NIST's binomial model and exact one-sided interval approach, not an observed migration benchmark. (^[7]) (^[6]) (^[5])

The bound concerns an unknown failure proportion under the model; it does not certify that every migrated record is correct. NIST specifies independent experiments and fixed event probability. (^[41]) (^[7]) A shared mapping error can affect a whole subgroup, so the model may be inappropriate. Purposeful selection of difficult records also lacks the simple random-sampling basis. Report that review as targeted coverage of specified risks, not as a confidence estimate.

Finally, attach each exception to the original check, affected population, likely cause, retest evidence, impact, and disposition. Annex 15 expects results to be summarized against acceptance criteria. (^[58]) A dashboard should therefore expose unresolved record classes and limitations, not collapse them into a single migration success percentage.

The evidence pack should become a controlled operating asset. Migration approval should identify who maintains the archive, checks continued access, manages dependencies, and reassesses preservation after changes. Annex 11 calls for archived-data accessibility, readability, and integrity checks. (^[59]) Health Canada's corresponding guidance also addresses these properties and retrieval following relevant changes. (^[60])

The following residual-risk register is a proposed minimum for handover. It makes the limits of the validation argument visible without claiming that risk acceptance overrides an applicable obligation. ICH explicitly preserves the duty to meet regulatory requirements. (^[19])

• Open limitation: identify the affected records, properties, and intended uses with precise boundaries.
• Evidence gap: state what remains untested, inaccessible, or dependent on the retained source.
• Compensating control: name the owner, procedure, effectiveness evidence, and monitoring trigger.
• Decision and expiry: record approval, rationale, review date, and conditions requiring escalation.
• Source dependency: specify what must remain available before further retirement or disposition is authorized.

Periodic verification should combine scheduled integrity checks with event-driven retrieval tests after significant platform, storage, identity, or rendering changes. The Digital Preservation Coalition recommends regular checksum checks, with the interval informed by storage and usage. (^[61]) NARA's own preservation program records file fixity values, while Library of Congress guidance considers specifications and validation-tool availability. (^[62]) (^[63]) These are complementary engineering references, not prescribed GxP frequencies.

Future regulatory revisions should enter change control through the applicable published catalog and implementation dates. The Commission's consultation materials should remain visibly distinguished from the operative text until their status changes. (^[12]) For each new requirement or technical dependency, reassess the evidence already retained, identify affected populations, and target additional verification. Avoid assuming that a later successful access test repairs missing historical context.

GxP data migration validation should support a specific decision about a specific population of records. The evidence needs to connect approved scope, expected transformations, executed checks, record reconstruction, exception disposition, and release approval. The governing objective is preservation of value, meaning, and availability, rather than successful movement alone. (^[22]) (^[14])

The proposed evidence pack makes that argument inspectable. Inventory the complete record; profile the source; approve mappings and acceptance criteria; execute reproducible rehearsals; reconcile the final population; review interpretation and historical context; and test recovery. Report the actual coverage of each check, including missing or untested objects. Sampling adds evidence about selected records, but its limits must remain explicit. The NIST assumptions underlying the illustrative calculation do not automatically describe migration defects. (^[41])

Cutover, source retirement, and eventual destruction require separate decisions and evidence. A controlled source may remain necessary until the archive preserves required history and functionality. Retention obligations continue independently of project completion, and destruction must wait until applicable retention conditions are met. (^[48])

The practical deliverable is therefore an approved, traceable explanation of what was preserved, how it was tested, what remains uncertain, and who owns continued access. A reviewer should be able to follow that explanation from the expected population through the final report without reconstructing the migration from informal messages. That is the purpose of a cutover evidence pack: make the decision and its limitations reviewable throughout the remaining record lifecycle.