Design Transfer Is a Controlled Release, Not a Handoff

A device can pass design verification and still fail in routine production.

The drawings may be approved. The validation report may be signed. The bill of materials may be in the manufacturing system. Then the first production build exposes what the transfer package did not capture: a tolerance that cannot be held, an inspection method that produces inconsistent results, a supplier specification that omits a critical feature, or an assembly decision that exists only in the memory of one engineer.

These are often described as manufacturing problems. Many begin earlier, when design transfer is treated as a handoff instead of a controlled release.

Under FDA's Quality Management System Regulation, ISO 13485:2016 provides the foundation for medical device design and development requirements. FDA's training on Clause 7.3.8 states that manufacturers should document procedures for transferring outputs to manufacturing, verify that those outputs are suitable before they become final production specifications, and confirm that production capability can meet device requirements.

That last point changes the nature of the work. Design transfer is not complete because manufacturing received the documents. It is complete when the organization has evidence that the released design can be made, inspected, accepted, packaged, labeled, and supported as intended.

The transfer is where product knowledge becomes production behavior

Design outputs describe what the device must be. Production controls determine what the organization will repeatedly make.

Transfer connects the two.

The FDA-hosted MDSAP Audit Approach directs auditors to compare approved design outputs with significant elements of manufacturing, supplied products, and established process tolerances. It also connects transfer with process validation, production controls, acceptance activities, equipment, environmental controls, personnel, and supplier controls.

That is a broader test than asking whether the device master record is complete. The practical question is whether production decisions preserve the design intent and risk controls embedded in the approved outputs.

For an essential output, the transfer trail should answer:

• Where does this requirement appear in the production specification?
• Which operation or supplier controls it?
• How will conformity be measured?
• What acceptance criterion applies?
• Who has authority to release or reject the result?
• What record proves that the control worked?
• What happens if the process or supplied component changes?

If the team cannot follow that chain, the design may be approved while its production implementation remains uncertain.

Start transfer before design freeze

Waiting until the final design review creates avoidable pressure. Manufacturing receives a large package at the point when changes are expensive, launch dates are close, and project teams are less willing to reopen an assumption.

Design transfer can begin earlier. The MDSAP audit model says transfer may start before validation and continue as design and development evolves, followed by a final transfer that closes the development process.

Early involvement gives manufacturing, supplier quality, operations, and service teams a chance to test whether emerging outputs can become practical production controls. They can identify tooling constraints, inspection limitations, process risks, material availability, training needs, or supplier questions while the design still has room to respond.

This does not mean releasing an unfinished design to production. It means treating manufacturability and controllability as design questions instead of problems reserved for the launch team.

A transfer plan should identify staged activities, responsible functions, required evidence, decision points, and the conditions for final release. It should also define how preliminary production information is controlled so draft instructions or files cannot be mistaken for approved specifications.

Define what is being released

A design-transfer package is more than a drawing set. Its content depends on the device and manufacturing model, but the release basis normally spans several connected areas.

Product and process specifications

The product definition may include drawings, component specifications, formulations, bills of materials, software or firmware configurations, workmanship criteria, packaging specifications, labeling, and service requirements.

The process definition may include manufacturing instructions, tooling, fixtures, equipment settings, environmental controls, in-process controls, acceptance methods, sampling plans, calibration requirements, maintenance needs, and validated-process parameters.

The transfer review should confirm that these records agree. A critical dimension in the drawing is not controlled if the work instruction uses a different nominal value or the inspection method cannot reliably measure the tolerance.

Configuration matters as well. The released software build, programmable file, labeling version, component revision, and manufacturing instruction must describe the same device. A correct document in the wrong product configuration is still a transfer failure.

Risk controls and acceptance activities

Risk controls should survive translation into production.

If a risk control depends on material identity, torque, cleanliness, seal strength, software configuration, sterilization exposure, alarm behavior, or a supplier-managed characteristic, the production system needs a corresponding control and record.

Acceptance activities should reflect the significance of the output. High-risk or essential outputs deserve inspection, monitoring, or process controls capable of detecting a meaningful failure. The team should also confirm that acceptance criteria were approved before use and that the method is suitable for the measurement being made.

The goal is not to inspect quality into the product. It is to show that the production process, its controls, and its acceptance activities collectively preserve the approved design.

Suppliers, software, labeling, and competence

Transfer reaches beyond the factory floor.

Supplier requirements must identify the characteristics and records needed from the external provider. Quality agreements, purchase specifications, change-notification terms, certificates, incoming acceptance, and supplier validation evidence should align with the risks of the supplied product or process.

