Computerized System Data Migration Validation

Computerized system data migration validation provides documented evidence that regulated data and records are transferred completely, accurately, securely, and with their required meaning and context preserved.

Migration may occur during:

• implementation of a new system;
• replacement of a legacy application;
• consolidation of systems;
• transfer to a cloud service;
• database conversion;
• application upgrade;
• acquisition or site transfer;
• or movement of records into an archive.

A technically successful transfer does not establish that the migrated records are suitable for regulated use. Validation must address record content, metadata, relationships, audit trails, electronic signatures, attachments, transformations, exceptions, reconciliation, and the final disposition of the source system.

Purpose of Migration Validation

Migration validation should demonstrate that:

• the source-data population was understood;
• migration scope was approved;
• inclusion and exclusion rules were correctly applied;
• source fields and objects were mapped to the correct target locations;
• transformations and cleansing were controlled;
• legacy codes retained their intended meaning;
• required metadata and record relationships were preserved;
• audit trails, signatures, and attachments were appropriately addressed;
• migration tools performed reliably;
• access to migration data was restricted;
• dry runs identified and resolved problems;
• migrated populations were reconciled;
• critical content was compared;
• exceptions were investigated;
• rollback was available where required;
• acceptance criteria were met;
• and source records remained controlled after cutover.

Migration assurance should be proportionate to the criticality of the data, complexity of the transformation, condition of the source records, migration-tool design, and consequences of incomplete or inaccurate conversion.

Position Within the Validation Lifecycle

Migration planning should begin during Computerized System Validation Planning and Strategy, not after the target system is ready for release.

Migration activities should be coordinated with:

• intended-use definition;
• system-boundary decisions;
• data and retention requirements;
• risk assessment;
• target-system configuration;
• interface design;
• functional testing;
• end-to-end testing;
• traceability;
• release planning;
• and legacy-system retirement.

The migration requirements should define what the organization expects the target system to contain and how successful migration will be demonstrated.

Migration acceptance should be completed before the target system becomes the authoritative source unless an approved staged-migration strategy establishes a different controlled arrangement.

Source-Data Assessment

The source-data assessment establishes what exists, what condition it is in, and what must remain available. The assessment should identify:

• source applications and databases;
• record types;
• data objects and tables;
• regulated and nonregulated records;
• active and inactive records;
• open and closed records;
• master data;
• reference data;
• calculated values;
• metadata;
• audit trails;
• electronic signatures;
• attachments;
• links and relationships;
• retained reports;
• and historical records.

The assessment should also identify source-data problems, including:

• incomplete records;
• duplicates;
• invalid formats;
• obsolete codes;
• orphaned attachments;
• broken relationships;
• inconsistent dates;
• missing metadata;
• unreadable files;
• unsupported characters;
• and records affected by known system defects.

Migration should not conceal pre-existing data-quality problems. The organization should distinguish between:

• an existing source-data condition;
• a migration-induced error;
• and an approved data correction.

Data Ownership and Authoritative Sources

The migration plan should identify the owner of each data population and the system considered authoritative before, during, and after cutover. The plan should define:

• when the source system stops accepting new transactions;
• whether temporary dual entry is permitted;
• how transactions occurring during migration are controlled;
• when the target becomes authoritative;
• how failed or delayed records are handled;
• and which system is used during rollback.

Uncontrolled operation of both systems can create competing authoritative records.

Where temporary parallel operation is required, the organization should define:

• permitted activities in each system;
• synchronization rules;
• reconciliation;
• conflict resolution;
• and the date on which parallel use ends.

Migration Scope

The approved scope should identify the exact populations included in the migration. Scope may be defined by:

• record type;
• object;
• date range;
• status;
• product;
• site;
• department;
• retention period;
• or business need.

The scope should also address associated elements that may not be obvious from the primary record, such as:

• comments;
• attachments;
• metadata;
• approval history;
• audit trails;
• signatures;
• related records;
• and reference data.

A broad statement such as “migrate all historical data” is insufficient unless the relevant objects and selection rules are defined.

Inclusion and Exclusion Rules

Inclusion and exclusion rules determine which records are transferred, archived, retained only in the source, or approved for disposition. The rules should be:

• specific;
• testable;
• reproducible;
• approved by the data or process owner;
• and consistent with retention requirements.

Examples include:

• migrate all open records;
• migrate closed records created after a defined date;
• retain older records in a controlled archive;
• exclude temporary records with no regulated value;
• exclude duplicates identified through an approved rule;
• or convert obsolete records into a readable archival format.

Excluded data should not disappear without explanation. The migration record should identify:

