Applications change hands: a product is licensed, a company is acquired, a publishing vendor is replaced, a tool is retired. The new owner receives years of sequences and is expected to file the next one as if nothing had happened. Often something has.
Key takeaways
- Check an inherited application before you file anything new on top of it.
- Most problems are missing files, inconsistent XML or broken lifecycle references.
- Fix without rewriting what was filed: the agency already has those sequences.
- Prove the result in a sandbox before repeating it in production.
Why inherited applications go wrong
An eCTD application is a chain. Each sequence refers back to documents in earlier ones, and every later operation depends on those references being intact. When the chain is moved — from one vendor to another, from an on-premise tool to the cloud, from one company to its acquirer — small breaks are easy to introduce and hard to see. A folder is renamed, a sequence is copied without its utility files, a file is edited after its checksum was recorded. Nothing fails until the next sequence tries to replace a document that the new system cannot find.
This is usually the first job a publishing desk is called for, before the next sequence: proving that what was filed is what is on the shelf.
Run a health check first
Files. Reconcile what each backbone references against what is actually on disk, for every sequence. Missing files have to be found or re-sourced; extra files that nothing references are a sign that something was edited or copied by hand. Re-check every checksum.
Backbone. Validate each sequence’s XML against its own specification version — an old sequence is checked against the rules that applied when it was filed, not today’s. Look for gaps or duplicates in sequence numbers.
Lifecycle. Follow every replace, append and delete back to its target. Each should point at a document that exists, and the resulting current view should show one version of each document in force. Then compare that view with what the team believes was filed.
What we usually find
- Missing files referenced by the backbone but absent from the archive.
- Malformed or inconsistent XML inherited from a previous tool.
- Broken lifecycle references, where a later operation points at a document path that no longer resolves.
- Duplicates in force, where a document was filed as new when it should have replaced an earlier version.
- Document defects — fonts, bookmarks, links — that were never fixed and will be inherited by the next sequence.
You cannot rewrite what the agency already has. You can make sure the next sequence builds on it correctly.
Fix without rewriting history
Sequences that have been filed belong to the agency’s record. The goal of remediation is not to change them, but to make your archive an exact match for what was sent and to give the next sequence a sound base. Missing files are reconstructed or re-sourced; XML problems are repaired without disturbing the lifecycle chain; and where the current view is genuinely wrong, the correction is made openly in a new sequence with the right operations.
Where an application is moving into a new system, publish it in a sandbox first, prove that the current view and every reference match the original, and only then repeat it in production.
Work the defect list one document at a time. It is unglamorous, and it is what decides whether the next validation run is clean.
How DnXT approaches it
Our publishing desk runs remediation and migration as fixed-scope projects alongside routine publishing: missing-file reconciliation, backbone clean-up, legacy republishing and system migration. DnXT Publisher validates imported sequences against each region’s criteria and shows cumulative and current views side by side, so the result can be checked before anything new is filed. See how one team moved its regulatory platform from on-premise to the cloud.
Not sure what you inherited?
Send us an application and we will tell you what its history really contains.
