Tech Transfer to a CDMO: The Digital Playbook

Tech Transfer Is an Information Architecture Problem

Ask a process engineer what a technology transfer is and you will get an answer about scale, equipment trains, mixing dynamics, and comparability. Ask a regulatory lead and you will get an answer about variations, site additions, and the timing of submissions. Both answers are right. Neither one explains why transfers that were technically sound still produce two years of avoidable deviations at the receiving site.

The World Health Organization’s guideline on technology transfer, published as Annex 4 to Technical Report Series 1044, breaks a transfer project into four phases: project initiation, project planning, project transfer execution, and project review and close-out.¹ Read the guideline closely and something becomes obvious. Almost every requirement in it is a requirement about information. The gap analysis is an information exercise. The control strategy is an information artifact. The list in the guideline’s appendix, titled “Documentation commonly required for technology transfer,” runs to eleven separate aspects, each with its own set of records, from regulatory process descriptions through to the history of changes and change management.¹

The accountability does not transfer

Under 21 CFR 211.22, the quality control unit has the responsibility and authority to approve or reject drug products and to review production records.¹² Outsourcing manufacture does not create an exception. FDA’s guidance on contract manufacturing arrangements is explicit that a quality agreement defines and documents which party performs which activity, and that it does not shift the underlying obligation to comply with current good manufacturing practice.⁹ In an April 2026 warning letter to a contract facility, the agency restated the position directly: contractors are extensions of the manufacturer, and a contract facility is responsible for the quality of the drugs it produces regardless of the agreements in place with product owners.¹⁰ Trade press coverage of contract manufacturing enforcement through 2026 has made the same point about the sponsor side of the relationship.²²

So the sponsor keeps the accountability and gives up the direct line of sight. That is the structural tension in every CDMO relationship, and it is resolved, or not resolved, by how information flows. A sponsor that receives a monthly summary spreadsheet has a different regulatory position from a sponsor that can open the executed batch record and read the audit trail. Both may have signed the same quality agreement.

Why the framing matters in practice

When a transfer is framed as a document exchange, the project plan tracks documents. Teams count how many of the ninety-four items in the transfer package have been sent and acknowledged. Completion is measured by transmission. Nobody asks where the parameter values in document forty-one ended up, who typed them into the receiving site’s manufacturing execution system, whether anyone checked the typing, or what happens the next time the sponsor changes one of them.

When a transfer is framed as a data project, the plan tracks data. Each item has a source, a destination system, a format, a verification step, and a named owner on both sides after go-live. Completion means the value is correct in the system where operators will actually see it, and that there is a defined path for changing it. Those are different projects with different failure modes, and the second one is the one that determines whether the product runs well in year three.

Build the Transfer as a Data Inventory, Not a Document List

The first change we recommend is small to describe and difficult to do: build the transfer package as an inventory of data, and derive the documents from it, rather than assembling documents and hoping the data is in there somewhere.

The six domains that actually move

Across small molecule and biologics transfers, the information that has to reach the receiving site sorts into six domains. Most transfer packages contain all six, but scattered across dozens of documents in ways that make it hard to see what is missing.

One: the process description and parameter set, with criticality classification. This is the unit operation sequence, the equipment requirements, the setpoints, the proven acceptable ranges, and the classification of each parameter as critical or not critical, together with the in-process controls and their limits. ICH Q11 describes how process understanding and the identification of critical process parameters are developed and justified for drug substances, and this is the material that has to travel.⁵ The classification matters more than the number. A setpoint without a criticality flag is an invitation for the receiving site to treat it as a preference.

Two: analytical procedures and their validation packages. Not just the test method text, but the validation report, the system suitability criteria, the reference standards and their certificates, the instrument configuration used during validation, and the known behavior of the method at the edges. ICH Q14 and the revised ICH Q2(R2) together define what development and validation information exists for a procedure across its lifecycle, and both assume that this material is available to whoever operates the method next.⁶⁷

Three: specifications and their justification. A specification limit is a number. The justification is a story about clinical experience, stability behavior, process capability, and regulatory commitment. Sending the number without the story guarantees that the first out-of-specification investigation at the receiving site starts from zero.

Four: raw material and component specifications, with approved suppliers. The WHO guideline is direct that the specifications and critical material attributes of starting materials used at the receiving unit should be consistent with those used at the sending unit unless a change is planned and assessed.¹ In practice this domain is where transfers quietly diverge, because the receiving site has existing supplier relationships and its own material master records, and a “functionally equivalent” excipient grade is a substitution that nobody logged as a change.

