This is a ready-to-use risk assessment for scoping a GxP data migration before the mapping specification and verification protocol are built. Replace every <<FILL: ...>> placeholder with your own specifics, set your document numbers and dates, and route it through your normal document control, review, and approval. A worked filled specimen follows the template so you can see how a completed version reads. This is general guidance to adapt and verify, not legal or regulatory advice; confirm each cited regulation against the current source before you rely on it.
The output of this assessment feeds two other documents: the verification depth column in the data migration validation protocol, and the sampling basis stated in the reconciliation report. Keep all three consistent with the band this assessment assigns.
Document control header
| Field | Entry |
|---|---|
| Document title | Data Migration Risk Assessment for <<FILL: source system to target system>> |
| Document number | <<FILL: RA-ID, e.g. RA-CSV-041>> |
| Version | <<FILL: version, e.g. 1.0>> |
| Effective / assessment date | <<FILL: date>> |
| Supersedes | <<FILL: prior version or "New">> |
| Document owner | <<FILL: role, e.g. Validation Lead>> |
| Source system / target system | <<FILL: source system name, version>> to <<FILL: target system name, version>> |
| Assessment team | <<FILL: names and roles, including a business SME who knows the source data, IT/migration engineer, and QA>> |
| Feeds | <<FILL: migration plan document number, migration validation protocol document number>> |
1. Purpose
This assessment ranks each data class in scope for the migration of <<FILL: source>> to <<FILL: target>> by criticality, source data quality, and transformation complexity, converts the ranking into a required verification approach, and records the mitigations and residual risk for any class that cannot reach its required depth before cutover. The objective is a documented, defensible answer to why one data class received 100 percent field verification and another received a justified sample, rather than a judgment call applied inconsistently across the migration.
2. Scope
This assessment covers every data class listed in section 7 moving from <<FILL: source system>> to <<FILL: target system>> under <<FILL: migration plan document number>>. It sets the required verification depth and sampling strategy for each class.
It does not define the field-by-field mapping, which is governed by the migration specification (<<FILL: mapping document number>>), and it does not execute the verification, which is governed by the data migration validation protocol (<<FILL: protocol document number>>). Re-score a data class whenever its source data quality, transformation rule, or in-scope population changes materially after this assessment is approved, and before verification for that class begins.
3. Responsibilities
| Role | Responsibility |
|---|---|
| Assessment author (Validation Lead) | Convenes the assessment, applies the scoring method consistently across classes, and owns the resulting document. |
| Business / data SME | Provides the factual picture of source data quality, known issues, and how each data class is actually used, not how it is described in a system description. |
| Source system SME / IT | Confirms transformation complexity from the actual mapping candidates and what the source data profiling shows. |
| Quality Assurance | Challenges optimistic quality or complexity scores, approves the assigned bands, the mitigations, and the residual risk statement. |
4. Definitions
- Data class: a defined, nameable population of records with a common structure and common risk profile (for example stability results, sample disposition, audit trail history, user accounts).
- Source data quality: the state of the data before extract, including completeness, consistency, duplication, and how it was entered historically. Assessed by profiling the source, not by assuming it is clean.
- Transformation complexity: how much logic sits between the source value and the target value, from a direct copy to a multi-system code-list consolidation.
- Risk band: the High, Medium, or Low classification this assessment assigns to a data class, which sets the required verification depth.
- Criticality floor: a rule that a data class feeding a disposition, safety, or submission decision always receives 100 percent verification of the specific fields that drive that decision, regardless of the computed band for the rest of the class.
5. Method
5.1 Sequence
- List every data class in scope from the migration plan and the source system inventory. A class not listed here is not in scope for migration and its disposition (archive or retain in legacy) is recorded in the migration plan instead.
- Score each class on the three factors in section 5.2 using the anchored scales.
- Sum the scores, apply the override rule in section 5.3, and assign the risk band.
- Map the band, and the population volume, to a required verification approach using section 5.4.
- Where a class cannot reach its required depth before the planned cutover date, apply a mitigation from section 6 and record the residual risk.
- Feed the assigned band and verification approach into the migration specification’s testing plan and the data migration validation protocol before either is finalized.
5.2 Scoring scales
Score each data class from 1 to 5 on each factor. Score the data as it actually is in the source system today, confirmed by profiling, not as the system description claims it to be.
Criticality (C): what depends on the data once it lands in the target.
| Score | Anchor |
|---|---|
| 5 | Directly supports batch or lot disposition, release, a safety report, a signed regulatory submission, or carries electronic signature meaning |
| 4 | Feeds a product quality decision that is not itself disposition, such as an in-process accept, a stability trend, or an OOS investigation input |
| 3 | Controls or monitors a process step where a downstream control would likely catch an error before it caused harm |
| 2 | Supports GxP activity with no direct decision dependency, such as an active reference lookup or a maintenance log |
| 1 | Informational or historical reference data with no GxP decision dependency |
Source data quality risk (Q): the state of the data before it is touched. Higher score means worse quality and more risk.
| Score | Anchor |
|---|---|
| 5 | Free-text fields, confirmed duplicate or orphaned records, no source profiling performed yet, known inconsistent legacy entry practice |
| 4 | Source profiled and material issues confirmed (missing mandatory values, inconsistent formats, unreconciled duplicates) with no remediation plan defined |
| 3 | Source profiled, minor issues found, and a defined handling rule exists for each one |
| 2 | Source profiled, largely clean, isolated exceptions understood and dispositioned |
| 1 | Source structured, clean, itself subject to ongoing data quality controls, profiled with no material issues found |
Transformation complexity (T): how much logic sits between source and target for this class.
| Score | Anchor |
|---|---|
| 5 | Merging two or more systems’ code lists or vocabularies for the same field, or a derivation that itself requires an SME judgment call rather than a fixed rule |
| 4 | Splitting a concatenated field, a non-trivial multi-value lookup, or a derivation with several conditional branches |
| 3 | A defined format conversion with a documented, unambiguous rule, such as a date reformat or a unit conversion |
| 2 | A simple, small, closed lookup table where every value is already mapped |
| 1 | A direct one-to-one copy with no transformation |
5.3 Combining scores and the override rule
Total = C + Q + T, range 3 to 15.
| Total | Risk band |
|---|---|
| 11 to 15 | High |
| 6 to 10 | Medium |
| 3 to 5 | Low |
Override rule. A Criticality score of 5 combined with a Source data quality score of 4 or 5 is always rated High, regardless of the arithmetic total. This is the single riskiest combination the method can describe: a disposition, safety, or submission-critical record built on data already known to be dirty. Record any application of this rule explicitly in section 7 so a reviewer can see the band was set by rule rather than by arithmetic alone.
Criticality floor. Independent of the computed band, a data class scored Criticality 5 always receives 100 percent verification of the fields that drive the criticality-5 decision. The band still sets the depth applied to the remainder of the record (an extended edge-case set at Medium, a standard edge-case set at Low) and scopes the mitigation effort in section 6. A Medium band on a Criticality-5 class is not a reason to sample the decision-driving field; it is a statement that the rest of the record carries proportionately less risk.
5.4 From band to verification approach
| Risk band | Required verification approach |
|---|---|
| High | 100 percent field-by-field comparison where volume allows manual or spot-checked review. Where volume makes full manual comparison impractical, an automated 100 percent field-comparison script (itself version-controlled, peer-reviewed, and proven on known-good and known-bad rows), or a statistically justified sample with zero-defect acceptance for critical fields plus forced inclusion of every transformation branch, code value, and boundary case. The criticality floor in 5.3 applies regardless of which method covers the remainder. |
| Medium | A defensible sample, statistical or risk-based, covering every transformation rule and boundary case, plus 100 percent verification of any subpopulation flagged during source profiling, such as all currently active or in-use records of that class. |
| Low | Record count reconciliation plus a spot check of a small number of records. |
State your sampling basis explicitly when you use one, whether a statistically justified plan (for example an accepted attribute sampling standard such as the ANSI/ASQ Z1.4 or ISO 2859-1 family) or a defined risk-based count with full coverage of every transformation rule.
6. Mitigations where the required depth is not feasible before cutover
| Gap | Mitigation | What it addresses | Notes on strength |
|---|---|---|---|
| Class scores Q4 or Q5 (poor source quality) and is also Criticality 5 | Profile and remediate the source before extract where feasible (deduplicate, resolve orphans, correct known bad values). Where remediation cannot complete before cutover, apply a documented, QA-approved exclusion or manual-review disposition for the affected records rather than migrating unresolved bad data. | Accuracy, completeness | Interim only; drives a data-cleansing action with an owner and a target date, tracked to closure before the class is declared migrated |
| Class scores T4 or T5 (high transformation complexity) with no business SME available to confirm the rule | Engage the business SME to co-author and approve the transformation rule before build. Write the expected output for a known input for every rule before coding, per the worked-example discipline in the parent article. | Accuracy | Do not proceed to build on a transformation rule nobody has confirmed |
| High-band class with volume too large for practical 100 percent manual verification | Automated field-comparison script plus a statistically justified sample with zero-defect acceptance, forced inclusion of every transformation branch and boundary case | Accuracy at scale | The comparison script is itself GxP-relevant code: version it, peer-review it, and prove it flags known errors before relying on it |
| Dry-run window too short to fully rehearse a High-band class at full volume | Extend the dry-run schedule, or run an additional full-volume dry run for that class specifically. Do not compress the rehearsal to meet a fixed cutover date. | Detection of runtime, truncation, and reference-data gaps before production | A dry run that never ran at full volume for the highest-risk class is not evidence the migration will work |
| Audit trail or metadata class where completeness cannot be sampled meaningfully | Treat completeness as a 100 percent count and render check regardless of band; a partial audit trail is not a partial risk, it is a broken record | Completeness | Sampling is not a valid substitute for completeness on this class type |
A mitigation closes a feasibility gap. It does not close this assessment. Every row using one carries an action, an owner, and a target date in section 8.
7. Assessment table
Complete one row per data class in scope. The rows below show the shape; replace with your own.
| # | Data class | Criticality (C) | Source quality (Q) | Transformation complexity (T) | Total | Override applied | Risk band | Verification approach |
|---|---|---|---|---|---|---|---|---|
| 1 | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL: none, or rule 1>> | <<FILL>> | <<FILL>> |
| 2 | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> |
| 3 | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> |
8. Residual risk statement and actions
| Field | Entry |
|---|---|
| Data classes assessed | <<FILL: count>> |
| High band | <<FILL: count>> |
| Medium band | <<FILL: count>> |
| Low band | <<FILL: count>> |
| Classes with a mitigation from section 6 in use | <<FILL: count, each with the record that evidences it>> |
| Residual risk statement | <<FILL: plain-language statement of what risk remains where a mitigation is in use, why the class could not reach full required depth before cutover, and what would change the conclusion>> |
| Actions (remediation, re-scoring, escalation) | <<FILL: action, owner, target date, one row per action>> |
| Trigger for re-assessment | <<FILL: source quality changes, transformation rule changes, in-scope population changes, or a defect found during dry run>> |
State the residual risk in language a reader outside the assessment team can evaluate. “Residual risk is acceptable” is a conclusion with the reasoning removed, not a statement.
9. Approval
| Role | Name | Signature | Date |
|---|---|---|---|
| Prepared (Assessment author) | <<FILL>> | ||
| Reviewed (Business / data SME) | <<FILL>> | ||
| Approved (QA) | <<FILL>> |
10. References
21 CFR Part 11 (electronic records and electronic signatures). 21 CFR 211.68, 211.180, 211.194. EU GMP Annex 11 (Computerised Systems), including data migration and accuracy checks. MHRA GxP Data Integrity Guidance and Definitions. PIC/S PI 041, Good Practices for Data Management and Integrity. ICH Q9(R1), Quality Risk Management, for the risk-based scoring method. GAMP 5 (Second Edition), for the risk-based, critical-thinking approach to scoping verification effort.
Confirm the current version and clause numbers of each reference before issue.
Filled specimen
The following scores six data classes for an example LIMS replacement, so you can see the level of detail an inspector expects. The company, systems, and numbers are illustrative; replace them with your own.
Source / target: Legacy LIMS v6 to new LIMS v3. Assessment team: R. Okonkwo (Validation Lead), S. Adeyemi (QC Business SME), P. Sandoval (IT Migration Engineer), QA reviewer.
| # | Data class | C | Q | T | Total | Override applied | Risk band | Verification approach |
|---|---|---|---|---|---|---|---|---|
| 1 | Stability results | 5 | 1 | 2 | 8 | None (Q below 4) | Medium, criticality floor applies | 100 percent verification of result value, unit, and disposition-relevant fields (floor); extended edge-case set on the remainder |
| 2 | Sample disposition / status | 5 | 4 | 4 | 13 | Rule 1 (C5 + Q4) | High | 100 percent field comparison plus mapping review; every legacy status code forced into the sample |
| 3 | Audit trail history | 5 | 1 | 4 | 10 | None | Medium, criticality floor applies | 100 percent completeness and render check (floor; completeness cannot be sampled), extended edge-case set on entry content |
| 4 | Analyst master data | 2 | 1 | 1 | 4 | None | Low | Count reconciliation plus spot check |
| 5 | Method definitions | 4 | 1 | 2 | 7 | None | Medium | Statistically justified sample plus 100 percent of currently active methods |
| 6 | Instrument lookup table | 1 | 1 | 1 | 3 | None | Low | Count reconciliation plus spot check |
Mitigation applied: Sample disposition / status scored Q4 because the legacy field mixes coded and free-text entries with 11 distinct status strings, some inconsistently cased. Mitigation: the business SME built and approved a single crosswalk covering all 11 legacy variants before build began; verification forces inclusion of every one of the 11 values in the comparison sample regardless of population weighting. Action: crosswalk approved 3 June 2026, tracked to closure, no open action remaining at assessment approval.
Residual risk statement. “Six data classes assessed: two High (sample disposition/status, forced by the override rule on a known dirty source field, fully mitigated by a reviewed crosswalk before build), two Medium with the criticality floor applied (stability results and audit trail history, both submission or completeness-critical and both verified at 100 percent on the fields that matter regardless of the Medium band), one Medium by arithmetic alone (method definitions, sampled with full coverage of active methods), and one Low (instrument lookup table). No open mitigation remains unresolved. Residual risk is accepted at Medium overall, driven by the transformation complexity of the audit trail schema change, with the render check providing direct evidence the migrated trail displays correctly rather than relying on the band alone.”
Common inspection findings this risk assessment prevents
- Every data class verified to the same shallow depth because nobody scored the difference between a disposition-critical class and a reference lookup.
- A criticality-5 class rated an overall Medium or Low band, and the decision-driving fields sampled instead of fully verified, because the band was read as the whole answer instead of a floor plus a band.
- Source data quality assumed rather than profiled, so a free-text field with known duplicates enters build with a Q score that has no evidence behind it.
- Transformation complexity scored by the person who wrote the rule, with no independent business SME confirmation that the rule is actually correct.
- A high-risk class left at a shallow verification depth because the population was “too big to check,” with no automated comparison script and no statistically justified sampling plan to substitute for it.
- A mitigation applied to a data quality gap with no tracked action, owner, or target date, so the gap is still open when the class is declared migrated.
How to adapt this risk assessment
- Set your document number and point the “Feeds” field at your real migration plan and migration validation protocol document numbers.
- List your actual data classes from the source system inventory, not a generic set; a class with no row here has no assigned verification depth.
- Score source data quality from an actual profiling exercise, not from what the system owner believes about the data.
- Keep the override rule and the criticality floor even if you adjust the band boundaries to fit your organization’s existing risk scale; both exist to stop a genuinely dangerous class from hiding inside an average score.
- For every mitigation used in section 6, attach the record that evidences it closed, not just that it was planned.
- Confirm every regulation in section 10 against the current published version before issue.