CMC Technology Transfer Document Management

Manage a CMC technology-transfer handoff as a versioned set of connected records, accepted for one named receiving-site task. Identify the source of each record, its exact revision, applicable product and site, supporting batches and unresolved change dependencies. Then have the receiving team reconcile the package before accepting it.

The output of this procedure is an accepted document baseline, a record of any exceptions and a clear boundary on its permitted use. That acceptance is not, by itself, permission to manufacture, proof of successful process or analytical-method transfer, validation approval or authorization for a regulatory change.

This is a tool-neutral documentary procedure published by Assyro. It can inform work in an EDMS or another controlled repository, but it does not describe verified screens or a tested vendor integration. Primary guidance was rechecked on October 6, 2026.

Start with the transfer task and the records you can access

Chemistry, manufacturing and controls knowledge must remain connected to the conditions under which it was generated. A report for one formulation, equipment configuration or analytical-method revision can be informative without demonstrating suitability for the receiving operation.

ICH Q10 describes technology transfer as the movement of product and process knowledge between development and manufacturing or between sites. That knowledge supports the manufacturing process, control strategy and validation approach. The guideline is a pharmaceutical quality-system model used alongside regional requirements, not a prescribed electronic folder structure. ICH Q10, Step 4, June 4, 2008.

Before assembling files, obtain access to the authorized transfer plan, applicable source records, relevant change controls and the people who can explain them. Name a sending-unit document owner, a receiving-unit technical reviewer and the quality and regulatory reviewers required for your scope. You also need a controlled place to store the manifest and receipt decision.

WHO's technology-transfer guidance describes planned responsibilities, documentation and acceptance criteria. Its appendix gives examples of commonly needed records and explicitly leaves the actual requirements to the tasks involved. Use those examples to inform the assessment; do not turn them into a universal statutory packet. WHO TRS 1044, Annex 4, 2022.

For broader project planning, our pharmaceutical technology-transfer guide covers the wider transfer lifecycle. The procedure below addresses the narrower question: what exactly did the receiving team accept as its document basis?

1. Write a bounded handoff statement

Record the product identifier and any strength, dosage form, formulation or presentation needed to distinguish it. Identify the sending and receiving sites, relevant production lines or laboratories, and the operation being transferred. Include the planned scale or batch context where it affects the evidence.

Then write the next permitted task. Examples include preparing a receiving-site protocol, reviewing an equipment gap assessment or assembling evidence for a defined regulatory assessment. Avoid “transfer complete” when the recipient has only received background documents.

A useful statement is: “Baseline TT-042-01 supports Site B laboratory preparation of the analytical-transfer protocol for Product P-042. It does not authorize routine testing at Site B.” The receiving lead can now decide whether each document is sufficient for that task without confusing the decision with a later operational approval.

If the product identity, intended site or next task is ambiguous, stop the package acceptance. Resolve that uncertainty in the transfer scope. Do not select a likely strength or assume that two facilities with similar names are interchangeable.

2. Build the manifest from the required decisions

For each receiving-site decision, identify the evidence needed to make it. A process-adaptation decision may need a controlled instruction, development rationale, equipment comparison and relevant batch history. A laboratory decision may need the analytical procedure, supporting validation information and the agreed transfer strategy. The appropriate set depends on the product and task.

Use the table below as a copyable manifest schema. The field names are suggested working names, not an agency form or a vendor's required data model.

Mark each row required or reference-only for the named handoff. If a requirement is not applicable, document why and identify who accepted that conclusion. Do not remove difficult rows merely to make the manifest appear complete.

The manifest should point to controlled values rather than become a second specification. For instance, link a material specification and revision instead of manually repeating every limit in the index. If a transfer summary must reproduce a parameter, record its source and have the summary checked against that revision.

3. Capture the source baseline and its context

Set a cutoff for the handoff and record the source state at that point. Retrieve the specified records through the authorized process, preserving the version and approval context needed by the recipient. Where the source system remains available, a controlled reference may be appropriate; where it will not, agree the export and retained evidence.

Check more than the visible PDF. Determine which attachments, data tables, linked records and review evidence make the document understandable. A batch summary without a way to identify the underlying batches may leave the recipient unable to investigate an apparent difference.

Keep the source file and any receiving-site adaptation distinguishable. If Site B converts Site A's instruction into a local template, give the adaptation its own identity and record that it derives from the named source revision. New formatting does not make it a new approved process.

A file checksum can help establish that two files have identical bytes, if your transfer process uses one. It cannot establish that those bytes represent the right revision, an approved instruction or an applicable manufacturing condition. Identity and meaning still require reconciliation.

4. Map the dependencies before reviewing completeness

Connect each important conclusion to the record that supports it. For batch evidence, identify the process or method revision used, the site and relevant equipment context. For an analytical report, distinguish the tested samples from the procedure and acceptance criteria used to evaluate them.

Where the receiving site differs, link the gap or change assessment. Record whether the difference affects the proposed local document, the evidence required, the transfer protocol or a regulatory assessment. Do not silently substitute the receiving site's equipment ID into a sending-site report.

Three relationships deserve separate labels:

