The Tools Behind a Clean Archive Handover Checklist
A look at the checklist, manifest and verification methods we rely on when preparing a finished video project for long-term archive and handing it to a colleague.
Marcus Delgado · · 6 minutes to read
Why the method matters more than the software
When we teach archive handover, we start with a plain point: the tools matter far less than the habits around them. A finished project can sit on a shared drive, a cloud bucket or a shelf of external disks, and in each case the person who opens it two years later needs the same things. They need to know what is inside, what is final, and what can safely be ignored.
The methods we rely on are deliberately modest. A written checklist, a folder manifest, a short readme and a verification pass cover almost every situation we meet in the Archive Handover module. None of them needs a licence or a special setup, so a freelancer and a ten-person team can follow the same routine.
This article walks through those working tools in the order a learner meets them, so you can judge which to adopt first and how they fit together before a project closes.
- A written handover checklist
- A folder manifest or file list
- A short readme for the project
- A verification pass before closing
The handover checklist as the central document
The checklist is the backbone of the module. It is a single page, one line per task, each with a tick box and a space for initials and a date. Learners build their own version during the course, starting from a simple template and trimming or extending it to match how their shoots actually run.
A good checklist asks questions rather than giving instructions. Are the final exports present in every delivery format? Is the project file saved with its media relinked or collected? Have temporary renders and cache folders been removed? Are the music and licence notes stored beside the cut that uses them?
We encourage keeping the list short enough to finish in one sitting. Once it grows past a page, people stop reading it and start ticking boxes out of habit, which defeats the purpose. Short, specific and signed off by a named person is the standard we practise in class.
- One page, one line per task
- Questions rather than commands
- Initials and a completion date
Manifests and readme files
Alongside the checklist we ask learners to produce a manifest: a plain list of what the archived folder contains, with folder names, file counts and total size. It can be generated from the file system and pasted into a text file in a few minutes. Its value is that anyone can compare the archive against it later and see at once whether something has gone missing.
The readme is the human companion. It is a short note, a few paragraphs at most, naming the project, the editor and producer, the date the project closed, the software versions used and the location of the final deliverables. It also records anything unusual, such as footage that was replaced or a cut that was withdrawn at the client's request.
We keep both files as plain text on purpose. Plain text opens on any machine, survives software changes and can be read by someone who has never seen your editing setup.
- Manifest: names, counts, total size
- Readme: who, when, which versions, where finals live
Verifying before anything is deleted
The step many teams skip is verification. Before working files are removed from the production drive, we practise a short routine: open the archived project from the archive location, check that media links resolve, play the final exports from start to finish and compare file counts with the manifest.
This takes less time than people expect, and it catches the quiet failures: a missing font, a proxy file that was never replaced, a final export that stopped halfway through a copy. Finding these while the original drive is still connected costs minutes. Finding them a year later can cost the project.
In class we pair learners so that one prepares the archive and the other tries to open it cold, without help. That second person is the real test of a handover, and it is the closest we can get to the colleague who inherits the project in practice.
- Open the project from the archive copy
- Play every final export in full
- Compare counts against the manifest
Walking a colleague through it
The module ends with a short walkthrough. The learner sits with a colleague, hands over the checklist, manifest and readme, and explains where things are and why. Ten or fifteen minutes is usually enough, and the questions the colleague asks show quickly which parts of the handover were unclear.
We treat those questions as edits to the checklist. If someone asks where the licensed music is kept, the checklist gains a line for it. If nobody can tell which cut was approved, version naming goes onto the list. Over a few projects the document becomes a precise record of how your team actually works.
This is also where permissions and ownership get settled: who may restore the project, who approves deleting working files, and who is named as the contact for the archive. Writing those answers down is part of the handover, not an optional extra.
Choosing what to adopt first
If your team has nothing in place, start with the checklist and the readme. They cost nothing, take an afternoon to draft and improve every project that follows. Add the manifest once the routine feels natural, and make verification a fixed step before any working files are cleared.
If you already have a handover habit, test it with the cold-open check: ask someone who was not on the project to find the final deliverables and the approved cut using only your notes. Whatever slows them down is the next thing to fix.
These methods are the ones we teach because they hold up under deadline pressure and across different kinds of shoots. They are small enough to keep using, which is the only measure of a handover method that counts.
A reliable archive handover rests on four plain tools: a short checklist, a manifest, a readme and a verification pass, finished with a walkthrough for a colleague. None is complicated, and together they let a project be opened and understood long after the team has moved on. Start with the checklist this autumn, test it on one closing project, and let the questions your colleague asks shape the next version.
Send us a message
- Call us
- (505) 214-0873
- By email
- [email protected]