Sooner or later you replace a validated system, and the records have to come with it. Migration is where a straightforward project turns difficult, because you are not just moving data — you are carrying regulatory obligations across a boundary and having to prove nothing changed on the way.
Most migrations go fine. The ones that don't usually failed quietly, and nobody noticed until an inspector asked for a record from six years ago.
Decide what actually has to move
Start here, because it determines the size of everything else. Not all data needs to live in the new system.
- Active records you will keep using — these migrate.
- Closed records still inside their retention period — these must remain retrievable, but not necessarily in the new system. An archive can be the right answer.
- Records past retention — with a documented decision, these may not need to move at all.
- Metadata and audit trails — the part everyone underestimates. A record without its audit trail has lost the thing that made it trustworthy.
Write the decision down per category with a rationale. Retention rules are covered in GxP archiving and data retention.
Proving nothing was lost or altered
This is the core of the validation, and it is mostly about counting and comparing.
- Reconciliation by count. Records out equals records in, per type, documented. Simple and non-negotiable.
- Field-level verification on a sample. Risk-based sample size, comparing values field by field — not a visual scan of a screen.
- 100% verification for critical fields. Results, specifications, approval status, signature meanings. Automated comparison, not eyeballs.
- Edge cases deliberately included. The longest record, one with special characters, one with an unusual status, the oldest, one with attachments. Migrations break on the unusual, not the typical.
- Transformation logic tested. If a field changes format or a status maps to a new value, that mapping is a specification and needs testing like any other.
- Audit trail continuity. Either migrated with the record, or the old trail retained and retrievable, with a documented link between the two.
The questions people forget
Are the signatures still meaningful? An electronic signature carries a meaning and an identity. If it migrates as a text field, you have converted a Part 11 signature into a note that says somebody signed. Decide explicitly how signed records are represented, and whether the old system must stay readable for them.
Who are the users now? Historical records refer to people. If user identities aren't mapped, attribution breaks — the A in ALCOA+.
What happens to the old system? Keeping it running "read-only just in case" is a decision with a cost: it stays in scope, needs periodic review, access control and patching. Decommissioning it properly is usually better, and is itself a controlled activity.
Can you still read the archive in year nine? A proprietary export format nobody can open is not retention. See archiving and retention.
Running it safely
- Do a dress rehearsal on a full copy. Not a subset — the volume is where timeouts and truncation appear.
- Freeze changes during cutover, and know exactly how you would reverse it.
- Keep the source untouched until verification passes. Never migrate-then-delete in one step.
- Have QA approve the verification results before the new system goes live, not afterwards.
- Treat a failed reconciliation as a deviation, with an investigation — not a quick re-run.
The migration plan and its verification report become part of the new system's validation package — see computer system validation and GxP software.
Where to go next
Explore GxP Copilot for AI-native validation, TraceDraft for source-traceable clinical documentation, or book a demo to see either on your own data.