Archive checklist template

What this is about

The archive decision is usually made by nobody, which is how productions end up paying for storage they cannot use. Keeping everything sounds safe and is the most expensive option; keeping only the master sounds lean until a cutdown is requested and the project file is gone. The realistic middle is deliberate: the finished masters and their textless versions, the project files with the media they reference, the rights documents that define what may be done, and enough metadata for a stranger to find a shot. What separates an archive from a pile of drives is that someone has restored from it once.

A template is the starting point, not the goal: once it has been filled in by hand twice, it is worth asking whether the document should come out of the plan instead.

What runs differently here

In planning terms, that means:

• The tiered keep list: delivered masters and textless versions, project files with referenced media, selected source material, and what is deliberately deleted
• Media and locations with at least two independent copies in different places, and a note of which format each copy is written in
• Rights and paperwork stored alongside the media: releases, licences, cue sheet, delivery specification and the signed approval
• A metadata and folder standard that works without the person who built it, including a plain readme naming the project, dates and contents
• Retention and review dates: when each item is looked at again, and whose budget carries the storage until then

Step by step

This order gets you there fastest:

1. Wait until delivery is confirmed and the approval is signed, then decide the keep list deliberately rather than by leaving drives untouched.
2. Consolidate the project: collect the edit project with the media it references, so it opens later without hunting for reconnects.
3. Write the masters and textless versions first, since they are the items most likely to be requested and the hardest to rebuild.
4. Put the paperwork in the same archive as the media — licences, releases, cue sheet, spec and approval — because rights questions arrive without the footage.
5. Write at least two copies to independent media in different physical locations and record which copy lives where.
6. Add a readme in plain text naming the project, the dates, the contents and the software versions used, aimed at someone who was not involved.
7. Restore a random sample from the finished archive and open it, because an untested archive is a hope rather than a backup.
8. Set the retention and review dates, align them with the licence terms and the statutory retention obligations for business records, and note the owner.

Common pitfalls

What most often goes wrong in practice:

• Archiving a project file without its media, which opens years later as a timeline of missing clips
• One copy in one building, where a single flood, theft or failed drive ends the entire history of a production
• No readme and no naming standard, so the material exists but only one former colleague could ever navigate it
• Never testing a restore, which is how a defective archive is discovered on the day it is finally needed

With TillyGen

TillyGen keeps scenes, shots and shooting days connected, so the archive inherits a structure that explains what the material is — rather than a folder tree whose logic left with the person who created it.

Change one constraint and the consequences travel through the whole plan: affected shots are flagged, the call sheet is regenerated, and nobody keeps working from yesterday's version.