Comparability, not documentation: how pharmaceutical technology transfer proves a handover

Pharmaceutical technology transfer moves products, processes, and knowledge between a sending unit and a receiving unit. It completes when there is documented evidence that the receiving unit can routinely reproduce the specified result against criteria agreed in advance.

That sentence contains the whole lesson. The completion test is performance by the recipient, measured against a standard written before anyone knew whether it would be met.

The protocol names the tests first

A transfer protocol identifies what moves, between whom, under which conditions, and how completion will be assessed. The structure includes written responsibilities, an authorised plan carrying acceptance criteria, records of changes and deviations, and a close-out conclusion approved by responsible persons.

Software handover routinely has the first, sometimes the third, and rarely the second or fourth. The acceptance criteria are the missing piece, and their absence is what lets a handover be declared complete on a date rather than on evidence.

Adapted for software, the protocol settles six things before transfer. The boundary: which releases, services, data, operating tasks, and exclusions are in scope. The parties and authority: who supplies evidence, who performs recipient tasks, who resolves disputes, who decides acceptance. The recipient’s constraints: what differs in staffing, access, infrastructure, capacity, and supported operating conditions. The evidence plan: what observation addresses each required capability, and what counts as missing or failing. The execution record: which version, under what conditions, by whom, with what deviations. And the resolution: what remains open, who owns it, what decision follows.

Assisted is a different claim from independent

The discipline that transfers best is recording what help was given.

A recipient who deploys the supplied service but relies on the sender to diagnose a failed dependency has demonstrated deployment and not diagnosis. The honest record says deployment observed, diagnosis assisted, and schedules further instruction and a later exercise.

The temptation is to change assisted to independent so the project can close. That single edit is the mechanism by which handovers that never happened are recorded as complete, and the incident three months later is its consequence.

Two related constraints hold. Exposing live users to make an exercise look realistic is not acceptable; controlled environments are used with their limits recorded. And one successful exercise does not establish that a team has the staffing for its future workload.

Comparability is not identity

The second precedent is the comparability exercise: assessing whether specified properties remain acceptable across a defined change.

The guidance is explicit that comparability does not mean identical quality attributes. The evidence strategy depends on the change made, the methods available, and how any observed differences relate to the outcomes that matter.

Two warnings carry directly into software.

Routine specifications alone are treated as inadequate on their own for assessing a change. Tests built to catch ordinary variation are not built to catch what a change does, and passing the existing suite is therefore weak evidence about a migration.

And results within acceptance limits can still warrant investigation when they depart from historical trends. A number inside the band that has moved is information, and a gate that only checks the band discards it.

What an average hides

A search service moving to a new retrieval backend keeps its aggregate relevance score. Testing then shows that authorised users can no longer retrieve an entire document class whose availability, permissions, and required behaviour are unchanged.

The average is preserved and a required behaviour is gone. This is the standard shape of a comparability failure in software, and it is invisible to any acceptance rule expressed as a summary statistic.

So the comparison specifies the required properties and the acceptable differences before decisive results are seen, selects tests sensitive to the actual change — preserved behaviours, changed integrations, failure recovery, access boundaries, affected user groups — and retains failed, missing, and ambiguous observations. Apparent improvements get investigated too, since they conceal a changed task or a changed scoring rule as readily as they indicate progress.

The rule

What stays fixed is that acceptance criteria are written before the evidence is gathered, and the recipient produces the evidence. What changes is which properties must be preserved, and that follows from the consequence of losing each one.

Not to be confused with

Statistical equivalence. A non-significant difference is not an acceptance rule. Claiming equivalence or non-inferiority requires a suitable design, justified margins, and uncertainty analysis, none of which follows from a failed significance test.

A regulatory route. These are precedents for structuring evidence. Manufacturing validation, dosage-form controls, cleaning limits, and marketing authorisation do not transplant into software as requirements, and a deliberately redesigned service needs validation against its new objectives rather than comparison alone.