Technology transfer: moving a process into somebody else's building

Inventory what has to travel before deciding how

Build a list covering the product definition, the process description with its parameters and permitted ranges, the tooling and fixtures, the measurement and test methods with their equipment, the material and component specifications with approved sources, the training material, the records format, and the accumulated history of what has gone wrong before. That last item is routinely omitted and is often the most valuable, because a receiving site with the failure history avoids repeating experiments the sending site already paid for. Assign an owner to each entry, because a transfer plan without named people becomes a document that describes work nobody is doing.

Write the process for a stranger, not for yourselves

Existing documentation is almost always written by people who already understand the process, so it records what to do and omits why. A receiving plant needs the reasoning: which parameters may be adjusted and which must not, what each control is protecting against, what an out-of-range condition looks like on the floor, and which apparently arbitrary steps exist because of a specific past failure. Rewriting to that standard is genuine effort and is the single highest-value activity in most transfers. It also exposes the gaps in your own understanding, which is uncomfortable and much better discovered before the process is somebody else's responsibility.

Knowledge moves with people more reliably than with files

Plan for movement in both directions. Send the receiving site's engineers and key operators to watch the process running where it works, ideally long enough to see it misbehave. Send your own people to the receiving plant for the first setups and early runs, and keep them there past the point where everything looks fine. Decide who trains the operators, how competence is judged rather than assumed, and who the receiving team calls at two in the morning during the first month. Transfers that consist of a document handover and a video call almost always cost more in recovery than the travel would have.

The receiving plant is not the sending plant

Equipment differs in make, age, control system and condition. Utilities differ in compressed air quality, water treatment, power stability, humidity and ambient temperature. Materials with the same specification may come from a local supplier whose product behaves differently within the same tolerance band. Handling, storage and even the height of a bench can change an outcome. Identify these differences deliberately at the start, because they explain most of the results that otherwise get blamed on the receiving team's competence. Where a difference cannot be eliminated, agree a compensating adjustment and record it rather than leaving each shift to discover its own workaround.

Proving arrival: comparability rather than conformity alone

Output that meets specification is a necessary result and a weak one, because the sending site may have been running comfortably inside the limits while the new site scrapes them. Compare directly: material from both sources measured by the same method, ideally in the same laboratory, with retained samples kept for later reference, and process data from both sites set side by side. Look at variation and margin, not only pass and fail. Where a product is regulated, the transfer itself is expected to be planned, documented and evaluated as an exercise in its own right, and your regulatory adviser should define what that requires for your market.

Frequently asked questions

When can we shut down the sending site?

Once the receiving plant has produced consistent output across several independent runs, with different operators, at least one material lot change, and any seasonal condition you know affects the process. Keeping the original capability alive costs money and is the only insurance you have, so wind it down in steps rather than switching off on a date. Retain the tooling, documentation and at least one person who ran it until you are confident, because reconstructing a process after the team disperses is far harder than keeping it warm.

What do we do when the process knowledge lives in one person's head?

Treat that person as the transfer, not as a resource for it. Give them the time to run the process while somebody documents what they actually do, including the adjustments they make without mentioning them, and have them supervise the first runs at the receiving site. Filming setups and difficult steps is cheap and unexpectedly useful. Recognise the personal dimension too: an engineer being asked to hand a process to the plant replacing their own is unlikely to volunteer everything unless they are treated properly.

Should we improve the process while transferring it?

Resist it. Transferring and changing at once means that when results differ you cannot tell whether the cause is the new site, the new process, or an interaction between them. Freeze the process, move it, prove it reproduces what the sending site achieved, then open the improvement list with the receiving team, who will by then have their own suggestions. The exception is a change forced by the receiving site's equipment or materials, which should be identified early, treated as a known deviation and validated on its own.