Five: stability protocols and existing data. The protocol, the storage conditions, the pull schedule, the analytical procedures used for stability, the historical data set, and the commitment stability that the receiving site will now have to run. The WHO guideline places the start and continuation of stability studies squarely in the review and close-out phase, which is the right place for it but also the phase where projects are already declaring victory.¹

Six: the change history. Every change made to the process, the methods, and the specifications since development, with the reason for each one. This is listed in the WHO appendix under “History of changes and change management.”¹ It is the domain most often omitted, and the one we treat as the highest value item in the whole package. The next section explains why.

What an inventory looks like

The practical form is a table with one row per data item, not per document. It is longer than a document list and considerably more useful, because it forces the two conversations that document lists let people avoid: where does this land, and who owns it afterward.

The two questions the inventory forces

The destination column is the one that changes behavior. Writing “MES master recipe” next to a parameter set means someone has to say how those values will get into the master recipe, who will verify them, and what the verification record looks like. Writing “LIMS specification tables” next to a set of limits means someone has to reconcile the sponsor’s specification numbering with the receiving site’s. These are unglamorous questions and they are almost never asked in a technical transfer meeting, because they belong to nobody in the room.

The ownership column is the one that survives the project. Peer-reviewed work on biopharmaceutical technology transfer has repeatedly identified information gaps and misaligned expectations between sending and receiving units as recurring causes of difficulty, rather than any single technical failure.¹⁵ An ownership column converts a vague expectation into a name.

The Change History Is the Item Most Often Left Behind

Of the six domains, the change history is the one that is routinely dropped, and it is the one we would protect first.

Why it gets dropped

The change history is inconvenient to assemble. It lives across development reports, change control records, deviation investigations, meeting minutes, and the memory of people who may have left. It has no single owner. It is not requested by any regulatory filing in the form that would make it useful. And it makes the sending organization look worse than a clean summary would, because it shows the wrong turns as well as the right ones. So it is summarized into a paragraph, or it is left out, and what arrives at the receiving site is the current state of the process with no explanation of how it got there.

Why it is the most valuable item you can send

A receiving site that does not know why a parameter is set where it is will eventually change it. Not out of carelessness. Out of ordinary engineering judgment. A hold time of four hours looks conservative when the equipment is available for six. A mixing speed looks like it could come down to reduce shear. A filtration step looks like it could be consolidated. Each of these is a reasonable proposal from a competent engineer who does not know that the four-hour hold exists because a degradant appeared at six hours in a development study that never made it into the filing.

The literature on knowledge management in the pharmaceutical quality system has been making this argument for years. Work published in the PDA Journal on knowledge management as a quality system enabler frames enhanced knowledge transfer as the mechanism that connects the lifecycle expectations of ICH Q10 to the lifecycle management tools of ICH Q12, and notes that knowledge management remains immature relative to those expectations.¹⁶ A review of knowledge management in biopharmaceutical development and lifecycle management reaches a similar conclusion about the gap between the stated importance of process knowledge and the practical systems for holding it.¹⁷ FDA’s adoption of ICH Q10 puts knowledge management in the position of an enabler across the whole product lifecycle, including the technology transfer stage itself.³

How to send it in a form that gets used

A narrative document titled “process history” will be filed and never opened. What gets used is a change history attached to the parameters themselves, so that anyone looking at the parameter sees the history in the same view. That means a structured record with, at minimum, the parameter or method affected, the previous value, the new value, the date, the reason, the supporting study or investigation reference, and the regulatory status of the change.

ICH Q12 provides the vocabulary that makes this workable in a regulatory sense. The concept of established conditions distinguishes the elements of a process that are legally binding commitments from the supporting information that can be managed within the pharmaceutical quality system, and the guideline’s annexes work through how those elements are identified and categorized.⁴ An ISPE case study on lifecycle management under Q12 illustrates how a company applied that categorization in practice.¹⁴ For a transfer, the practical benefit is that the change history can be sorted into changes that would require regulatory action and changes that would not, which tells the receiving site exactly how much room it has before a proposal becomes a submission.

Extend it, do not close it

The change history is not a package item that gets delivered once. From the day the receiving site starts making changes, it is generating new entries. If those entries live only in the CDMO’s change control system, the sponsor’s institutional knowledge stops at the transfer date, and the next transfer, to a second site or back in house, starts from a package that is progressively less true. The obligation to feed the sponsor’s change history should be written into the agreement, and someone at the sponsor should be accountable for maintaining it.

