Technology Transfer × Knowledge Management
A technology transfer is the moment a site discovers what it actually captured. You can only move knowledge that was made explicit — so transfer is the acid test of knowledge management, and the batch record is the easy half.
What this page does not claim
An intersection covers what happens only where two axes overlap. It does not restate what either parent page says, and it is not a substitute for reading them.
WHAT ONLY EXISTS IN THE OVERLAP
- Transfer is the audit of what was never written down. A process runs on documented parameters and on undocumented know-how, and the second only becomes visible when someone who does not have it tries to run the process — which is precisely a transfer. The gap surfaces at the receiving site or not at all.
- The transferable object is rationale, not procedure. Handing over a batch record moves the steps; it does not move why each parameter has its value, its range, and its criticality — and without the why, the receiving site cannot judge a deviation or defend a change. ICH Q10 names knowledge management as the enabler for exactly this.
- Established conditions cannot be classified without the development knowledge. ICH Q12 makes some parameters regulatory commitments and others manageable in the quality system, and the evidence that sorts them lives in the development history — so that history has to transfer, or the receiving site inherits a process it cannot lawfully change.
- The knowledge decays on a human timescale. People retire, teams reorganise, and tacit process understanding leaves with them; the transfer window is often the last moment that undocumented knowledge can be forced into explicit form before it is simply gone, which makes transfer a knowledge-preservation event, not only a logistics one.
- Process validation at the receiving site consumes the transferred knowledge as its input. EU GMP Annex 15 process performance qualification proves the process works where it now lives — but the acceptance criteria, worst cases, and control strategy it validates against are only sound if the sending site's knowledge came with the process.
Transfer is the audit of what you captured
Every established process carries two bodies of knowledge. One is explicit: the master batch record, the specifications, the validation reports, the parameter ranges. The other is tacit — the operator who knows the granulation looks right at a particular torque, the engineer who warms a jacket before charging because a cold vessel once caused a problem nobody formally traced, the shift lead who reads an early sign of a stalling reaction that no alarm captures. While the process stays where it was developed, the tacit layer is invisible, because the people who hold it are present and simply apply it. A technology transfer removes that assumption. It asks a different site, with different people and equipment, to reproduce the outcome using only what was written down — and everything the sending site knew but never externalised now shows up as a failed batch, an out-of-trend result, or a question the receiving team cannot answer from the documents.
That is what makes transfer the honest test of a knowledge-management system rather than a shipping exercise. A site with mature knowledge management has already converted much of its tacit understanding into explicit, transferable form — development reports that record why parameters were set where they were, a documented control strategy, and a captured history of what failed and why during development and scale-up. A site without it discovers its gaps the expensive way, at another facility, under a timeline, with a regulator eventually asking why the transferred process behaves differently from the original. The failure is almost never in the parameters that were transferred; it is in the knowledge that was assumed, never written, and therefore never sent.
The control strategy is the transfer object
Naive transfer copies the procedure: here are the steps, the setpoints, the tests, reproduce them. It routinely under-delivers because a procedure is the conclusion of a reasoning process without the reasoning. The object that actually has to move is the control strategy — the set of controls derived from product and process understanding that assures performance and quality, together with the rationale for each: why this parameter is critical and that one is not, why the range is what it is, which attributes it protects, and what happens at the edges. ICH Q10 places knowledge management alongside quality risk management as the two enablers of the pharmaceutical quality system precisely so that this understanding is managed as an asset across the lifecycle rather than living in the heads of the development team. Transfer is where that asset is either drawn down or found to be missing.
The practical test comes the first time the receiving site hits a deviation. A site that received only the procedure can tell that a parameter went out of range but cannot judge whether the batch is affected, because it does not hold the rationale that says what the range protects and how much margin exists beyond it — so it either scraps sound product or, worse, releases compromised product, and in both cases it cannot investigate to a real root cause. A site that received the control strategy can reason: this attribute is what the parameter guards, here is the relationship, here is the evidence, and here is why this excursion does or does not matter. The difference is not documentation volume; it is whether the knowledge that lets a process be governed came with the process. 21 CFR 211 requires the receiving site's master production record to reflect a properly established process, and a record built on transferred steps without transferred understanding meets the letter while missing the point.
Established conditions and the lifecycle boundary
ICH Q12 sharpened what a transfer has to carry by formalising established conditions — the elements of a process that are regulatory commitments, changeable only through a defined regulatory route, as distinct from the details a firm may manage within its own quality system. The classification of a given parameter into one bucket or the other is not arbitrary; it rests on the development knowledge that shows how much that parameter matters to product quality. When a process transfers, the classification has to transfer with it, and so does the evidence behind it — because a receiving site that does not know which parameters are established conditions is a site that cannot safely make changes at all. It will either freeze the process against improvements it is entitled to make, or alter a committed condition without recognising it needs a regulatory filing, and both are foreseeable consequences of a transfer that moved the process but not the knowledge that governs its change.
This is where the intersection reaches furthest into the lifecycle. ICH Q12's tools — the established-conditions concept and the post-approval change management protocol — only function if the receiving site inherits the product and process understanding that justified them, which means the transfer package has to include the development rationale, not just the current state. A well-run transfer therefore treats the sending site's knowledge as a regulated deliverable: the control strategy, the criticality assessments, the change history, and the basis for each established condition, handed over as the foundation the receiving site's future change management will stand on. A transfer that omits it leaves the receiving site technically operating the process but epistemically unable to steward it — compliant today and unable to change safely tomorrow.
Validating the received process
The transfer is proven, in GMP terms, by process performance qualification at the receiving site under EU GMP Annex 15 — batches manufactured under the intended commercial conditions, demonstrating that the process reproducibly yields product meeting its predetermined criteria in its new home. What is easy to miss is that PPQ does not validate the process in the abstract; it validates it against acceptance criteria, worst cases, and a control strategy that all originate in the sending site's knowledge. If that knowledge transferred faithfully, the PPQ tests the right things at the right limits and a pass means something. If it did not, the receiving site can run a technically clean qualification against criteria that quietly omit the parameter that actually mattered, and produce a validated process that is validated against an incomplete understanding — the most dangerous outcome, because it carries a signature.
The knowledge-preservation dimension gives the transfer window its urgency. Development teams disperse, scale-up engineers move on, and the tacit understanding that a mature transfer depends on has a shelf life measured in the tenure of the people who hold it. A transfer that happens years after development, at a site whose originators have moved on, is often working from a knowledge base that has already partially evaporated — which is why leading organisations treat the moment of transfer as a forcing function to externalise tacit knowledge while its holders are still reachable, capturing the why alongside the what before it is unrecoverable. Done that way, the transfer strengthens the knowledge-management system by converting private expertise into an organisational asset; done as a document handoff, it merely relocates the process and lets the understanding leak away.
Derived from the 4 standards SPEQ maps to this intersection, across 3 regulatory bodies: FDA, EMA, ICH.
FREQUENTLY ASKED
Why do technology transfers fail even when all the documents are handed over?
Because a process runs on more than its documents. The explicit layer — batch records, specifications, validation reports — transfers easily, but a working process also depends on tacit know-how: the operator judgement, the informal adjustments, and the undocumented reasons behind steps that were never traced to a formal record. That layer is invisible while the process stays with the people who hold it, and it surfaces only when a different site tries to run the process from the documents alone. The transfer then exposes exactly what was assumed and never written. Most transfer failures are not in the parameters that were sent; they are in the knowledge that was presumed obvious, left implicit, and therefore never made it into the package. This is why transfer is the true test of a knowledge-management system.
What does ICH Q10 mean by knowledge management as an enabler?
ICH Q10 names knowledge management, alongside quality risk management, as one of two enablers of the pharmaceutical quality system — meaning product and process knowledge is to be treated as a managed asset acquired, analysed, stored, and transferred across the whole lifecycle, not left to accumulate informally in individuals and teams. The practical force of that idea shows up most sharply at technology transfer, which is the point where knowledge has to move between organisations or sites. A site that has genuinely managed its knowledge can draw the control strategy, the development rationale, and the failure history out of its system and hand them over. A site that has not finds those things scattered, partial, or resident only in people who may no longer be available, and the transfer becomes a recovery operation rather than a handover.
How does ICH Q12 relate to technology transfer?
ICH Q12 introduced established conditions — the elements of a process that are regulatory commitments and can only be changed through a defined regulatory route, as opposed to details a firm manages within its own quality system. Sorting a parameter into one category or the other depends on the development knowledge showing how much it affects product quality, so that knowledge has to travel with the process during a transfer. A receiving site that does not know which parameters are established conditions cannot make changes safely: it will either freeze improvements it is entitled to make or alter a committed condition without filing. So Q12 raises the stakes of transfer — the package must carry not only the current process but the rationale that classifies its parameters, or the receiving site inherits a process it cannot lawfully steward.
What knowledge must a sending site transfer beyond the batch record?
The rationale, not just the recipe. The batch record moves the steps and setpoints; what also has to move is the control strategy and the understanding behind it — why each parameter has its value and range, which quality attribute it protects, how critical it is, and what the evidence for that criticality is. Alongside it should travel the development and scale-up history, including what failed and why, and the basis for each established condition so the receiving site can manage change lawfully. This is the knowledge that lets the receiving site judge a deviation, investigate to a real root cause, and defend a change. Transferring only the procedure leaves the receiving site able to run the process but unable to govern it, which is the difference between operating and stewarding.