eCTD Software Implementation Plan: Milestones and Owners

This plan is for a regulatory operations lead implementing a new publishing workflow. Assyro publishes it as an original planning resource. The milestones and example durations are proposed project assumptions, not measured vendor delivery times or FDA review targets.

Define where implementation starts and ends

Record a kickoff event after the required commercial and project approvals. Name the product and release, authority, eCTD version, first application, document sources, intended users, and publishing responsibilities. Identify which prerequisites were completed before kickoff so their time and effort do not disappear from the overall plan.

For this article, the implementation endpoint is an accepted release rehearsal with permission to use the qualified workflow for the first production sequence. The rehearsal uses permitted test content. Production source approval, release authorization, transmission, acknowledgment review, and agency assessment remain distinct events. Do not label a successful rehearsal as a submitted or accepted regulatory application.

A new software deployment is also different from converting an existing application history. FDA's current eCTD v4.0 page describes support for new applications and identifies forward compatibility for existing v3.2.2 applications as a future phase. Check that pathway before adding “migrate our existing application to v4.0” to an onboarding plan. FDA eCTD v4.0 implementation status

Milestones from contract to controlled use

Replace the suggested owners with named people. Record each milestone's evidence, actual completion time, open exceptions, and acceptance decision. “Vendor finished its work” and “customer accepted the result” should not be the same checkbox.

M1, M2, and M3 can often proceed concurrently after scope is agreed. Training preparation can also start early, although final operator readiness depends on the environment and procedures actually being used. Do not add every parallel task's duration together as if one person performs them sequentially.

Resolve the dependencies that usually hide behind “onboarding”

Configuration and qualification are different deliverables

Configuration establishes the proposed environment. Qualification establishes evidence for its intended use. Your quality team determines the required assessment and documentation; this planning article does not prescribe a universal validation package.

Ask the supplier what it provides and what remains with the customer: release documentation, configuration assistance, test evidence, training, or technical support. Review supplied evidence against your exact configuration and use. An installation record does not show that your document references, roles, or export process work.

The source set should include representative difficult cases as well as ordinary documents. Name the expected outcome when a required input is missing or a reference is unresolved. A qualification plan that contains only successful package creation cannot show how the operators recognize and handle a blocked release.

Source readiness is an owned workstream

Identify who supplies documents, metadata, permitted test material, templates, and expected results. Give each dependency an acceptance condition. “Documents uploaded” does not establish that the selected revisions are approved for the exercise or that the expected output is known.

Keep qualification inputs separate from the first production content inventory. A stable test set lets you evaluate the workflow even while scientific documents are still being finalized. It does not make unfinished production content releasable. Carry those production dependencies into M7 explicitly.

Gateway readiness depends on the actual route

For an FDA workflow, identify the submitting party, center/submission type, account status, and selected ESG NextGen method. Apply current instructions to that combination rather than copying an old generic signup timeline.

For example, FDA's current Center Submission Types table marks CDER / ECTD as not requiring a test submission for a new ESG NextGen user before production access. That does not waive account approval or prove that your software and operators are ready. Other center/submission types have different flags. FDA Center Submission Types

An internal rehearsal can still be a project acceptance requirement. Keep that internal condition separate from an agency onboarding requirement. If a partner will submit, assign evidence delivery and acknowledgment monitoring to named parties instead of assuming the software license includes those services.

Worked calendar: parallel tasks and a delayed source set

This is a fictional internal schedule. It makes no claim about typical implementation length. All timestamps are 09:00 UTC, durations are elapsed calendar days, and the team has explicitly planned coverage on weekends. No holiday or business-day adjustment applies to this example. Your staffing calendar may require a different forecast.

Assume kickoff is September 14, 2026 at 09:00 UTC, after M0 acceptance. Planned prerequisite completion is:

• M1 configuration: kickoff plus 3 days, September 17.
• M2 qualification source set: kickoff plus 5 days, September 19.
• M3 submission route: kickoff plus 4 days, September 18.
• M5 operator readiness: kickoff plus 6 days, September 20, using the configured environment and agreed procedures.

M4 qualification takes an assumed three elapsed days after both configuration and sources are accepted. M6 rehearsal takes two elapsed days after qualification, route readiness, and operator readiness. The example assumes acceptance decisions occur at task completion without an additional queue and that no rework is needed.

The planned implementation endpoint is September 24. It is not the forecast production submission date because M7's production-content and release conditions have not been dated in this example. The model also assumes route readiness is confirmed as planned; an external dependency without evidence cannot be treated as complete merely because its target date arrives.

Now change one fact: the qualification source set is accepted on September 22, three days later than planned. Keep all other conditions unchanged.

Qualification now starts September 22 and finishes September 25. Rehearsal starts September 25 and finishes September 27 at 09:00 UTC. The end date shifts by three days because source readiness lies on this example's controlling path. The already completed route and operator work is not added again.

If the source owner cannot provide an acceptance date, the revised endpoint is unknown. You can display a conditional scenario—“if sources are accepted September 22, rehearsal acceptance is forecast September 27”—but should not present that date as a committed plan.

What to do when a gate fails or a date arrives too early

Suppose the calendar reaches September 24 while the delayed qualification is still open. The workflow is not ready under the stated plan. Preserve the original target as the baseline, record the actual dependency status, and publish the revised forecast with its assumptions. Do not close a milestone merely to keep the dashboard green.

When an acceptance test fails, distinguish correction time from retest and approval time. Assign the finding to the party that controls the affected component. A missing source belongs to its source owner; a configuration error belongs to the configuration owner. Determine the cause from the actual evidence before assigning a software defect.

Recalculate only after the affected work is scoped. For example, if correction changes the configured output process, identify which qualification and operator exercises need repeating. A change that affects the rehearsed workflow may also invalidate part of M6. Preserve unaffected evidence where your process permits it; do not assume every finding restarts the entire project or that none require retesting.

If the planned release date is fixed by a business need, escalate the unresolved dependency with the available options: qualified retained tooling, an agreed external publishing arrangement, a narrower supported scope, or a revised date. Each option needs its own acceptance and responsibility record. Schedule pressure does not establish a missing capability.

Finish with a reproducible handoff

At rehearsal acceptance, have someone other than the original operator retrieve the prepared package, identify its configuration and input set, inspect the review evidence, and explain the next action. Confirm the support contact and the procedure for an interrupted or unsuccessful handoff.

Assign retention explicitly. FDA's ESG NextGen FAQ distinguishes submission details and downloadable acknowledgments from the actual submitted files, which outside users cannot retrieve through the portal. Keep the released package in your agreed records system; submission history is not a substitute for your own retained artifact. FDA ESG NextGen FAQ, Unified Submission Portal

Before M7, verify the production content and exact release-specific conditions rather than reusing the synthetic rehearsal's approval. After transmission, record the returned evidence and unresolved response status separately. A completed technical handoff does not establish an agency's scientific decision.

Turn the plan into an implementation proposal

Ask vendors to return this milestone structure with named deliverables, dependencies, customer effort, acceptance responsibilities, and duration assumptions. Compare what each quote includes: configuration, qualification support, training, source preparation, integrations, release assistance, and continuing support. The eCTD software cost guide helps separate those costs from the recurring license.

For an Assyro implementation discussion, bring the authority/version scope, first-use task, source inventory, and submitting-party arrangement. Confirm the available product workflow before placing it on the schedule. The plan is ready to manage when every milestone has an owner, visible evidence, and a forecast that changes honestly when its dependencies change.