The same discipline applies to software used in the device or to control production. Released versions, access, configuration, backups, validation, and change authority need clear ownership. IntelaSolve's article on computer software assurance provides additional context for risk-based assurance of software used within the quality system.

Labeling and packaging are part of the released product definition, not launch materials to be reconciled after production starts. Training must also move beyond attendance. Operators, inspectors, technicians, and release personnel need the competence to perform the assigned process and recognize unacceptable results.

Prove production capability, not document completion

A transfer checklist can show that required records exist. It cannot, by itself, show that production can meet the device requirements.

Use production-representative builds to test the transfer. The evidence should demonstrate that the actual or intended production environment, equipment, tooling, materials, suppliers, personnel, software, methods, and controls can produce conforming results.

The scope depends on risk and process. It may include:

• process qualification or validation;
• manufacturing feasibility runs;
• inspection-method qualification;
• packaging or sterilization validation;
• supplier first-article or capability evidence;
• yield and nonconformance review;
• configuration verification;
• line-clearance and labeling controls;
• training and observed competence; and
• confirmation that transferred units are representative of those used in applicable validation work.

Review unexpected results as information about the transfer, not as noise standing between the team and launch. A repeated adjustment, undocumented workaround, high scrap condition, or dependence on engineering support may show that the process is not ready for routine release.

The design can be technically correct while production capability remains incomplete.

Put unresolved work under explicit control

Few transfers close with every desirable improvement finished. The problem is not the existence of open work. The problem is allowing open work to disappear inside meeting minutes, email, or a launch-risk spreadsheet with no controlled relationship to product release.

Classify each open item. Determine whether it blocks release, permits a limited release under defined controls, or can move into an approved post-transfer action. Record the rationale, risk assessment, interim control, owner, due date, and approval authority.

Avoid using temporary instructions as permanent production knowledge. If an interim control is necessary, issue it through the document and change system, train the affected personnel, and define when it expires.

After final transfer, changes to the device or production process should enter the established change-control process. The change assessment needs to consider the released design, risk management, verification or validation, regulatory status, suppliers, labeling, and existing inventory.

A release decision loses its value if the configuration changes the next day without the same cross-functional visibility.

Contract manufacturing does not transfer accountability

The handoff risk grows when design and production sit in different organizations.

A contract manufacturer may have had little involvement in development and may not know why a particular tolerance, material, inspection, or process limit matters. Sending the approved drawing does not transmit the risk analysis behind it.

The legal manufacturer needs evidence that the contract manufacturer can meet the specified requirements and operate the necessary controls. That includes clear technical and quality agreements, approved specifications, validation responsibilities, change-notification rules, access to records, nonconformance escalation, and agreement on release authority.

The related article on supplier monitoring under QMSR explains why initial qualification does not replace ongoing performance oversight. Design transfer establishes the production relationship. Supplier monitoring shows whether it continues to work.

Keep the release decision connected

Design transfer brings together records that are often owned by different systems and functions: design outputs, risk controls, supplier evidence, process validation, production specifications, training, labeling, regulatory commitments, nonconformances, and approvals.

When these records remain disconnected, the final review becomes a document hunt. Reviewers see completion dates but struggle to determine whether the same device configuration and the same critical requirements are represented across every record.

Connected compliance infrastructure allows the release decision to be built around the product. An essential design output can remain linked to its risk, manufacturing control, supplier requirement, acceptance method, validation evidence, approved configuration, and later change.

IntelaSolve's project-verified medical-device compliance platform is designed around that lifecycle relationship across R&D, design controls, risk management, quality, regulatory work, manufacturing and operations, and postmarket evidence. It does not replace the people who approve design transfer. It helps them review one controlled evidence chain instead of reconstructing the release from separate applications.

That traceability also strengthens QMSR inspection readiness. An auditor should be able to move from an approved design output to the production control and record that preserve it without relying on tribal knowledge.

Questions for the final transfer review

Before authorizing routine production, ask:

1. Is the released product configuration unambiguous across hardware, software, labeling, packaging, and specifications?
2. Have essential design outputs and risk controls been translated into effective production and supplier controls?
3. Can production and inspection methods repeatedly meet the approved requirements?
4. Are required validations complete for the released configuration, equipment, materials, and environment?
5. Are operators, inspectors, technical personnel, and release authorities competent for their assigned work?
6. Are deviations, unresolved items, and temporary controls visible, risk-assessed, approved, and time-bound?
7. Can the team retrieve the records supporting the release decision without rebuilding the story from email?
8. Is the post-transfer change path active for the first production issue or improvement?

A "yes" to document completion is not enough. The release decision should show that the production system can preserve the device the design team intended.