• the excluded population;
• the reason;
• applicable retention requirements;
• location after migration;
• access method;
• and approval.

Field and Object Mapping

Mapping defines how each source element corresponds to the target system. The mapping specification should identify:

• source object;
• source field;
• target object;
• target field;
• data type;
• format;
• field length;
• unit;
• precision;
• permitted values;
• transformation rule;
• default value;
• required or optional status;
• and exception handling.

Object mapping should also address:

• one-to-one transfer;
• one-to-many conversion;
• many-to-one consolidation;
• split records;
• merged records;
• and records with no direct target equivalent.

Mappings should be reviewed by personnel who understand both the data and the business process. A technically valid mapping can still be incorrect if it changes the record’s regulated meaning.

Transformations

A transformation changes the form or value of source data during migration. Examples include:

• date-format conversion;
• unit conversion;
• code translation;
• text concatenation;
• field splitting;
• precision adjustment;
• status conversion;
• character-set conversion;
• and creation of a target value from several source fields.

Each transformation should have:

• a defined business rule;
• approved logic;
• expected results;
• error handling;
• and verification.

Transformation logic should be tested using:

• routine values;
• boundary values;
• blank values;
• invalid values;
• special characters;
• maximum field lengths;
• and representative legacy conditions.

Rounding, truncation, defaulting, or loss of precision should not occur without documented assessment and approval.

Data Cleansing

Cleansing may be necessary when the source contains known errors, duplicates, inconsistent formats, or obsolete values. Cleansing should be controlled separately from technical migration so that the organization can determine:

• what the original value was;
• why it was changed;
• who approved the change;
• what rule was applied;
• and what the corrected value became.

Approved cleansing methods may include:

• duplicate resolution;
• format normalization;
• correction of invalid codes;
• completion of permitted missing values;
• closure of obsolete records;
• and removal of nonrecord temporary data.

Migration should not be used as an undocumented opportunity to improve or rewrite historical records.

Where regulated data are corrected, the correction should remain attributable and justified.

Legacy Codes and Reference Values

Legacy systems may use codes, abbreviations, status values, or identifiers that do not exist in the target system. The mapping should define how each legacy value is handled.

Possible approaches include:

• direct equivalent mapping;
• mapping several legacy values to one approved target value;
• retaining the legacy value in a dedicated field;
• creating a controlled target reference value;
• or retaining the record in the source or archive.

When several source values are consolidated, the organization should confirm that the distinction is no longer required for interpretation, reporting, investigation, or regulatory review.

Original legacy identifiers should generally remain available when needed to support record traceability.

Metadata

Metadata provides context needed to understand and reconstruct the record.

Applicable metadata may include:

• creator;
• creation date and time;
• modifier;
• modification date and time;
• record status;
• effective date;
• version;
• source system;
• equipment or instrument identity;
• method;
• units;
• sequence;
• approval state;
• and relationships to other records.

Migration validation should determine which metadata must be transferred, transformed, retained in the source, or preserved through an archival method.

A migrated result without its units, method, status, or record association may be unusable even when the numerical value is correct.

FDA’s Data Integrity and Compliance With Drug CGMP guidance discusses the importance of data context and metadata in maintaining complete and meaningful CGMP records.

Audit Trails

Audit-trail migration requires a specific strategy.

Depending on system capability, the organization may:

• migrate audit-trail entries into the target system;
• migrate them into a linked read-only repository;
• retain them in the validated legacy system;
• preserve them in an approved archival format;
• or use a controlled combination of these approaches.

The strategy should preserve, as applicable:

• affected record;
• action;
• user identity;
• date and time;
• previous value;
• new value;
• reason for change;
• and chronological sequence.

Migrated historical audit entries should not be represented as new target-system events created by the migration account without preserving their original identity and context.

Audit-trail records should remain available for review for the required retention period. Applicable Part 11 closed-system requirements are described in 21 CFR 11.10(e).

Electronic Signatures

Electronic signatures may not be technically transferable between systems because the signature depends on the source system’s identity, security, record linkage, and signature implementation. The migration strategy should preserve:

• signer name;
• signature date and time;
• signature meaning;
• signed record;
• record version or state;
• and permanent linkage between the signature and record.

Possible approaches include:

• validated transfer of signature information;
• migration of a signed representation;
• retention of the signed record in the source;
• or controlled archival of the complete signed record.

Historical signatures should not be recreated as new signatures by migration personnel.

The selected approach should preserve the evidence that the original signature represented.

Attachments

Attachments may include:

• documents;
• images;
• chromatograms;
• spectra;
• certificates;
• investigation evidence;
• correspondence;
• reports;
• and scanned records.

