Plan: Hybrid Record Retirement and Migration to Fully Electronic Records

This is a ready-to-use plan for moving off hybrid paper-and-electronic records. Replace every <<FILL: ...>> placeholder, set your document numbers and dates, attach your hybrid inventory and risk assessment, and route it through your normal document control, review, and approval. A worked filled specimen roadmap follows. Verify each cited regulation against the current source before you rely on it, and treat this as general guidance to adapt rather than legal or regulatory advice.

Hybrids are a transitional state rather than a defect. Inspectors do not generally expect them to be gone; they expect them to be known, controlled, risk-ranked, and moving. The weakest position is not having many hybrids, it is having no plan and no evidence of progress. This plan exists so that the answer to “what is your plan for hybrids?” is a document with scores, owners, and dates rather than an intention.

Document control header

1. Purpose

This plan defines how <<FILL: COMPANY NAME>> reduces its population of hybrid records, in a sequence set by risk, to a defined target state for each hybrid, while preserving the retrievability and reconstructability of every legacy hybrid record for its full retention period. It sets the prioritisation method, the migration paths, the deliverables that must exist before a hybrid can be declared retired, and the governance that keeps progress visible.

2. Scope

This plan covers every hybrid recorded in the hybrid inventory register at the sites listed in the header, across laboratory, manufacturing, engineering, warehouse, clinical, and quality operations, including all three hybrid patterns: electronic generation with paper review and signature; paper generation with electronic storage or summary; and split-field records.

It covers the decision on target state per hybrid, the prioritisation, the migration execution, the validation and change control that authorise the change, the fate of legacy records, and the criteria for declaring a hybrid retired.

It does not replace: validation of the replacement system, governed by <<FILL: SOP-ID for computer system validation>>; change control, governed by <<FILL: SOP-ID for change control>>; data migration validation, governed by <<FILL: SOP-ID or protocol for data migration validation>>; system decommissioning and archival, governed by <<FILL: SOP-ID for decommissioning>>; or the day-to-day control of hybrids that remain in service, governed by <<FILL: SOP-ID for hybrid record control and reconciliation>>. Hybrids remain fully controlled under that procedure until the day they are declared retired. Being on a migration roadmap is not a reason to relax an existing control, and a plan used that way makes the position worse rather than better.

Out of scope: replacement of systems for reasons unrelated to hybrid retirement, which follow the normal capital and change processes; and paper records with no electronic component at all, which are not hybrids and are governed by the documentation procedures.

3. Approach

The plan works in five moves, repeated per wave rather than performed once for the whole estate.

1. Establish the population. Take the hybrid inventory as the baseline. A hybrid that is not on the inventory cannot be prioritised, so inventory completeness is a prerequisite rather than a parallel activity.
2. Score and rank. Apply the prioritisation method in section 4 to every hybrid, producing a single comparable score.
3. Choose the target state and path. For each hybrid, decide what the end state is and which of the three migration paths in section 5 reaches it. Some hybrids will have a target state that is still hybrid, because full electronic capture is not feasible; that is an acceptable answer when it is a decision rather than a default, and it is recorded with its reasoning.
4. Sequence into waves. Group hybrids into waves by score, by shared infrastructure, and by dependency, per section 7.
5. Execute, verify, and declare. Deliver the migration, meet the acceptance criteria in section 8, close out under change control, and update the inventory.

Two structural choices are worth stating up front. First, sequence by shared infrastructure where possible: networking a chromatography data system typically retires the standalone-workstation weaknesses of a whole laboratory at once, and doing that as one project beats doing it eight times. Second, do not wait for a perfect target state before improving a control. Declaring the governing record and enforcing reconciliation costs almost nothing and can happen in the first month; replacing an instrument takes a capital cycle. The plan runs both tracks in parallel.

4. Prioritisation: risk basis and scoring method

Priority is the product of what depends on the data and how weak the controls are. A hybrid feeding a release decision with shared logins and no audit trail review outranks a low-criticality logbook with strong controls, and the scoring makes that comparison explicit rather than intuitive.

4.1 Data criticality score

Score what depends on the record. Take this from the data criticality classification where you already have one, and record the source.

4.2 Control weakness score

Score the current state of the controls, taken from the hybrid data integrity risk assessment so that the two documents agree.

4.3 Priority score and bands

Priority score = data criticality x control weakness, range 1 to 25.

4.4 Modifiers

Apply these after the base score, and record each application.

The last modifier matters. Firms sometimes score a hybrid down because nothing can be done about it, which quietly removes the highest-risk records from the plan. Infeasibility changes what you aim for, not how much attention the risk gets.

5. Migration paths

Most real programmes use all three. Path C is usually the highest-return move in a laboratory because it fixes attribution, clock control, audit trail, and backup for a whole population at once. Path A is what actually removes the paper. Doing C without A gives you a well-controlled electronic half and an unchanged worksheet.

6. Deliverables per migration

