Build the cross-reference manifest
The manifest is the bridge between the old archive and the new one. One row per record, written once and stored immutably as a signed file. It's the artefact an auditor reads first.
Each row carries the original filename and the standardized name. It also carries the contract identifier and the baseline hash, with the certificate reference and the source location. Around the rows sit the approvals: who authorised the batch, when, and under what version of the scheme. The approach mirrors what ISO 14641-1 asks of an electronic archiving system, where integrity rests on fingerprints of archived objects and a time-stamped log of operations.
Version the manifest itself and never overwrite it. If the scheme changes mid-project, you issue version 2 and record why, so that version 1 stays readable. Exception notes belong in the same file, so that every record a script refused to touch has a documented reason sitting next to it. File naming conventions without a manifest are just a preference, and the manifest is what turns them into evidence.
Rename files safely
Rename at the file-system level only. The operation changes the directory entry and nothing else, which means no library that opens or re-serialises the document. Any tool that loads a PDF into memory to write it back out has already left the safe path.
Pilot on a small batch first, maybe 50 records spanning your messiest formats, and verify that batch fully before scaling. The script refuses to overwrite an existing name and stops on the first exception rather than continuing. It writes an append-only log of every action with its timestamp and result. File naming best practices at this stage are mostly about restraint: do one thing and halt when reality disagrees with the manifest.
Collisions are the most common failure. When two records resolve to the same standardized name, the run stops and both go to review, because silently appending a counter buries a duplicate-contract problem inside a naming problem. Applying file naming conventions is reversible. Losing track of which of two agreements was the executed one is not.
Avoid the Save As trap
Here's the failure that undoes an entire project. Someone opens a signed contract in a PDF editor, uses Save As to give it the new name, and the editor rewrites the file structure on the way out. The signature panel then reports a problem, because modifying a signed document invalidates existing electronic signatures.
Certification signatures make this stricter still. A PDF sealed with the DocMDP setting NO_CHANGE_PERMITTED treats any change to the document as invalidating, so there's no benign rewrite. Format conversion carries the same hazard, which is why ETSI notes that a document should be converted to PDF/A before signing rather than after.
There's a second, quieter discrepancy. Certificates of completion frequently stamp the filename as it existed at signing, so a rewritten file can end up with a name that contradicts its own certificate. Quarantine anything suspected of a rewrite and route it to legal and technical review together. File naming conventions state in plain terms that Save As is prohibited on signed records.
Verify renamed files
Recalculate SHA-256 over every renamed file and compare each result to its intake value. The match has to be exact. A single mismatch means the file was rewritten rather than renamed, and that record goes back to quarantine rather than into the archive.
Reconcile counts as well as hashes. The number of agreements and the number of certificates agree with the number of manifest rows, and any shortfall gets explained before sign-off. Re-run signature validation on a sample using an independent validator, such as the tools described in the European Commission's eSignature validation guidance, so you're not relying solely on the hash comparison. File naming best practices end with proof.
Then obtain written approval before the working copy replaces anything. The approval references the manifest version and the verification report. Only after that does the source archive come off read-only.
Preserve evidence in Agrello
A renamed archive is only as defensible as the evidence stored alongside it. Keep the completed records together with the sealed manifest and the certificates of completion. Store both sets of hash results and the approvals in one place with consistent references between them. An auditor takes a standardized name and finds its manifest row. The auditor reads the original filename and baseline hash, then confirms the signature still validates.
That continuity is what makes file naming conventions safe to apply to historical contracts rather than risky. Since the eIDAS Regulation took effect on 1 July 2016, the EU has recognised three levels of electronic signature, and the higher levels rest on cryptographic structures described in ETSI EN 319 142-1 that your renaming process must leave untouched. Agrello stores signed documents with their signature data and audit records in one repository, which is where this evidence set belongs. Document naming conventions and chain of custody then live in the same system instead of in two spreadsheets that drift apart.
Closing the loop
The sequence is unglamorous and it works: scope it and inventory it, then hash it and map it. You then rename it at the file-system level and verify byte for byte. The sequence requires that you refuse to open the files.
Agrello is a document management and e-signing platform where signed agreements and their certificates sit together. Talk to Agrello about preserving signature validity across a legacy archive, or start a free trial and test your file naming conventions against a real signed record set.
