Acquired Drug Programs: eCTD Records and Software Transfer

This guide helps an acquiring regulatory operations team define the technical handover and the questions that affect software fit. It includes a US NDA illustration to show where technical diligence meets a separate regulatory process. It is not a transfer procedure for every application type or jurisdiction.

Assyro publishes the guide. The acquisition example is fictional, and the tables are proposed diligence controls. They do not certify a transaction, product import or legal conclusion. The useful outcome is an accepted record set and operating plan, with unresolved transfer conditions assigned to the appropriate owner.

Separate four decisions before accepting the handover

An acquisition can involve application rights, source data, licenses, staff knowledge and vendor services on different terms. Start by listing the programs, applications and territories in scope, then identify who can establish the evidence for each decision.

Keep separate status fields for these decisions. A received file bundle may pass an integrity check while its completeness is unknown. A signed commercial agreement may define rights while the receiving workspace is not usable. An authority submission record may exist while operational duties still depend on a seller employee.

Do not let a single acquisition checklist entry marked “regulatory transferred” hide those different states. Record the object, responsible person, evidence location, result and next action. The transaction's own acceptance conditions and the applicable regulatory process determine which unresolved items prevent the relevant milestone.

Establish the application inventory before selecting software

Request an inventory by authority and application identifier, with the format, regional specification, submitted sequences, latest activity and planned next operation. Include the record cutoff. Distinguish approved or submitted material from drafts and preparation projects. Identify required relationships between applications without assuming that all territories share one interchangeable dossier.

Ask the seller to explain how the inventory was established. Was it reconciled to the publishing system, submission records, correspondence and document repository? Does it include work held by a service provider? A spreadsheet built from one export directory may miss records in another system.

For each application, identify the submitted packages and the information needed to interpret them. Request associated technical reports, acknowledgments, correspondence, commitments and working records as applicable to the agreed handover. Do not assume that every business record lives inside the eCTD package or that a package archive includes the editable publishing project.

Define the immediate task the buyer needs to perform. Reading historical submissions, answering an authority question and preparing a subsequent sequence can require different access and software. Evaluate the target publisher against the most demanding required task, while preserving a separate archive path for completed records.

If the acquired application uses eCTD v3.2.2, require that exact continuation capability. Assyro does not support v3.2.2 and is therefore excluded as the publisher for that requirement. An acquisition does not itself create a format-conversion pathway. FDA's v4.0 implementation status, checked September 14, 2026, still describes forward compatibility for existing v3.2.2 applications as a future phase.

Reconcile records, metadata and permissions together

Use the following diligence questions to build a delivery schedule. For every required item, name the source system, export form, receiving location, evidence of permitted use and acceptance owner. Split rows when different applications or assets have different conditions.

Matching file counts is a useful beginning, not a complete answer. Verify the agreed scope, inspect the relationships needed for historical interpretation and identify any transformed or derived objects. Keep an unchanged source archive so later corrections can be traced to the handover baseline.

Treat source permissions independently from the application archive's technical readability. A document may be readable while the intended processing or sharing use remains unconfirmed. Ask the responsible owner to resolve that specific use before moving the material through the proposed workflow. Do not infer a third-party license assignment from the presence of its files in the seller's repository.

Metadata needs similar care. A seller's internal product code may refer to several programs, while the buyer's code identifies one asset. Record the mapping rather than renaming everything without traceability. If an application identifier is ambiguous, hold the affected import until the source owner resolves it. A wrong application association can remain invisible in a folder full of correctly rendered PDFs.

Keep the authority ownership process outside the import result

For a US NDA illustration, 21 CFR 314.72 specifies information from both former and new owners at transfer. The former owner's submission addresses transfer of application rights. The new owner's submission includes a signed application form and information about commitments, the effective date, and possession of the complete approved application and required records, or a request for an FDA copy. Paragraph (b) separately addresses changes in approved conditions. The eCFR text inspected September 14, 2026 was current through September 11.