• Supports: a study or batch record supplies evidence for a conclusion under a stated scope.
• Derived from: a receiving-site draft adapts a particular source revision.
• Requires resolution of: an open change, deviation or knowledge gap prevents the stated next use.

These labels make the handoff more useful to both people and software. A document can be present and readable while its required dependency is still unresolved. A search result or automated completeness check should not promote that record to “ready” merely because a file exists.

5. Reconcile the received records before technical acceptance

Have the receiving document owner compare the incoming records with the manifest. Check identity, revision, state, applicability and required attachments. Then confirm that the technical reviewers can open and interpret the records through their intended access.

Classify the outcome precisely. “Received” means the material arrived. “Reconciled” means it matches the manifest. “Accepted for protocol preparation,” for example, means the responsible reviewer found it adequate for that named task. Local approval and effectiveness remain separate decisions.

If a required record is missing, inaccessible or inconsistent, keep the affected task blocked or unresolved. Record the specific reason and request a correction from the source owner. Preserve the rejected receipt so that the history explains why a replacement was requested.

WHO distinguishes the planned transfer documentation from records of activities performed and the resulting conclusions. Its documentation section describes reporting the actual transfer scope, results, changes and deviations. A receipt log alone cannot stand in for that later execution evidence. WHO TRS 1044 Annex 4, section 7.

6. Exercise the gate with a concrete version mismatch

The following fictional packet is deliberately limited to the source basis for preparing one receiving-laboratory protocol. It is not a complete manufacturing-transfer dossier.

Package TT-042, baseline 01, concerns Product P-042, presentation S1, from Site A laboratory A1 to Site B laboratory B1. The sending and receiving leads have agreed that these four records are required for that preparation task. The sample evidence comes from batches A017 and A018; no receiving-site testing result is yet being claimed.

All four files arrived, but the package fails reconciliation. Revision 5 is not acceptable simply because it is newer. The validation and batch evidence identify revision 4, so the package now contains an unresolved relationship between the method and its support.

The source owner confirms that revision 5 was sent accidentally and that revision 4 remains the authorized basis for this preparation task. The receiver obtains revision 4, verifies its identity and approved state, and repeats the dependency check. With the correct method, accessible supporting records and no unresolved required item, the receiving lead records: “TT-042 baseline 01 accepted for Site B protocol preparation.”

That is the successful endpoint of this exercise. The receiving protocol still requires its own review and approval before use. No method-transfer result, manufacturing release or regulatory authorization has been produced by correcting the file.

If revision 5 was an intentional change, do not use the correction route above. Open the change assessment, establish the evidence needed for the revised method and issue a new baseline when justified. If the product presentation is missing from DAT-042, leave applicability unresolved even when all four revisions match.

For that unresolved case, the receiving technical lead records: “DAT-042 revision 1 received; presentation not established; blocked for TT-042 protocol preparation pending source-owner confirmation.” The closure evidence must establish that the underlying A017/A018 records concern P-042 presentation S1, with a controlled correction or supplement linked to DAT-042. Typing “S1” into the receiving manifest without that source evidence does not close the gap. Retain the original receipt and the correction so another reviewer can reconstruct why the disposition changed.

7. Control changes after the recipient accepts the baseline

An accepted baseline should remain identifiable when the source system changes. Notify the receiving owner of changes that may affect its intended use, and record which package and receiving work products are affected. Do not replace accepted files invisibly in a shared folder.

For a newly approved specification, ask whether it affects a receiving draft, planned samples, material requirements, protocol criteria or existing conclusions. The change assessment should identify affected dependencies and decide whether ongoing work may continue, must pause or needs a revised basis. Preserve the prior baseline and the reason for the transition.

For an approved US NDA or ANDA, a manufacturing-site or other CMC change can require a separate regulatory reporting assessment under the applicable framework. FDA's April 2004 revision of its changes guidance addresses categories and manufacturing changes; it should not be applied indiscriminately to BLAs, investigational products or other jurisdictions. FDA, Changes to an Approved NDA or ANDA.

Link that assessment to the technical handoff rather than treating the packet itself as a submission. Our regulatory impact assessment guide explains the related decision process. A technically coherent packet can still have an unresolved regulatory dependency.

8. Close the handoff with explicit limits and follow-up

Create an acceptance record that identifies the package baseline, receiving task, reviewers, date and supporting reconciliation evidence. List any reference-only limitations and the separate gates that remain. A required unresolved item prevents acceptance for the affected task; an administrative receipt does not override it.

Use this short closeout record:

Process-validation conclusions belong to their own evidence and decision process. FDA's January 2011 guidance describes a lifecycle approach to process validation; a document handoff does not establish successful qualification or continued process performance. FDA process validation guidance.

Finally, assign custody and retrieval responsibility for the accepted baseline and its subsequent history under the applicable record requirements and agreements. Do not invent one retention duration for all transfer records. Confirm that the receiving team can retrieve the accepted material after access changes or the project team disbands.

If your bottleneck is organizing or reviewing the regulatory-document basis for a transfer, discuss that defined workflow with Assyro. Bring the manifest, the intended receiving task and an example dependency problem. Keep technical acceptance, local operational approval and regulatory authorization explicit throughout the handoff.