Design transfer: where good documentation actually earns its keep

What design transfer is

Design transfer is the formal handoff from "we have a validated design" to "someone else can build it correctly, repeatably, without the original design team in the room." For a regulated product, it's also a defined step in the design control process, referenced directly in frameworks like 21 CFR 820.30(h) and ISO 13485, which require that design outputs be verified as adequate for production before routine manufacturing begins.

In practice, design transfer covers more than shipping a folder of files. The BOM, schematics, layout, assembly drawings, and test procedures all need to travel, but so does the information that rarely makes it into a formal document: why a tolerance is tighter than it looks like it needs to be, why a specific supplier was chosen for one component over an equivalent, what almost went wrong during bring-up and how it was resolved. A transfer that only moves the paperwork and not that context tends to surface its gaps at the worst possible time, mid-production, not during review.

Design transfer happens more than once in a typical product's life: from R&D to a pilot line, from pilot to volume production, and again whenever a program moves between contract manufacturers or a supplier changes hands. Each of those transitions carries the same risk, and each deserves the same discipline, not just the first one.

What belongs in a transfer package

• Current-revision BOM, with approved alternates and their qualification status noted, not just the primary part number
• Schematics and PCB layout source files, not just PDFs, so the receiving team can actually work with them if a change is needed later
• Assembly drawings and work instructions, including any hand-assembly or rework steps that aren't obvious from the layout alone
• Test procedures and acceptance criteria, with enough detail that a different team could actually execute them, not just a summary of what's tested
• The design history file or equivalent: verification and validation records, DFMEA and PFMEA if they exist, and any deviation or known-issue log from the sending team's build experience
• Contact access to the original design team for a defined transition period, since some questions only surface once the receiving team starts building

The transfer process

1. Package assemblyThe sending team compiles the full package above, explicitly flagging any known open issues, deviations, or "this works but we're not sure why" items rather than presenting the design as more settled than it is.
2. Receiving team reviewThe team taking on the build reviews the package independently and generates questions before touching real hardware. This step is where the sending team's assumptions get tested by someone who wasn't in the room when they were made.
3. First article buildA build under the receiving team's actual process and equipment, not the original team's bench setup, is the first real test of whether the documentation is complete. Every gap that shows up here would otherwise show up in production.
4. Gap resolutionFindings from the first article build get resolved and fed back into the documentation itself, not just handled verbally and left undocumented for the next person who runs into the same question.
5. Process qualificationOnce the build is repeatable and correct, the receiving process moves into formal qualification (see our note on IQ/OQ/PQ), confirming it holds up across multiple lots and operators, not just the one closely-watched first article.
6. Sign-off and transitionFormal acceptance of the transfer, with a defined, time-limited window where the sending team remains available for questions rather than the relationship ending the moment the package is delivered.

Worked example: a substitution that didn't make it into the transfer

This is a common shape for design transfer failures: nothing was hidden on purpose, the information simply lived in a person's memory instead of a document. A transfer process that treats "why did we choose this" as a real question, not just "what did we choose," catches this class of issue before it reaches a customer.

Common design transfer mistakes

• Transferring files, not context. The BOM and drawings are necessary but not sufficient; the reasoning behind non-obvious decisions needs to travel too.
• Skipping a real first article build. Reviewing documentation on paper doesn't surface the same gaps that an actual build under the new process does.
• Treating the sending team as available indefinitely, or not at all. Neither extreme works well; a defined transition window with real availability gets the best of both.
• Not updating the source documentation after gaps are found. If gap resolution happens verbally and doesn't make it back into the package, the next transfer, or the next new hire, hits the same gap again.

Frequently asked questions