The Format Problem: Documents In, Re-Keying Out

Now to the part of the transfer that almost nobody designs, and that quietly generates risk on every project.

What actually happens to a transfer package

Transfer packages are assembled as documents. Word files, PDFs, spreadsheets, scanned batch records, presentation decks from the technical meetings. They are sent through a portal or a secure file transfer, acknowledged, and indexed. Then the receiving site has to make its systems run the process, and its systems do not read PDFs.

So people re-key. A process engineer opens the parameter table in the transfer package on one screen and the MES recipe builder on the other, and types. A quality control analyst opens the method document and configures the chromatography data system by hand. Someone builds the specification tables in LIMS from a specification document. Someone creates the material master records in ERP from a component specification. On a moderately complex product this is hundreds of individual values, each of which is a transcription event in a dataset that is GMP-critical by definition, because those values will control the manufacture and testing of product for patients.

The industry has been describing this problem in its own trade literature for years. Coverage of digital technology transfer has noted the extent to which required information is manually extracted and re-entered into new production systems, and the time and effort spent reconciling different items and data structures between organizations.²⁰ Practitioner accounts of what makes transfers succeed keep returning to the completeness and usability of the transferred information rather than to the science.¹⁹

What structured transfer would look like

The alternative is to move the data in a form that a system can consume without a human retyping it. There are three layers where this is technically achievable today.

Be honest about how common this is

It is not common. The great majority of transfers between a sponsor and a CDMO in 2026 still move as documents, and the parameters still get typed. There are good reasons for that, and pretending otherwise does not help anyone plan.

The systems on the two sides are different, and often from different vendors with different data models. The sponsor may not have its own parameter set in structured form to begin with, because it lives in development reports rather than in a system. The standards that exist are strong in narrow areas and absent in others: batch control has a mature model, analytical data has an active one, and there is no widely adopted standard for exchanging a full product transfer package. Building a structured exchange for a single product is hard to justify. Building one across a portfolio is a program, not a project.

What is realistic, and worth doing now, is narrower.

• Make the parameter set structured on the sponsor side first. Even if the CDMO receives a PDF, holding the authoritative parameter set as structured data inside the sponsor’s own system means every future transfer, every regulatory question, and every change assessment starts from one source instead of a document search.
• Deliver a machine-readable companion file alongside the document package. A defined spreadsheet or structured file with one row per parameter, including criticality and range, does not require either party to change systems and removes most of the ambiguity that makes re-keying dangerous.
• Verify at the destination, not at the source. The meaningful control is a documented check that the value in the receiving site’s MES or LIMS matches the sponsor’s authoritative record, performed after configuration and repeated after every change. This is a small amount of work with a large effect, and it is frequently missing.
• Require the analytical data itself, not just the reports. For method transfer, ask for the underlying result data in a form your systems can read, not a PDF of a summary table. This becomes the basis for any later comparison.

The Systems Boundary: Who Sees What, and When

The transfer package is a one-time flow. The systems boundary is permanent, and it decides whether the sponsor’s oversight is real or nominal.

The four questions that define the boundary

Which sponsor systems does the CDMO get access to? Usually a document management system, so the CDMO can pull controlled specifications and methods. Sometimes a quality management system, so deviations and change requests can be raised in one place. Occasionally a data platform, so the CDMO can post batch results directly. Each grant is a validation and access-control question, and each one avoided means a manual handoff somewhere.

How does batch data come back? The range runs from a PDF batch record package emailed after disposition, through a structured data file per batch, to direct read access into the CDMO’s manufacturing execution system. Where a sponsor sits on that range determines what kind of trending it can do at all.

Can the sponsor see the batch record while the batch is running, or only afterward? This is the question that separates oversight from audit. Near real time visibility means the sponsor’s person on the program can see a step that is trending toward a limit and pick up the phone. Visibility after the fact means the sponsor learns about it during batch record review, when the only remaining options are disposition decisions.

How are deviations visible? Notification within a defined number of hours for defined categories is standard practice in quality agreements. What is far less common, and far more useful, is the sponsor being able to see the deviation record itself, including the investigation as it develops, rather than a notification followed by a closed report weeks later.

Why summary reports are not enough

Both PIC/S and MHRA have made the same observation about outsourced data, and it is the most useful single point in the data integrity guidance for anyone designing a CDMO relationship. The PIC/S guidance on good practices for data management and integrity, PI 041-1, addresses data integrity considerations for outsourced activities and notes that summary reports supplied by contract facilities are limited, because the supporting data and associated metadata are typically not included and the original data cannot be reviewed.¹¹ The guidance also expects the contract giver to review the contract acceptor’s data management arrangements, at a frequency set by risk.

