Archiving is the step that gets skipped because nothing bad happens when you skip it. The project folder just stays where it is, and the active folder gets a little longer, and a year later you're scrolling past nineteen dead clients to reach the two live ones.
The cost shows up in two places: navigation gets worse every month, and archived material that was never properly closed turns out to be unusable when you finally need it — missing fonts, broken links, no explanation of what any of it was.
Both problems are solved by the same fifteen-minute close-out.
Close out before you archive
Do these in order, while the project is still fresh:
1. Confirm delivery is complete. Everything the client received is in the deliverables folder, named as they'd recognize it. Compare against the scope in the contract, not against your memory.
2. Consolidate what's scattered. Files in email attachments, in chat, on your desktop, in a shared folder on someone else's drive. Anything belonging to this project that isn't in the folder comes home now. This is the step that matters most and takes the longest.
3. Resolve linked assets. Design files that reference fonts, images, or templates stored elsewhere need those dependencies inside the folder — most design software has a "package" or "collect for output" function that does this automatically. A design file that opens with missing links in three years is a file you can't use.
4. Strip the junk. Delete duplicate exports, abandoned experiments, and the eleven interim JPGs from review round two. Be moderate about this: deleting is irreversible and storage is cheap. Remove the obvious waste, keep anything ambiguous.
5. Note the outcome. One paragraph at the end of the README: what shipped, what went well, what you'd price or scope differently. Written now, this is useful. Written later, it's fiction.
6. Convert what should be permanent. Final documents to PDF, key spreadsheets to a CSV copy alongside the original, presentations to PDF. Proprietary formats age badly; the source file plus a universal-format copy costs nothing and guarantees readability.
Write a manifest
One file at the root of the archived project, ARCHIVE-MANIFEST.md:
# Northwind Design — Brand refresh
Archived: 2025-06-02
Ran: 2025-04-01 to 2025-05-30
Contact at time: Ana Reyes, ana@northwind.example
Contract: 01 Contracts/2025-03-28 Northwind SOW-02 signed.pdf
Value: 4,200 — paid in full 2025-06-01
## What's here
01 Brief — kickoff notes, client-supplied brand material
02 Working — Illustrator source files (fonts packaged), 3 concept directions
03 Deliverables — final logo suite, colour spec, one-page guide (as delivered 5/30)
04 Invoices — INV-0184, INV-0191
## Software and dependencies
Illustrator 2025 files. Fonts packaged in 02 Working/Fonts.
Playfair Display (OFL) and Sofia Pro (Adobe subscription — licence note in 02).
## Notes for future me
Client approves through Tom (CFO), not Ana. Add a week for approvals.
Scope crept in week 3 — quote the guide separately next time.This file is the whole reason an archive is useful. Without it, a folder retrieved in 2029 is a puzzle. With it, it's a resource.
The "software and dependencies" section is the one that saves real time. Knowing which application version created a file, and whether the fonts are inside, determines in ten seconds whether you can open the folder or need to plan around it.
Where the archive lives
06 Archive/
Clients/
2025/
Northwind Design - Brand refresh/
Projects/
2025/
Marketing/
2025/Year folders inside the archive, which is the one place where date-based organization is correct — archived material is retrieved by "roughly when was that" far more often than by category.
Set the archive to read-only for everyone who doesn't need to change it. Archived work that gets edited stops being a record of what happened, which is most of its value. Most drive platforms support view-only permissions on a subtree.
Zipping: when and when not
Zipping a finished project has real advantages — it's one object, it can't be partially modified, and it usually shrinks meaningfully.
Zip when: the project is large, contains thousands of small files, or is genuinely finished with no likelihood of reuse.
Don't zip when: you'll want to search inside it, pull individual assets from it, or reference it regularly. Most search tools can't see inside archives, so a zipped project is invisible to search — which means you have to remember it exists.
Middle path: keep the deliverables folder unzipped and searchable, zip the working files. The finals are what you'll look for; the working files are what takes the space.
If you zip, test that the archive opens before deleting the original. Corrupt zips exist, and the moment you discover one is never convenient.
Retention and the archive
Archiving is not the same as keeping forever. Tag the archived project with its retention tier — permanent, long-term, or short-term — either in the manifest or in the folder name.
Client work generally falls in the long-term tier, tied to the contract's limitation period and your tax retention requirements, which vary by jurisdiction. Personal data inside the project may have a shorter mandated life than the project files around it. That's worth noting in the manifest so that a future retention review doesn't have to reopen everything to find out.
Line one of the manifest can carry it: Retention: keep until 2032 (contract end + statutory period). Contains client customer list — review for deletion 2026.
Verify the archive actually works
Two checks, and almost nobody does them:
The open test. Six months after archiving, open one archived project at random and try to open three files from it — a source file, a deliverable, and a document. This finds format rot, missing fonts, and broken dependencies while you can still fix them.
The restore test. Confirm the archive exists somewhere other than your primary drive, and confirm you can actually retrieve it from there. Archived material tends to be excluded from backup routines precisely because it's large and static, which means the least-frequently-accessed data is often the least-protected.
Archives fail silently. A backup that fails is noticed when you need it; an archive that's quietly corrupt is noticed years later, which is worse.
What to delete, and being conservative about it
Delete confidently:
- Duplicate exports and interim renders
- Cache and temp files from design applications
- Downloaded stock you didn't use and don't have rights to keep
- Video and audio raw files where you have the finished edit and no likelihood of re-editing
Keep even when tempted:
- All correspondence about scope and approvals
- Contract chain and change orders
- Source files, always
- Anything you can't recreate
The asymmetry is stark: keeping something unnecessary costs pennies of storage. Deleting something you needed costs hours or a client relationship. When unsure, keep.
The quarterly archive run
Fifteen minutes, once a quarter. Look at your active clients and projects folders and ask of each: is this actually still live?
Anything finished more than 60 days ago gets closed out and moved. That's it.
The threshold matters — moving things the week they finish is premature, because late requests are common. Sixty days is past the tail of most follow-up and well before you've forgotten the context needed to write a decent manifest.
Next in this series: How to Document Your Business Systems Before You Hire