Every migration produces the deliverables below. Where a deliverable does not apply, record it as not applicable with a reason rather than omitting it.

7. Roles

Name individuals against these roles per migration rather than relying on the function. A migration owned by a department is owned by nobody.

8. Acceptance criteria for declaring a hybrid retired

A hybrid is declared retired only when all of the following are met and evidenced. Meeting most of them is not partial retirement; it is an ongoing hybrid with a new system in it.

1. The replacement or upgraded process is validated for its intended use, and the validation summary is approved.
2. The electronic record controls are configured, verified, and operating: complete audit trail that ordinary users cannot disable, individual named accounts, controlled and protected time source, retention set to at least the record retention period, backup with a restore tested by opening a real record.
3. The electronic signature controls, where signatures are applied, are verified: the manifestation carries the printed name of the signer, the date and time, and the meaning of the signing; the signature is linked to the specific record so it cannot be transferred by ordinary means.
4. Reconciliation between halves is no longer required because only one record now exists, or any remaining paper is purely informational, declared non-governing in writing, and the declaration is approved.
5. No field of the record exists only on paper. This is the check that catches an incomplete retirement: a system can hold the results electronically while the deviation note, the second-person verification, or the operator observation still lives on a sheet nobody migrated.
6. The procedures, forms, and training are updated, the retired forms are withdrawn through document control, and every affected role is trained with the training recorded.
7. Legacy hybrid records remain retrievable and reconstructable for their full retention period, demonstrated by an actual retrieval of a real legacy record, both halves, with the elapsed time recorded.
8. The archive strategy for the legacy electronic half is decided, executed, and documented per section 9.
9. The change is closed under change control, and the hybrid inventory entry is updated to Retired with the date.
10. A post-implementation check is scheduled at <<FILL: interval, e.g. 3 months>> after go-live to confirm the new controls are operating in practice and that no informal paper has reappeared.

Criterion 10 is not administrative. Informal paper reappears with some regularity after a migration, in the form of a personal notebook, a printed checklist, or a spreadsheet used to stage data before entry, and it recreates the hybrid without anyone declaring it.

9. Legacy data and archive strategy

Retiring a hybrid does not retire the records it already created. Those records stay subject to the same retention and reconstructability rules after the system that made them is gone, and the failure pattern is predictable: the instrument is replaced, the old workstation is wiped or scrapped, and three years later nobody can open the electronic half of a record whose paper half is still neatly filed.

9.1 Decide before decommissioning, never after

Once the workstation is wiped, the options narrow to expensive or impossible. Decide the strategy as part of the migration, not as a clean-up afterwards.

9.2 The decommissioned-system problem

Where the electronic half was created by a system that is being decommissioned, all of the following are addressed and recorded before the system is switched off:

1. What exists. A complete inventory of the records the system holds, with the retention period applicable to each.
2. What the record actually is. Whether the data is dynamic, and therefore whether an export can preserve it. A static export of dynamic data is a decision to lose the dynamic content, which may be acceptable when the record is old and the risk is low, but only when it is a documented decision.
3. The audit trail travels with the data. An archive that preserves results and drops the audit trail has preserved the half with less evidentiary value.
4. The link stays alive. If the electronic half moves to a new location or format, the identifier written on the paper half no longer resolves. Record the new location against the old identifier in the archive index, so a worksheet from four years ago still leads somewhere.
5. Retrieval is tested, not assumed. Restore a record and open it. Include a hybrid record in the test so both halves are confirmed to come back together.
6. Readability is re-confirmed periodically. For read-only retained systems and for exported formats, confirm at <<FILL: interval, e.g. annually>> that a record can still be opened, and record the confirmation.
7. The decommissioning itself is controlled. Executed under <<FILL: SOP-ID for decommissioning>> with its own plan and report.

9.3 Retention of the retirement evidence

Retain this plan, each retirement declaration, each archive strategy decision, and each retrieval test record for <<FILL: retention period>>. These documents are the evidence of what the governing record was at the time a historical batch or study record was created, which is exactly what a reviewer needs when they retrieve a record from before the migration.

10. Schedule structure

The plan is executed in waves rather than as a single programme, so that progress is visible and a delay in one migration does not stall the rest.

Wave 0 is the wave most often skipped, and it is the one that produces the fastest risk reduction per unit of effort. Declaring the governing record and enforcing reconciliation changes the risk profile of the entire population within a quarter and requires no capital.

Governance and reporting

Report at <<FILL: frequency, e.g. monthly>> to <<FILL: forum>>: total hybrids, count by band, count retired in the period, count of overdue actions with reasons, and any hybrid whose score changed. Present the plan at management review per <<FILL: SOP-ID for management review>>. Review and re-score the whole plan at least annually, and out of cycle whenever a new hybrid is identified, a system is upgraded or networked, or a deviation or audit finding relates to a hybrid.

11. References