That is a precise statement of the problem. A sponsor that receives only summary reports has accepted the contract acceptor’s conclusions without the ability to test them. That may be an acceptable risk position for a low-risk product with a mature partner. It should be a conscious decision, documented as such, rather than the accidental result of nobody having asked for anything more during transfer.

Analytical Method Transfer as a Data Exchange

Analytical method transfer deserves separate treatment, because it is the part of a transfer most likely to fail visibly, and because it is fundamentally an exercise in generating and comparing two sets of data.

The recognized approaches

The United States Pharmacopeia general chapter on transfer of analytical procedures describes the transfer as the documented process that qualifies a receiving laboratory to use a procedure that originated elsewhere, and sets out the recognized approaches: comparative testing, co-validation between laboratories, revalidation, and, in defined circumstances, a transfer waiver.⁸ The WHO guideline uses a similar set, naming confirmation testing, comparability testing between sending and receiving units, co-validation, and paper-based knowledge transfer, and requires that the choice be risk-based and scientifically justifiable.¹

Comparative testing is the most common approach for a CDMO transfer: both laboratories test samples from the same lot, and the results are compared against criteria agreed in advance. That single sentence hides the two things that go wrong. The criteria have to be set before anyone runs anything, and the data being compared has to be genuinely comparable.

What has to be exchanged

The WHO guideline sets out the responsibilities of each side in useful detail. The sending unit is expected to define the procedures to be transferred, define the experimental design, sampling methods, and acceptance criteria, provide validation reports including evidence of the method’s ruggedness, provide details of the equipment used and any standard test samples, provide the approved test procedures, offer method-specific training, and review and approve the transfer report. The receiving unit is expected to review the procedures and formally agree the acceptance criteria before execution, ensure the necessary equipment is available and qualified and meets the specifications the procedure requires, ensure trained personnel are in place, provide a documentation system capable of recording receipt and testing of samples and reporting and collating the data, execute the protocol, perform the appropriate level of validation or verification, and generate and obtain approval of the transfer report.¹

Read that list as a data specification rather than a task list and the exchange becomes concrete.

The failure everyone has seen

The method is valid. The receiving laboratory is competent. The instruments are qualified. And the method still performs differently, because instruments are not interchangeable. Practitioner guidance on chromatographic method transfer consistently identifies differences in system volume, detector cell characteristics, thermal behavior, and column-to-column variability as the sources of disagreement between two laboratories running what is nominally the same procedure. The consequence is a peak that co-elutes on one system and resolves on the other, or a retention time shift that pushes an early-eluting impurity into the solvent front.

None of that is a data problem in origin. It becomes a data problem in resolution, because working out which of those explanations applies requires both laboratories to compare instrument configuration data and raw result data, and that comparison is impossible if all that crossed the boundary was a PDF of a results table. This is where the Allotrope work matters practically: a standardized representation of analytical data with its contextual metadata is what makes an instrument-level comparison feasible without a week of email.¹⁸

The compendial and lifecycle context

ICH Q2(R2) sets out what validation of an analytical procedure has to demonstrate, and ICH Q14 sets out the development and change management framework around it, including the idea that accumulated procedure knowledge supports later changes with proportionate effort.⁷⁶ For a transfer, the useful implication is the same as for the process side: if you send the knowledge and not just the conclusion, the receiving laboratory can make good decisions later without coming back to you for every one of them. If you send only the conclusion, either you become a bottleneck or they make the decisions without you.

Writing the Data Expectations Into the Agreement

Everything described so far has to be contractual, or it will not happen. Quality agreements between sponsors and contract facilities are well-established instruments, and FDA’s guidance on contract manufacturing arrangements describes what they are for and what they cannot do.⁹ The point here is narrower than the general question of what belongs in a quality agreement: it is what a transfer-specific data annex should contain.

The transfer data annex

We recommend a separate annex, referenced from the quality agreement, that covers the following. It is short. It is also the difference between a relationship where data flows and one where every request is a negotiation.

