Switching eCTD Software Vendors: Migration and Cutover Guide

This is a documentary procedure for regulatory operations teams changing publishers. Its inventories and examples are proposed acceptance controls, not agency forms or observed vendor tests. No production submission should be sent merely to exercise the procedure. Test with an authorized isolated copy and preserve the original history.

Assyro publishes this guide and is our first evaluation for an eligible workflow. Assyro does not support eCTD v3.2.2, so it is excluded as the replacement publisher in the continuing v3.2.2 example below. The same eligibility gate applies to any candidate that cannot perform the required operation.

Define the switch separately from a format migration

Record the source and destination products, releases, application identifiers, authority, regional specification, package format, included sequences and next intended submission. Identify active work that is not yet part of the submitted history. Give the source owner, migration lead, publishing reviewer and cutover authority distinct responsibilities, even if some roles share a person.

A move between publishers using the same specification is a different project from converting an application to another eCTD version. FDA's current v4.0 implementation status, checked September 14, 2026, describes acceptance of new CDER/CBER applications in v4.0 and forward compatibility for existing v3.2.2 applications as a future phase. A vendor's support for v4.0 does not establish a current conversion path for an existing v3.2.2 application.

Agree the receiving use before export. An archive-only transfer needs retrievable records; a publisher replacement must also support continued work. The data-portability checklist covers exit and retained access. This procedure adds the reconciliation and cutover needed to take over the next publishing operation.

Reconcile legacy sequences and their dependencies

Start from the authoritative source inventory, not the files the importer happened to accept. List each application and sequence, its status, package location and required supporting records. Distinguish submitted packages from drafts, unsuccessful attempts and generated viewing copies. Preserve their identifiers and explain exclusions; a sequence-number gap alone does not establish that a submitted sequence is missing.

For each inventoried package, record its file list, backbone and regional metadata, relevant lifecycle relationships, references and associated reports or correspondence. Identify dependencies outside the latest sequence. Verify the inventory with the person responsible for the historical application, then retain an unchanged source copy before importing.

Consider the fictional BIRCH application, using eCTD v3.2.2 throughout. Its agreed history is sequences 0000, 0001 and 0002. Sequence 0000 contains report R0 and study report S0. Sequence 0001 contains report R1 replacing R0. Sequence 0002 contains summary Q2, which links to S0 in sequence 0000. The current and historical replacement distinction follows Appendix 6 of the ICH eCTD 3.2.2 specification, July 16, 2008; the named documents here are invented.

Now suppose an import finishes after receiving only 0001 and 0002. Q2 opens, and the importer displays a completion message. Reconciliation still fails: the agreed inventory includes 0000, and its S0 dependency cannot be inspected. Do not manufacture a placeholder or repoint Q2 to a similarly named report merely to remove the error. Recover the missing original history and repeat the affected import and reference checks.

Check the original files separately from derived indexes or renditions. An integrity comparison can establish that retained bytes match the chosen baseline. It cannot establish that the baseline was complete or that the destination interprets lifecycle metadata correctly. If the destination changes internal identifiers, preserve a source-to-destination mapping and verify that references still reach the intended objects.

Where the full history is unavailable, document the gap and its operational impact. A readable partial archive does not automatically support continued publishing. The migration authority must choose a supported recovery or retained-system path before accepting the replacement scope. Record unexamined dependencies explicitly rather than treating a small sample as evidence for the entire portfolio.

Use a migration acceptance test record

Use this reusable record for each test: test ID; application and scope; source evidence; expected result; destination evidence; actual result; status; owner; correction and retest reference. The expected result is agreed before the run. Keep blank fields in a working template, but do not present an incomplete record as a completed test.

Record pass, fail, unknown and justified not applicable separately. Unknown means the evidence does not establish a result. A confirmed disagreement with a mandatory expected result is a failure. Not applicable requires a scope reason approved by the person responsible for that requirement.

These are the baseline cases for a publisher replacement. Expand them for the actual application and configuration; they do not represent a complete agency validation rule set.

Here is a completed synthetic M3 record for BIRCH: scope is Q2's reference to S0; source evidence is the agreed 0000–0002 inventory and Q2 reference map; expected is opening S0 from 0000; destination evidence is receiving inspection B-14; actual is “target unavailable because 0000 is absent”; status is fail; owner is the migration lead; correction is recover and import the original 0000 package, then repeat M1–M3 for the affected scope. The missing package has not yet been recovered in this initial record.

For a separate positive case, assume a permitted rehearsal copy contains all three sequences and an original-file comparison shows every inventoried file unchanged. That supports M1 and M2 for that inspected copy. It does not establish M3–M6. If no restore was attempted, M6 is unknown. If the approved scope is archive-only, M5 can be not applicable with that reason; it cannot be waived for the publisher-replacement scope used here.

