A regulator can ask for proof that it works

If software is part of a process that affects patient safety or product quality, it falls under GxP. The records need to show what the system was supposed to do, how it was built, and how that was verified.

Computer system validation ties those records together. The validation plan sets the scope and acceptance criteria. The user requirements specification describes what the system must do. Functional and design specifications describe how the system meets those requirements. Verification covers installation, operation and performance in the actual process. The validation summary report brings the evidence together. After release, the system remains under change control and periodic review.

A passing test in a GxP system needs to show more than pass or fail. It should identify what was tested, the requirement it covered, the version under test, the result, when it ran and what ran it. The framework also needs to retain that information so it can be reviewed later. On an NGS mutation calling platform, a Cypress framework covered 98 percent of frontend workflows, and every pipeline stage was validated programmatically. That shortened release cycles and reduced defects after release.

A requirement should lead to the test that covers it, and that test should lead to the result. The requirements system holds the requirements, the tests link back to them, and the results stay with the tests. The traceability report shows what is covered and where the gaps are. Automation keeps those links current instead of leaving someone to maintain them in a spreadsheet.

Validation produces plans, specifications, test scripts, executed records, summary reports, change control records and periodic reviews. Those records may need to remain available long after the original system has been replaced. On a Veeva Vault migration for a biotechnology company running clinical studies, more than 10,000 documents moved from AODocs. Metadata was mapped field by field, the migration was tested first, every file was hash verified, and the audit trail was retained.

Risk is not the same across the system

A low risk function can end up with the same validation effort as one where a failure could affect patient safety, product quality or data integrity. That is how teams spend time on the wrong parts of a system.

GAMP 5 provides a framework for handling this. It categorises software partly by how much has been configured or developed. Software used as supplied generally needs less validation than a configured product, while custom development calls for more. A risk assessment identifies the functions that affect patient safety, product quality or data integrity, and the validation work follows from that assessment. The important part is being able to explain why the level of validation was chosen.

The FDA's Computer Software Assurance guidance also takes a risk based approach and allows different types of testing, including vendor testing, unscripted testing, automated assurance where it fits, and formal scripted testing for higher risk functions. That can reduce the amount of testing done by hand, but the risk assessment still has to support the choices.

Keep the evidence with each release

Validation does not stop after the first approved release. Changes can affect the validated state, and manual validation becomes harder to manage as a system gets larger. We see release cycles stretch to six weeks or more when teams rely heavily on manual validation.

The test suite runs with each change, the results are captured automatically, and failures are found before the change reaches the validated environment. That is the practical part of Computer Software Assurance: put more effort into the areas that carry risk and use automated assurance where it fits, rather than treating every release as a full revalidation exercise.

We do not automate every test. Regression testing usually gives the best return because the same checks can run on every release. Functional, integration and performance testing are added where they are needed. Exploratory testing and user acceptance still involve people, and the test strategy should say which checks are automated and which are not.

The records have to keep their history

These are regulated records, not ordinary working files. A missing or corrupted record is a data integrity problem. The same applies if the link between a document and its approval history is lost, or if metadata, signatures, dates or approval history change during the migration.

The target system needs the right controls. If it will hold GxP records, it needs 21 CFR Part 11 controls, including audit trails, access control and electronic signatures where signatures are used. Moving compliant records into a system without those controls does not preserve the original compliance state.

We handle the migration as a controlled activity. A migration plan defines what moves and what counts as success. A data mapping records how each field and attribute is handled in the target. Verification checks that what arrived matches what left, using full comparison for critical records and statistical sampling where a complete comparison is impractical. A migration report records the outcome and any deviations. The old system is then retained or decommissioned under change control.

There is a practical benefit as well. Legacy validation documents are often scanned PDFs spread across systems and difficult to search. Putting them into a structured system makes the archive easier to search and use. Finding a periodic review or the test evidence for a particular function should not require another manual search across old systems.

Do you follow GAMP 5 or Computer Software Assurance?

Both. They address different parts of the same problem. GAMP 5 provides the categories and risk based structure. Computer Software Assurance puts more emphasis on using the right testing approach for the risk, including automated and unscripted testing where appropriate and formal scripted testing where the risk is higher.

Can automated tests be used as validation evidence?

Yes, provided they record enough information. What was tested, against which requirement, on which version, the result, when it ran and what ran it, stored with integrity controls and an audit trail, and signed with compliant electronic signatures where a person approves them. That depends on how the framework records and controls the evidence.

What does 21 CFR Part 11 require?

Controls over electronic records and electronic signatures in the US. Automated test results stored electronically need integrity controls and audit trails, and where a person approves them, compliant electronic signatures. It applies to the systems that hold regulated records as much as to the systems that produce them.

What should we automate first?

Regression testing is usually a good place to start because the same checks need to run on every release. Functional tests against defined requirements come next, then integration across system boundaries, then performance where load matters.

How do you keep a migration from breaking a document's compliance history?

By treating the migration as a controlled activity: migration plan, data mapping, verification of what arrived against what left, and a migration report covering the outcome and any deviations. Metadata, signatures, dates and approval history are the parts that matter most, because losing any of them is a data integrity failure.

Our documents are scanned PDFs in three different systems. Is that a problem?

It is common, and migration is a good time to address it. A structured, searchable destination makes the archive much easier for the team to use and can reduce the effort involved in the next validation.