eCTD Software Data Portability: Export and Exit Checklist

This checklist helps regulatory operations, quality, and procurement teams specify an exit before buying or renewing software. Assyro publishes it as a procurement exercise. The worked example is fictional, and the acceptance criteria are proposed buying conditions, not evidence that any named vendor passed them.

Define the export before requesting it

Record the source product and release, application identifiers, authority, eCTD version, included sequences, cutoff, destination, and responsible owners. Distinguish submitted packages from working drafts. List correspondence, acknowledgments, review decisions, and source documents separately so that neither party assumes they are included in the dossier download.

Define two intended uses: retrieve the historical record and, where needed, continue publishing in another system. A readable archive may satisfy the first while lacking the editable project data needed for the second. Evaluate each against its own acceptance criteria.

For each check below, record the evidence location, operator, date, and result. Use pass for demonstrated acceptance, fail for an observed violation, unknown for missing evidence, and not applicable only with an approved scope reason. An export button or an unsigned promise is not a passing result.

eCTD export acceptance checklist

The suggested owners should agree these conditions before the pilot. Split a row into separate records when its subchecks produce different outcomes.

Agree the depth of inspection explicitly. Checking one representative reference does not establish that every link in a large portfolio works. Use a complete inventory reconciliation and an appropriate combination of technical checks and representative human review; record the unexamined scope.

Inspect three different layers of information

The submitted package

Retain the original package files and the metadata needed to interpret them. For an eCTD 3.2.2 example, a later replacement identifies the earlier leaf it changes; the original remains historical while the replacement becomes current. The relationship cannot be reconstructed reliably by sorting similarly named PDFs. This distinction follows the replacement example in Appendix 6 of the ICH eCTD 3.2.2 specification, dated July 16, 2008.

Use the applicable version's representation in your pilot. Do not apply 3.2.2 lifecycle instructions to a 4.0 package by analogy. Include external dependencies within the authorized scope, or document how the recipient will resolve them. A file can be intact while its destination is unavailable.

Keep an unchanged original export. If the receiving system creates an index, normalizes metadata, or generates a viewing rendition, identify that as a derived artifact and retain its mapping to the original. An integrity comparison demonstrates that bytes match the chosen baseline; it does not establish that the baseline was complete or scientifically correct.

The business and review records

Comments, approvals, user identities, workflow events, and correspondence may live outside the submitted package. Specify which records your organization requires, their format, and how they connect to a particular application, sequence, document, and version.

A comment reading “resolved” is of limited use without the issue, disposition, responsible person, and relevant revision. A spreadsheet can be a useful retention format if it preserves the necessary relationships and can be read. It need not reproduce the old application's interface. Conversely, a visually convincing PDF report may omit the identifiers needed to locate its evidence.

Set the required record fields with your quality and records owners. Do not assume every working comment requires the same retention treatment, or that an exported approval label recreates the original electronic-signature functionality.

The software project and access dependencies

The dossier export, editable publishing project, and software license are separate deliverables. Record which one is needed for each future task. A target publisher may import a standards-based package while requiring additional work to establish its internal project structure; test that workflow if continuation is part of the purchase decision.

For example, Veeva documents dossier export specifically for RIM Submissions Archive, including retained folder structure and a warning that continuous publishing can leave an export incomplete. Its general-release instructions also identify export and file-staging permissions. These are concrete details to verify in that workflow; they do not establish post-contract access or export of every review record. See Veeva's export documentation, updated June 10, 2026.

Worked example: all the PDFs arrive, but the exit fails

Use this fictional record to practice evaluating the checklist. It describes expected observations; it is not a downloadable eCTD package or an executed software test.

Application ALDER has three agreed 3.2.2 sequences: 0000, 0001, and 0002. Sequence 0000 contains report A. Sequence 0001 contains report B replacing A. Sequence 0002 contains a summary with an explicit historical reference to report A. The reference must continue opening A, even though B is current for the replaced report's position in the dossier.

The separately retained business inventory contains one approval record, AP-17, attached to B's reviewed revision, and one authority letter, COR-4, associated with sequence 0002. The buyer wants an independently readable historical archive. Continued authoring is expressly excluded from this pilot.

P3, P10, P11, and P12 remain unknown until their evidence is inspected. Do not infer them from the successful rows. This example is sufficient to reject exit acceptance already: the failed reference and approval association are required conditions.

After correction, repeat the historical reference test and inspect AP-17's association. Retrieve COR-4, rehearse the intended archive access, and complete the remaining checks. Keep the failed results and the corrective evidence. A rerun establishes the corrected scope; it does not retroactively turn the original export into a pass.

Test archive access after the contract ends

Read-only access still has dependencies. It may require a paid archive subscription, a separate viewer, supported runtime software, customer-controlled storage, or continuing identity administration. Identify the arrangement that will exist after the authoring contract ends, including who pays for and operates it.

First, agree the access period and operational service. Specify the retained applications, permitted readers, retrieval process, expected response time, and responsibility for reader compatibility. Your records and legal owners determine the applicable retention obligations; there is no single retention duration supplied by this checklist.

Next, rehearse that exact arrangement safely. Use an isolated test environment or an agreed controlled account transition. Disable the pilot's authoring entitlement while retaining only the proposed archive entitlement. Have the archive reader locate the application, open the historical and current documents, follow the selected reference, and retrieve AP-17 and COR-4. Record the account and software involved.

If the arrangement depends on the old authoring account, the rehearsal has not established independence. If a paid archive service is the agreed solution, its continued license is an explicit dependency to price and manage. The important distinction is between an understood retained service and an unrecognized requirement that disappears at termination.

Test access removal separately. An archive reader who should retain access and a former external reviewer whose access should end have different expected outcomes. Check the removed user's existing session as well as a new login. Do not disable actual production users or remove real licenses merely to illustrate this article.

Then test recovery from the retained copy. A backup that downloads successfully has not yet proved that another authorized person can reconstruct a usable archive. Restore it into the proposed environment, repeat the representative retrieval and reference checks, and verify that access restrictions remain appropriate. Identify who owns decryption keys, reader installation material, and any supported migration process needed over time.

Finally, put the evidence into the exit schedule: export deadline, correction window, assistance responsibilities, known fees, unresolved charges, archive entitlement, and acceptance owner. The eCTD software cost guide provides a separate switching-cost worksheet. An unknown mandatory archive fee remains an unresolved budget input, even when technical retrieval passes.

Make portability part of the buying decision

For a renewal, ask the incumbent to demonstrate the agreed export before the exit window closes. For a replacement, have the source and destination owners inspect the same package and record their separate responsibilities. Defer irreversible decommissioning until the required evidence is accepted under your transition plan.

Bring the completed inventory and failed or unknown checks to an Assyro evaluation if you are assessing its fit. Confirm the exact supported format, destination workflow, and retained-access terms first. The useful purchasing outcome is a documented account of what your team can retrieve and use after exit, with every remaining dependency assigned to an owner.