Attachment migration should verify:

• file presence;
• file name;
• file type;
• size;
• readability;
• integrity;
• relationship to the correct parent record;
• and applicable metadata.

A record count may show successful migration even when attachments are missing or linked to the wrong record.

Unsupported or corrupted files should be documented and resolved before acceptance.

Record Relationships

Relationships may connect:

• parent and child records;
• batch and material records;
• sample and result records;
• deviations and corrective actions;
• changes and affected documents;
• training assignments and completions;
• attachments and parent records;
• or original and revised records.

Testing should confirm that:

• related records remain connected;
• sequence and hierarchy are preserved;
• links open the correct object;
• and reports or workflows use the migrated relationships correctly.

Orphaned records should be identified through automated checks or reconciliation.

Migration Tools

Migration may use:

• commercial extraction and loading tools;
• database utilities;
• supplier migration services;
• scripts;
• spreadsheets;
• application programming interfaces;
• interface engines;
• or custom programs.

The migration-tool strategy should reflect tool complexity and risk.

Applicable evidence may include:

• intended use;
• tool version;
• approved script or configuration;
• code review;
• test records;
• access restrictions;
• execution logs;
• error logs;
• change control;
• and supplier evidence.

A one-time tool may not require the same lifecycle documentation as a permanent application, but its operation should still be sufficiently controlled and verified for the migration it performs.

Security and Access

Migration commonly requires elevated access to source and target data. Controls should address:

• authorized migration personnel;
• privileged accounts;
• service accounts;
• extraction permissions;
• target loading permissions;
• temporary credentials;
• encryption;
• secure staging locations;
• transfer methods;
• audit logging;
• and removal of temporary access.

Migration data stored in temporary files or staging databases should receive protection appropriate to the source records.

Temporary data should be securely disposed of when no longer required, subject to approved retention and investigation needs.

Dry Runs

Dry runs allow the migration process to be tested and improved before production cutover. A dry run should use representative data and evaluate:

• extraction;
• mapping;
• transformation;
• loading;
• runtime;
• error handling;
• reconciliation;
• reporting;
• and rollback.

Dry runs should identify:

• failed records;
• unexpected source conditions;
• mapping defects;
• performance constraints;
• missing reference data;
• unsupported attachments;
• relationship errors;
• and inaccurate reconciliation logic.

Corrections resulting from a dry run should be controlled. The final production migration should use the approved tool, mapping, and procedure established through the dry-run process.

Source Freeze and Cutover

The cutover plan should define how source data are controlled during the final migration. Applicable controls include:

• transaction cutoff;
• source-system freeze;
• final extract date and time;
• treatment of transactions in progress;
• delayed transaction entry;
• reconciliation period;
• target-system availability;
• user communication;
• and rollback decision points.

The organization should retain evidence identifying the exact source population used for the production migration.

Changes to source data after extraction should be prevented, captured in a controlled delta migration, or reconciled separately.

Migration Execution

The production migration should be performed according to an approved procedure or run plan. The execution record should identify:

• source and target environments;
• migration-tool version;
• approved mapping version;
• source extract;
• execution date and time;
• responsible personnel;
• run identifiers;
• processing logs;
• record counts;
• rejected records;
• warnings;
• interruptions;
• and completion status.

Unplanned reruns should be controlled. The organization should understand whether rerunning the migration can create duplicate records, overwrite corrected data, or alter identifiers.

Counts and Control Totals

Counts and control totals provide population-level evidence. Applicable comparisons include:

• total source and target records;
• counts by record type;
• counts by status;
• counts by date range;
• counts by site or product;
• attachment counts;
• relationship counts;
• and rejected or excluded record counts.

Control totals may include:

• quantities;
• monetary values;
• result totals;
• batch totals;
• sample totals;
• or other meaningful aggregated values.

A matching total count does not prove that the correct records were migrated. Counts should be combined with content and relationship verification.

Sampling

Sampling may be used for content verification when complete automated comparison is impractical. The sampling strategy should consider:

• data criticality;
• transformation complexity;
• source-data condition;
• record type;
• date range;
• status;
• exceptional records;
• attachments;
• signatures;
• and known problem areas.

The sample should include more than typical records. It should deliberately include:

• transformed records;
• boundary values;
• long text;
• special characters;
• historical records;
• corrected records;
• signed records;
• records with attachments;
• and complex relationships.

Critical fields and high-risk transformations may require complete verification rather than sampling.

Content Comparison

Content comparison should determine whether the target record matches the approved expected result. The comparison may include:

• field values;
• units;
• precision;
• dates and times;
• text;
• status;
• calculations;
• metadata;
• signatures;
• attachments;
• and relationships.

Comparison may be:

• automated;
• manual;
• or a controlled combination.

Automated comparison logic should itself be verified. A comparison report is not reliable when the comparison tool uses the same incorrect mapping logic as the migration tool.

Independent checks are particularly important for critical transformations.

Exception Handling

Migration exceptions may include:

• rejected records;
• missing required values;
• invalid codes;
• truncated fields;
• duplicate target records;
• failed attachments;
• broken relationships;
• count variances;
• transformation errors;
• and unexpected tool messages.

Each exception should be:

• uniquely identified;
• associated with the affected record or population;
• classified;
• investigated;
• corrected or dispositioned;
• reverified;
• and included in final reconciliation.

The exception record should distinguish between:

• a source-data problem;
• an approved exclusion;
• a migration defect;
• and a target-system limitation.

Reconciliation

Final reconciliation should account for the complete approved migration population.

A basic reconciliation relationship is:

Source population = successfully migrated records + approved exclusions + unresolved or failed records

Unexplained differences should not be hidden through adjustments to counts or undocumented exclusions.

The final reconciliation should confirm:

• all source records are accounted for;
• target counts are correct;
• exclusions are approved;
• rejected records are resolved;
• transformations are verified;
• attachments and relationships are addressed;
• and outstanding exceptions are visible.

Rollback

Rollback planning is required when the migration or cutover could fail after the source system has been frozen or the target has begun operation. The plan should define:

• rollback decision authority;
• decision deadline;
• source-system restoration;
• target-data disposition;
• handling of transactions created after cutover;
• reversal of interfaces;
• user communication;
• data reconciliation;
• and evidence retention.

Rollback should be tested or otherwise demonstrated where its successful execution is necessary to manage migration risk.

A rollback plan that simply states “return to the legacy system” is inadequate when source data, interfaces, user accounts, or operational procedures have already changed.

Migration Acceptance

Migration acceptance should confirm that:

• approved scope was completed;
• inclusion and exclusion rules were correctly applied;
• mappings and transformations were verified;
• counts and control totals reconcile;
• content comparisons met acceptance criteria;
• critical metadata and relationships were preserved;
• audit trails and signatures were appropriately addressed;
• attachments are complete and readable;
• exceptions were resolved or accepted;
• rollback status is known;
• and source-system disposition is approved.

Acceptance should be performed by appropriate data, process, technical, validation, and Quality representatives.

Migration evidence should remain connected through Requirements Traceability and Validation Evidence.

For drug-manufacturing systems, 21 CFR 211.68 requires checks of computerized-system input and output for accuracy based on system complexity and reliability. Migration verification should apply this principle to the transfer and conversion of regulated records.

Source-System Retention

The source system should remain available until the organization confirms that:

• the migration was accepted;
• required target records are complete;
• historical records remain readable;
• source-only information is controlled;
• regulatory retention requirements are met;
• and rollback is no longer required.

Retention options include:

• maintaining the validated legacy system;
• placing the system in controlled read-only mode;
• transferring records into a validated archive;
• retaining approved true copies;
• or maintaining a combination of these controls.

21 CFR 211.180 permits required records to be retained as originals or true copies and requires them to remain readily available during the retention period.

Keeping an unsupported legacy application indefinitely may create security, access, hardware, and readability risks. Continued retention should be governed by an approved strategy.

Legacy-System Disposition

Legacy-system disposition should identify what happens to:

• application software;
• databases;
• servers;
• interfaces;
• user accounts;
• privileged access;
• licenses;
• backup copies;
• encryption keys;
• certificates;
• documentation;
• and retained records.

Possible dispositions include:

• continued read-only operation;
• controlled archival;
• decommissioning;
• infrastructure retirement;
• contract termination;
• and secure destruction after retention requirements are satisfied.

Before decommissioning, the organization should confirm:

• required records are retained;
• retrieval has been tested;
• record meaning and context remain available;
• dependent interfaces are removed or redirected;
• access is withdrawn;
• and retirement approval is complete.

The relationship between migration, retention, archival, and retirement is addressed further in Electronic Records Lifecycle, Retention, and Archival.

Practical Outcome

Effective migration validation demonstrates that the approved source population was transferred or dispositioned under control and that the target records remain complete, accurate, readable, traceable, and suitable for their intended GxP use.

The migration is not complete merely because the target system contains data. Completion requires verified content and context, reconciled populations, resolved exceptions, approved cutover, and a controlled decision regarding the source and legacy system.