Building a Project Handover Checklist Your Archive Can Rely On
A practical walk-through for preparing a finished video project for long-term archive: what to gather, what to record, and how to talk a colleague through it.
Daniel Whitfield · · 6 minutes to read
Start with the question the archive must answer
A handover checklist exists to answer one question for someone who was not on the project: if I opened this in two years, could I find what I need and trust it? Before writing any list, I ask the team to state what a future reader is likely to want. Usually it is the final exports, the project file that produced them, the source footage that was actually used, and a short note explaining decisions that are not obvious from the files alone.
Writing that purpose down at the top of the checklist keeps it honest. Without it, checklists grow into long inventories of everything on the drive, and the person doing the handover stops reading them. With it, every line can be tested: does this item help the future reader, or does it only make the person preparing the handover feel thorough?
In these early autumn weeks many teams are closing out summer shoots, which makes it a good moment to try this on one finished project before the next one starts. Pick a job that is genuinely complete, not one still waiting on a client note, and use it as your pilot.
Gather what belongs in the archive package
Begin by listing the four groups of material: final exports, project files, selected source media and supporting documents. For each group, decide what is kept and what is left out. Final exports should include every delivered version, along with any masters you would need to re-deliver. Project files should be saved in a state that opens cleanly, with the editing software version noted.
Source media is where decisions get difficult. Keeping every camera card is safe but expensive, and it buries the useful material. A reasonable rule is to keep everything the timeline referenced and decide separately, with the producer, about unused footage. Whatever you choose, write the rule down so the next project follows the same one.
Supporting documents are the quiet part of an archive and the part most often missing. Music licences, release forms, delivery specifications and client approvals all belong next to the files they relate to. Collect them into one clearly named folder rather than leaving them scattered across email threads.
- Final exports, every delivered version
- Project file saved and tested to open
- Source media the timeline actually used
- Licences, releases and approval notes
Check the package before it is closed
Once everything is gathered, run a short set of checks. Open the project file from the archive copy, not from the working drive, and confirm that media links resolve. Missing links are the most common surprise, and it is far better to find them now than when someone needs the project after the original drive has been wiped.
Next, play each final export from start to finish, or at least scrub through it, to confirm the file is complete and matches the version name. Check file names against your naming convention and look for stray duplicates, such as copies labelled final, final2 or new. Remove or clearly mark anything that should not be treated as current.
Finally, confirm permissions. Decide who may read the archived project and who may change it, and apply that before the folder is closed. An archive that anyone can edit slowly stops being an archive. Record the check in the checklist with a date and the initials of the person who did it.
Write the handover note in plain language
The handover note is a single page, written for a reader who knows video but not this project. Open with the project name, client, delivery date and the location of the archive package. Then describe the structure in a few sentences: where exports live, where the project file sits, and how the folders are named.
Add the things the files cannot say for themselves. Which cut was approved? Were any shots replaced late? Is there a colour or audio pass stored separately? Are there fonts or plug-ins the project depends on? These small facts are exactly what disappears when a team moves on, and they take minutes to record while the work is fresh.
Keep the tone matter of fact and avoid shorthand that only the editor would understand. If a term needs explaining, explain it. A good test is to hand the note to someone outside the project and ask them to point to the final export without help. If they hesitate, the note needs another pass.
- Project name, client and delivery details
- Archive location and folder layout
- Approved cut and any late changes
- Software versions, fonts and plug-ins
Walk a colleague through it
The last step is the one most teams skip: a short walkthrough with a colleague who was not involved. Sit with them, share the archive package and the note, and let them do the navigating. Your job is to stay quiet and watch where they slow down. Every pause points to a gap in the structure, the naming or the note.
Ask them to complete three small tasks: find the final export, open the project file, and locate the licence for the music. Time is less important than confusion. If they need to ask you where something is, write down the question and fix the checklist or the note so the answer is already there next time.
Ten or fifteen minutes is usually enough. Afterwards, update the checklist with what you learned and mark the project as handed over. Over several projects the walkthrough becomes quick, because the same questions stop coming up and the checklist has absorbed the answers.
Keep the checklist alive
A checklist is only useful if it is used, and used means revised. After each handover, spend a few minutes noting what was awkward and adjust the list. Remove items nobody needed and add the ones people kept asking about. A short, current list beats a thorough one that nobody trusts.
Store the checklist where the team already works, next to the archive template, and give one person the job of keeping it current. That person does not have to do every handover, only make sure the list reflects how the team actually works rather than how it once intended to.
Review it again when your tools change, whether a new editing application, a new storage location or a new delivery format. These changes quietly break old assumptions, and a quick read-through of the checklist is a cheap way to catch them before an archive is closed with something missing.
A good handover is not a large task, but it does need to be done the same way each time. Define what the future reader needs, gather the package, check it opens, write a plain note and let a colleague test it. Then improve the list. Done on a few projects, this becomes routine, and your archive stops being a pile of drives and becomes something a stranger could pick up and use with confidence.
Send us a message
- Call us
- (505) 214-0873
- By email
- [email protected]