• The data inventory itself, as a controlled schedule. The six domains, itemized, with destination systems and named owners on both sides. Under change control, reviewed at least annually.
• Format obligations in both directions. What the sponsor will deliver and in what form, and what the CDMO will return and in what form. If a structured file is expected, name the schema. If a PDF is acceptable, say so deliberately.
• Destination verification. An explicit obligation to verify that values configured in the receiving site’s systems match the sponsor’s authoritative record, with a retained record of the verification, performed at initial configuration and after each change.
• System access, named by system and role. Which sponsor systems the CDMO may use, which CDMO systems the sponsor may read, at what level, and what the provisioning and de-provisioning process is when people change roles.
• Timing. Not just deviation notification windows, but the cadence for routine data returns, the window for ad hoc data requests, and a defined turnaround for records needed during a regulatory inspection.
• Audit trail and metadata access. An explicit right to the underlying data and its metadata for defined critical records, rather than to summary reports only. PIC/S expects the contract giver to be in a position to review original data, and the agreement is where that becomes possible.¹¹
• Change history maintenance. An obligation on the CDMO to supply change records in a form the sponsor can add to its own history, and an obligation on the sponsor to maintain that history.
• Retention, and what happens at exit. How long each category of data is held, in what format, and how it is returned or transferred if the relationship ends or the product moves to a second site. This clause is written by people who are optimistic and read by people who are not.
• Flow-down to subcontractors. The CDMO’s own testing laboratories and packagers inherit the same obligations, or the chain breaks at the first tier the sponsor cannot see.

Keep the transfer annex separate from the ongoing service terms

Transfer obligations and steady-state obligations have different shapes. The transfer annex is dense, time-bound, and closes. The steady-state data terms are lighter and permanent. Combining them tends to produce a document where the ongoing obligations are buried inside project language that everyone treats as finished once the project is. Separating them keeps the permanent commitments visible after the project team disbands.

The Operating Model After the Transfer Closes

The transfer project ends. The data relationship does not. The sponsor holds the marketing authorization, the quality unit obligations, and the answer to every question an inspector asks about the product for as long as it is on the market. That is a permanent operating requirement, and it needs to be designed rather than improvised.

What continued oversight actually requires

The WHO guideline places the review and close-out phase after execution and expects continued attention to stability studies, post-marketing commitments, and the integration of new material suppliers into the quality management system.¹ The older WHO guideline it replaced set out the same lifecycle expectation.² ICH Q10’s model treats commercial manufacturing as a lifecycle stage with process performance and product quality monitoring, corrective and preventive action, change management, and management review as ongoing system elements, and none of those pause because the manufacture happens at another company.³

In practice, five things have to run continuously.

Name a technical owner and keep them

The single most effective structural choice we see is naming one person at the sponsor as the technical owner of the product at the CDMO, and keeping that person in role for years rather than months. Not a project manager, and not solely a quality contact: someone who understands why the parameters are what they are and who reads the batch data. Turnover in that role is where change history goes to die, which is why the structured history described earlier matters. It is the only thing that survives a handover.

Watch for divergence

Over time, receiving sites drift. Not through misconduct. Through small changes that are individually reasonable and collectively significant: a supplier substitution, a slight range widening after a capability review, a method system suitability adjustment, a sampling plan simplification. Each one went through change control at the CDMO. Some of them were notified to the sponsor. The aggregate picture is visible only if someone is holding the authoritative record and comparing it to what is actually configured.

A periodic reconciliation, comparing the sponsor’s authoritative parameter set and specification set against what is live in the CDMO’s systems, is cheap to run if the data inventory exists and nearly impossible if it does not. Annually is usually enough. Doing it for the first time three years into a relationship is uncomfortable, and it is the exercise that most often finds something.

Conclusion

Technology transfer will keep being described as a scientific and regulatory exercise, and it will keep being planned that way, because that is where the visible risk sits and where the specialists are. The argument here is not that the science matters less. It is that the science travels inside an information architecture that almost nobody designs, and the quality of that architecture determines how much of the science actually arrives.

The practical version is short. Build the transfer as a data inventory across six domains rather than a document list, and insist on the destination and ownership columns. Protect the change history above everything else, because a receiving site that does not know why a parameter is set where it is will eventually change it. Be honest that the package still moves as documents and design a real verification at the destination rather than pretending the re-keying is not happening. Decide the systems boundary deliberately during the transfer, while there is still a budget and a sponsor, because summary reports alone leave you accepting conclusions you cannot test. Treat analytical method transfer as a data exchange and get the raw data across, not the summary. And accept that the operating model is permanent, because the accountability is.

Sakara Digital works with pharma and biotech organizations building the data foundations under manufacturing and quality operations, including the systems boundary between sponsors and their contract partners. If you are planning a transfer to a CDMO, or living with one that is not giving you the visibility you expected, and you want an independent perspective on where to start, we are happy to have that conversation.

For Further Reading