21 CFR 211.68, 211.180, 211.194. 21 CFR Part 11, in particular 11.10, 11.50 (signature manifestations), and 11.70 (signature and record linking, including handwritten signatures executed to electronic records). EU GMP Annex 11 (Computerised Systems) and EU GMP Chapter 4 (Documentation). FDA guidance, Data Integrity and Compliance With Drug CGMP, Questions and Answers (December 2018). MHRA GXP Data Integrity Guidance and Definitions (March 2018). PIC/S PI 041, Good Practices for Data Management and Integrity in Regulated GMP/GDP Environments. ICH Q9, Quality Risk Management, for the risk basis of prioritisation. ICH E6 Good Clinical Practice, where clinical hybrids are in scope.

Related material: data migration validation, backup, restore, and disaster recovery validation, change control for validated systems, electronic signatures implementation, and the hybrid system inventory register.

Confirm the current version and clause numbers of each reference before issue.

12. Revision history

13. Approvals

Filled specimen

The following is a prioritised roadmap for an example site with six hybrids. Company, systems, names, and dates are illustrative; the scoring logic and the sequencing reasoning are the parts worth copying.

Scored roadmap

Wave sequence

Notes on the specimen decisions

Three of the scoring decisions in this roadmap are worth reading rather than skimming.

HYB-007 was pulled into Wave 1 by infrastructure, not by score. It scored the same as HYB-001, but even if it had scored lower it belongs in the same wave, because both are acquisition instruments moving onto the same networked server. Splitting them would mean qualifying the same infrastructure twice and running two change controls for one technical change.

HYB-002 scored P1 and is in Wave 2, which looks wrong until you read the modifier. The balances are already funded for replacement in Q3 2027 under the metrology capital plan. Migrating them separately in Wave 1 would mean buying interfaces for instruments due to be scrapped. The P1 score still does work: it requires interim compensating controls to be in place and evidenced from the day the score was assigned, which is why 100 percent second-person verification of every transcribed weight and same-day certified copies of thermal slips are operating now rather than from Q3 2027. The band drives the controls; the modifier drives the sequence.

HYB-004 has a target state that is still hybrid, and that is the honest answer. Field groups collected during a visit can move to direct data capture. Observations that originate in the subject’s medical chart cannot, because the chart is the source and it is not the sponsor’s system. Recording the target state as “controlled hybrid” with the certified copy discipline as the standing control is a decision with a reason. Recording it as “fully electronic, Q4 2029” would be a commitment nobody intends to meet, and an inspector who reads two consecutive versions of the plan will notice the date moving.

Common inspection findings this plan prevents

• Hybrids are treated as permanent, with no risk ranking, no roadmap, and no visible progress, which signals that the data integrity programme is not managing them.
• A migration roadmap exists but has no owners and no dates, or has dates that have moved in every revision with no reason recorded.
• Prioritisation is driven by which system was easiest to replace rather than by what depends on the data.
• Interim controls were deferred because a migration was planned, so the highest-risk hybrids ran uncontrolled during the years before their replacement arrived.
• A hybrid is declared retired while a field of the record, typically a deviation note or a second-person verification, still exists only on paper.
• Paper forms were retired but never withdrawn from circulation, so operators continue using them alongside the electronic record.
• The old system was decommissioned before the archive strategy was decided, and the electronic half of legacy records can no longer be opened.
• Legacy data was migrated with no verification that records are complete and unaltered after the move, and audit trails were not migrated at all.
• The paper half of a legacy record still cites an identifier that no longer resolves to anything, because the electronic half moved and the archive index was not updated.
• Informal paper reappeared after go-live, in the form of staging spreadsheets or personal checklists, recreating the hybrid without a declaration.

How to adapt this plan

1. Set the document number, owner, sponsor, and plan horizon in the header, and point the source inventory and risk assessment fields at your real documents.
2. Score every hybrid before you sequence anything. The sequence is an output of the scoring, and a plan that presents a sequence with no visible scoring invites the question of how it was chosen.
3. Take the criticality score from your existing data criticality classification rather than inventing a parallel scale, and take the control weakness score from your hybrid risk assessment. If the two documents disagree with this plan, fix the disagreement rather than carrying two numbers.
4. Run Wave 0 first and finish it. It is the cheapest risk reduction available and it makes every later wave easier, because a hybrid with a declared governing record and an operating reconciliation is a hybrid you understand.
5. Set realistic target quarters and then hold them. A roadmap whose dates move in every revision is worse evidence than a roadmap with fewer, firmer commitments, because the movement is visible across versions.
6. Where a fully electronic target state is not feasible, record the target as a controlled hybrid with its reasoning and a re-evaluation date. Do not invent a distant date to make the column look complete.
7. Decide the archive strategy in section 9 as part of each migration, and put the decision in the change request rather than leaving it to the decommissioning project.
8. Schedule the post-implementation check at go-live rather than intending to do it, and include a walk of the area looking for informal paper.
9. Confirm every regulation in section 11 against the current published version before issue.