During the continuation test, check both the proposed new output and the unchanged historical originals. Identify the exact tool and criteria used for technical checking. A vendor may rebuild internal project data during import, so compatibility must be demonstrated in the offered configuration. Do not require identical proprietary database records when the agreed outcome is correct usable history, but do require evidence for every mandatory relationship and next operation.

Keep failed attempts and later retests. A new passing result establishes the corrected condition; it does not make the original import complete retrospectively. The cutover authority should receive the evidence record and unresolved scope, not just a percentage-complete dashboard.

Decide go, delay or fallback before the filing

Choose the cutover decision from evidence and the remaining workload. There is no universal number of days before filing that makes a switch safe. The relevant inputs are source readiness, required corrections, operator availability, receiving-workflow acceptance and the viability of the retained publishing path.

Apply these gates at the agreed decision meeting. Split them into individual records if applications or environments have different results. A working demonstration in one program cannot release another program whose history is still incomplete.

In BIRCH's initial state, the missing S0 dependency makes reconciliation fail. The next sequence has not been rehearsed, so the next-operation gate is unknown. The team cannot choose go merely because its filing date is close. It should first determine whether the incumbent remains eligible and accessible for the required next operation. A fallback is a demonstrated operating path, not an assumption that an old license still works.

Suppose the team later recovers the history, accepts the affected retests and completes M5, but a late source update arrives after the migration cutoff. The document coordinator records the changed object and its downstream impact. Reconcile that change and repeat affected output checks before go. Do not silently re-export the entire project and assume the earlier acceptance evidence still applies unchanged.

If the incumbent can perform the filing while the migration remains incomplete, finish that scoped work there and set a later boundary for takeover. Identify where the resulting new history will be retained and incorporated into the replacement. Otherwise the successful fallback itself creates another migration gap. Avoid maintaining two competing approved packages for the same operation.

For an archive-only transfer, a publishing rehearsal may be not applicable, but retrieval and recovery still need evidence. For a publisher takeover, those gates remain required. The decision record should state go for the accepted scope, delay pending named evidence, or fallback to the specified retained path, with the owner and conditions for reassessment.

Check the desktop-to-cloud changes separately

Moving to cloud software changes operational dependencies even when the submission specification stays the same. A desktop workstation may read a local network folder, use a locally installed conversion utility and rely on a person's stored credentials. A cloud service does not inherit those capabilities merely because it imports the dossier.

Map each dependency to its proposed replacement. Test under the actual intended user identity and environment, using permitted material. Do not use an administrator's successful setup session as the only evidence for an ordinary operator's workflow.

Consider a separate BIRCH variation after the historical import is complete. The cloud publisher can open the dossier, but the next source document exists only on the operator's local shared drive. The proposed workflow assumes direct access to that drive, and the actual receiving environment cannot retrieve it. Source access fails for the promised arrangement. The correct action is to establish an approved transfer or supported connector, verify the source version and repeat the handoff. Do not treat historical import as proof of ongoing source access.

If the ordinary publisher account completes its assigned task and a reviewer account is prevented from publishing under the agreed role design, the scoped identity check passes. If the interruption recovery exercise was not run, that check remains unknown. If the workflow has no local conversion utility and the scope inventory confirms this, the local-utility item can be not applicable with that reason. It is not a default exemption for every cloud deployment.

Have the quality owner assess what changed in the configured use, procedures and supplier responsibilities. This is not a universal requirement to repeat an identical qualification package for every move. Likewise, a vendor's cloud certification does not establish your particular source access, restore path or publishing continuation.

Retain a practical operating instruction: where sources come from, who transfers them, how failures are recognized and who restores work. Cloud convenience is valuable when these dependencies are understood. An undocumented local workaround that only one operator knows should not become the basis for accepting the new workflow.

Close the migration with an accepted operating record

Before ending incumbent access, have a person outside the migration team retrieve the agreed historical documents and decisions, then locate the next working submission and its owner. Confirm that the retained archive and active publisher are identified separately. Close required reconciliation, continuation and recovery findings for the accepted scope.

Retain the source baseline, import records, accepted outputs, test dispositions, change cutoff, remaining responsibilities and commercial access terms. Record what is deliberately retained in the incumbent and the condition for removing that dependency. A project can complete a scoped transition while retaining an agreed archive service; it should not claim a full replacement while an essential operation remains unassigned.

Discuss an eligible Assyro workflow with the exact authority, version, history and next task. For a scope requiring another publisher, use the same reconciliation and cutover evidence with that vendor. The purchase is ready to become an operating decision when the required history, output and recovery path can be demonstrated.