How to Archive a Finished Project

Key Takeaways

• Decide the archive's purpose first: legal retention, reuse, or reopening the project. Each keeps different things.
• Keep the deliverables, the project files, the source media, the licences and a read-me. That is the whole list.
• The read-me is the part everyone skips and the only part that makes the rest usable.
• Prune before you archive, not after. Nobody has ever gone back and tidied an archive.
• Two copies in two places, and one of them not in the same building or the same account.
• Test the restore once. An archive nobody has opened is a hypothesis.

Decide What the Archive Is For

Three different reasons produce three different archives, and people conflate them and then keep everything.

Legal or contractual retention. You need proof of what was delivered, when, and under what licence. This archive is small: final files, the signed scope, the licences, the invoices. It does not need project files or rushes.

Reuse. You expect to lift material out of this project for something else: footage, illustrations, a template, a photo library. This archive keeps the source media and the assets in editable form, and it needs good naming far more than it needs completeness.

Reopening. The client may come back for a new cut, a new language version, or an update in eighteen months. This is the demanding one. It needs the project files, the media they reference, the fonts, the plugins, the graphics in editable form, and enough notes for someone to open it without you.

Ask which of the three applies before you start, and be honest. Most projects are the first two. Treating every project as a potential reopen is how a studio ends up paying for twelve terabytes it never touches.

What to Keep

The list is short and it is the same every time.

The final deliverables, exactly as delivered, in their delivered form. Not the export you made afterwards with the small fix; the ones the client actually received, because those are the ones you may need to prove or match.

The project files, if the archive is for reopening. Edit project, design files, After Effects compositions, the DAW session. Consolidated and collected, so they reference media that lives inside the archive rather than a path on a machine that will be reformatted.

The source media that the project files need. Not every card from the shoot, unless the archive is for reuse. The selects and anything visible in the final cut.

The licences and permissions. Music licences, stock licences, model releases, location agreements, font licences. This is the category that turns into a real problem years later, and it is the smallest and easiest thing to keep.

A read-me. One page. Covered below, and it is the difference between an archive and a pile.

Optionally, the brief and the final approved version of the plan, because they explain the choices anyone reopening the project will question.

What to Throw Away

Prune before archiving. Pruning after archiving does not happen.

Intermediate exports. Every version you sent is in the review platform or the email thread; you rarely need v01 through v07 as files. Keep the delivered versions and the last working export.

Duplicate media. Cards copied twice, footage that exists in both the camera folder and the edit folder, a downloads folder full of assets you also have properly filed.

Renders and caches. Preview renders, proxies, conform caches. They are regenerable, they are enormous, and they are the single biggest source of archive bloat.

Unused takes, if the archive is not for reuse. This is the judgment call that saves the most space and the one people find hardest. Be honest about whether anyone has ever gone back for an unused take on a project like this.

Anything you are keeping because deleting feels risky rather than because you named a reason. That instinct is what produces unusable archives, because volume is exactly what makes an archive unusable.

The Read-Me Is the Archive

An archive without a note is a folder of files that require the person who made them.

One page, plain text or markdown, at the top level. It takes ten minutes at the end of a project and it is the entire difference between an archive that works and one that does not.

What it should say:

• What the project was, in two sentences, including the client and the date.
• What was delivered, listed, with where the final files are in this archive.
• Which application and version the project files need, plus any plugins or fonts.
• Where the source media lives inside the archive and how it is organised.
• What is licensed, for how long, and where the licence documents are.
• Anything a future person would get wrong. The one that always matters: which version is actually final, if the folder contains more than one candidate.
• Who to ask, if that is still possible.

Write it in the language of someone who was not there. "Final delivery is in 04_Delivery, three files" rather than "the usual place".

The single most valuable line in most read-mes is which file is final. That is the question people actually open an archive to answer, and folders are bad at answering it.

Two Copies, Two Places

The rules here are old, boring and correct.

Two copies minimum, on different media, with at least one off-site or in a different account. A single drive in a cupboard is not an archive; it is a drive that has not failed yet. Cloud plus a local drive is a reasonable combination for most small studios; two drives in the same building is a fire away from being no copies.

Do not rely on the client's copy. They will lose it, change agency, or reorganise their storage. If you may need it, keep it.

Label the physical media with the project name, the date and what is on it. An unlabelled drive is functionally empty because nobody will plug in six drives to find something.

Write down where the copies are. A one-line index of which projects are on which drive or in which bucket. It is the difference between an archive and an attic.

Test the Restore Once

An archive nobody has opened is an assumption.

Pick one archived project a year and actually restore it. Open the project file, confirm the media relinks, confirm the fonts are there, confirm the deliverables play. It takes half an hour and it is the only way to find out that your consolidate step has been silently omitting something for two years.

The failures this catches are always the same: media that relinked to a local path rather than the archive, missing fonts, a plugin that no longer exists, a project file saved in a version the current software will not open, and licences that expired without anyone noticing.

The plugin and version problem is worth a specific note. Software moves, and a project file from four years ago may not open in the current version. If a project genuinely must be reopenable long-term, archive a flattened, non-proprietary version alongside the native one: a full-quality master, a graded conform, an EDL or XML, and layered assets exported as TIFF or PSD.

When to Archive

At the end of the project, in the same week the final invoice goes out, and not later.

Archiving is a two-hour job on the day and a full day six months later. The reason is memory: on the day, you know which version is final and where the licence is. Six months later, you are reconstructing.

Attach it to something that already happens. The final invoice is the best trigger, because it always happens and it always happens at the right moment. Some studios make the archive a line on the deliverables list, which is even better because it is then scoped and paid for.

Set a retention period. Three years, five, whatever fits your contracts and your storage budget, and then actually delete. An archive with no expiry is a storage bill that only grows, and the material with genuine long-term value is a small fraction of it.

What This Does Not Preserve

An archive preserves the artifacts. It does not preserve the reasoning.

Two years later, someone opens the project, finds the final cut and a folder of unused takes, and asks why the second interview was dropped, why the ending changed, or why the brand colour is not the one in the current guidelines. The files cannot answer any of it. The read-me can carry a line or two, and it is a note rather than a record.

Storyflow is our product and it does not do archiving. It is not storage: no media hosting, no versioned backups, no project-file consolidation, no cold storage, and it should not hold your rushes. Use a drive, a NAS, or cloud storage, and follow the two-copies rule above. The adjacent job is the reasoning: keeping the brief, the references, the rejected directions and the decisions on one canvas so the questions people bring to an old project have somewhere to be answered. Paid-only during early access, with the Free plan landing before the end of 2026, and anyone a paid member invites to a board joins free now.

The Bottom Line

Archiving is a small discipline whose entire value shows up when nobody involved remembers the project.

Decide what the archive is for, because retention, reuse and reopening keep different things.

Keep five things: deliverables, project files, the media they need, the licences, and a one-page read-me. Prune everything else before you archive rather than promising to tidy later.

Write the read-me, and make sure it says which file is final. That is the question people open an archive to answer.

Two copies, two places, labelled, with an index of where things are.

Test one restore a year, because until you have, the archive is a hypothesis.

An archive is not a backup. A backup answers "can I get the file back". An archive answers "can someone else understand this in two years".