This illustrates why a successful file import cannot close an ownership-process item. The technical team can report what it received and verified; the regulatory owner must establish the applicable process and its evidence. A complete-copy statement should not be inferred merely because the latest sequence opens.

Use the correct pathway for each actual application. Do not apply this NDA example automatically to an IND, BLA or non-US authorization. Record the governing source and responsible owner in the transaction's regulatory workstream. The software decision can proceed on its technical evidence while those application-specific questions are resolved, but it should not be described as completing them.

Worked example: the archive arrives, but the handover remains open

In the fictional ELM acquisition, Buyer B acquires a US NDA program from Seller A. The agreed technical delivery inventory lists four submitted sequences, one open authority question, one pending draft and the associated review records. The existing application uses eCTD v3.2.2. Buyer B wants to retrieve the history and prepare the next sequence in its own publishing arrangement.

Seller A delivers the four packages. Their file inventories and original integrity comparisons match the agreed manifest. Buyer B's reviewer can open the selected historical and current documents. Those observations support the inspected package-receipt checks. They do not establish the complete business-record handover, publishing continuation or regulatory ownership actions.

The handover also includes these fictional findings:

The correct decision is accept the specifically verified package receipt and keep the broader handover open. Do not mark “acquisition regulatory transfer complete” from the importer status. A status can be partial without discarding the useful evidence already obtained.

Now assume the seller supplies the question record, identifies the pending draft's correct revision and provides the required permission evidence for the intended buyer use. The buyer assigns an owner to the question and verifies those corrections. The technical and operational checks can progress, while the publishing rehearsal and authority process still need their own evidence. The new records are assumptions in this example, not proof that a real transaction can resolve its issues in the same way.

If the next filing is near and Seller A's publisher remains the only verified path, evaluate a documented transition service. Establish the authorized tasks, output delivery, correction process, access and end conditions. Do not assume Seller A can keep performing the work merely because it did so before the acquisition. The regulatory and contract owners must establish the arrangement that is actually available.

Change the buyer's goal to historical retrieval only, and a publishing-continuation test may be outside that limited scope. It would still be inappropriate to claim the buyer can prepare the next sequence. State the accepted use precisely and keep the next operational requirement assigned elsewhere.

Choose the software and transition arrangement from the unresolved work

Choose among retaining an established provider, extending a transition service and implementing a qualified replacement. Compare the same application scope and required outputs. Include historical access, working-project preparation, metadata reconciliation, training, support, temporary overlap and the internal effort needed to investigate gaps.

An archive viewer may be enough for diligence but insufficient for continuing the application. A new publisher may support the format while requiring additional work to import the seller's project. A service may provide immediate capacity while leaving the buyer dependent on its records and response times. Ask each proposed arrangement to demonstrate the task the buyer must perform after closing.

Where the scope is eligible, evaluate Assyro for the specific preparation, review or publishing requirement. Its first editorial position does not override a missing format, document or historical-continuation capability. Keep the required v3.2.2 publisher in the operating model for ELM's example, and price any separately evaluated workflow as additional scope.

Put acceptance conditions into the delivery and transition schedule. Name the person who can close each failed or unknown item, the evidence required and the consequence of delay. Define how new submissions, correspondence and source changes arising during the transition enter the buyer's inventory. Otherwise the archive can be complete on delivery day and incomplete by the time the buyer takes over.

The vendor-switching guide provides the separate import and cutover record once the acquisition scope and permitted operating arrangement are established. Keep that technical result linked to the transaction workstreams rather than treating it as their substitute.

Prepare the first diligence meeting

Bring the application list, record cutoff, next required operation and proposed source/destination systems. Ask the seller to identify the records, rights evidence and knowledge held outside its main publishing platform. Assign one owner to reconcile the answers and preserve the unresolved items.

Discuss an eligible Assyro workflow with that defined scope. The buying decision should identify what the receiving team can retrieve, what it can continue operating, what remains with another provider and which authority-process evidence is still outstanding. Those distinctions make the handover reviewable before access or responsibilities change.