Where to Keep Original Files After Client Delivery

A finished job produces three copies with three different owners, three different purposes and three different lifespans. Say the names out loud and the storage decision stops being one decision and becomes three easy ones.

Most studios have two of these and believe they have all three. The usual missing one is the client's copy, because the client was shown a gallery and everyone assumed that settled it. The second most common gap is the archive copy: the working drive is quietly serving as the archive, which means the archive has no second copy and is stored on the device that gets used, dropped and replaced most often.

One more thing worth being blunt about. The gallery the client browses is none of the three. It is a viewing surface. Proof images are compressed for fast viewing, so they are not the client's copy of the work, and they are not your archive of the originals either. Check what your own platform actually stores before you treat a live gallery as a backup. On clientgallery.io it is not one, and the next section sets out exactly what is held and for how long.

This is the single most valuable instruction on this page, and it costs one paragraph in your delivery message. Tell the client to download their files and keep their own copy, and tell them where to keep it. Not "the files are available". An instruction, with a destination.

The reason is that your archive is a courtesy, not a guarantee. In three years a laptop dies, and the message that arrives says "you still have these, right?". If you told them at delivery, in writing, that the copy is theirs to keep, that conversation is a short and friendly one whatever the answer turns out to be. If you never said it, you are the one who lost their wedding.

Something close to this, adjusted to your own periods:

Your full-resolution files are ready to download from the gallery. Please download them now and keep your own copy in two places, for example an external drive plus one cloud account you already pay for. I keep a copy for [period] and I can put the download back up any time you ask, but the copy that is always there is yours.

With clientgallery.io the mechanics behind that message are worth stating plainly, because the message should describe what actually happens.

Read the second row as a handoff window rather than a limitation to apologise for. The three days are the period in which a client who has just been told to download their files actually downloads them. If they miss it, or come back a year later, you re-upload the ZIP and send the same link again. What does not happen is a permanent full-resolution mirror sitting on someone else's hardware, and that is the reason the price is one flat number instead of a storage ladder.

The proofs are a different matter. They stay up for as long as the account exists, which is why the gallery remains a useful place to point a client who wants to look at their photographs rather than download them. More on that distinction in how to send full-resolution photos to a client.

The working copy is the RAW originals, the catalog and whatever exports are still in flight. It belongs on the fastest storage you own, and it belongs there for exactly as long as you might still be editing. The mistake is to tie that to a month, because a month is not a fact about the job.

Pick an event instead. The working copy moves when one of these fires, whichever comes first:

• The client signs off on the delivery.
• The contracted revision round is used up.
• The album is ordered, or the licence period starts running.
• A stated number of days passes after delivery with no reply, and that number is in your delivery message so the silence means something.

Until then, leave it alone. Re-editing from an archive is slow enough that you will quietly start refusing reasonable requests, and that costs more than the drive space.

Two practical notes. Move the job rather than copying it, because a working copy that survives the archiving step is how a drive fills up with things you already archived. And batch the moves: a folder called To archive, emptied once a month, is the version of this habit that survives a busy season, whereas doing it per job means doing it while tired at the end of a delivery.

One warning worth stating flatly. The working copy is not a backup. If the job exists in exactly one place right now, the archive step is not tidying, it is overdue.

The archive copy is the one that has to survive being ignored. Two copies, on two separate devices or services, in two separate places, is the floor. One copy is not an archive, and two copies in the same room is one copy with extra steps.

What belongs in it:

• The RAW originals worth keeping. Not every frame. The keepers, the near-misses you might revisit, and anything with a person in it you would not want to have to re-shoot.
• The delivered full-resolution masters. Exactly what the client received, unchanged. This is the file a reprint request needs, and it is the one that proves what was delivered.
• The catalog and the edit history. The catalog file and the sidecar files that carry your develop settings. This is the section people skip and regret.
• The paperwork. Contract, model release, invoice, licence terms. It weighs nothing and it is what answers a usage question years later.
• A manifest. One plain text file at the top of the folder.

The manifest is what turns a folder into an archive. Keep it to one screen, in plain text rather than a document format, because plain text opens in every decade. Client name and a contact address. Shoot date and location. Session type. What was delivered, how many files, and on what date. Licence terms and when they expire. Your retention date for this job. And where the other copy of this folder lives.

That last line is the one nobody writes and everybody needs. An archive whose second copy is a mystery is a single copy you feel good about.

Which medium the archive lives on, and what it costs per terabyte, is a separate decision that does not have to be made this week. The options and their real costs are compared in affordable archive storage for a photography studio. Any pair of destinations you will actually keep paying for beats the perfect plan you postpone.

Archiving the working folder as it stands is the default, and it is wasteful in both directions: it carries gigabytes of files that regenerate themselves, and it often loses the few megabytes that cannot be regenerated at all.

Now the part that runs against instinct. The catalog and the edit history look like software clutter, and they are the first thing most people delete. Keep them.

They are tiny. Measured against the RAW files in the same folder they round to nothing. And they are the only record of the work you actually did: the crop, the colour, the local adjustments, the thing that makes the image yours rather than a developed sensor read. A reprint in five years that has to match the print already on the client's wall needs those settings, and a re-edit that starts from a raw file with no history is not a re-edit, it is a re-shoot at a desk.

The rule underneath is short. Previews regenerate. Edits do not. Strip the things a computer can rebuild, keep the things only you produced.

In five years you are the stranger. You will not remember the bride's first name, whether the corporate job in the spring was the headshots or the factory floor, or which of two folders is the real one. Name for that person, not for the one who just finished the edit.

A folder name that works has three parts, in this order:

• Date first, as year, month, day. It sorts chronologically on every system without anyone configuring anything.
• Client name second. It is what you will type into a search box, because it is the only thing the incoming email will contain.
• Session type third. It separates the two jobs you shot for the same client in the same month.

So 2026-06-14_Tremblay_Wedding rather than Tremblay final, and 2026-03-02_NordCo_Headshots rather than March corporate. Skip spaces and accented characters if the archive will ever cross between operating systems, and never rename a folder after archiving, because the manifest and your client records both point at the old name.

Inside, use the same subfolders every time, so the shape is predictable before you open anything: originals, delivered, catalog, paperwork, and the manifest at the top level. An archive that cannot be searched is an archive that gets re-shot, and the client pays for that twice.

Read your contract first. If it promises availability for a period, that period is the floor for every job already signed, whatever you decide from here.

If the contract says nothing, write two periods into it: one for RAW originals, one for delivered masters, plus a line placing backup responsibility with the client. Two periods rather than one, because a re-edit request and a lost-files request are different problems. The periods themselves, and the warning email to send before anything is deleted, are worked through in how long photographers should keep client photos.

What belongs here is the reason a written period matters even when your files sit on a consumer cloud subscription you have paid for years. A storage subscription is not a retention policy. Two of the largest providers publish exactly what happens when an account drifts over its quota.

Both say "might" or "may" rather than "will", and that is the point: neither is a threat, and neither is a promise to keep your files. Going over quota is not an exotic failure either. It is what happens to an archive that grows every season while the plan does not, or to an account whose card expired on a phone you replaced. A retention period you chose, wrote into the contract and told the client about survives that. A subscription you assumed would hold everything indefinitely does not.

• Google Drive Help, "What happens if you exceed your storage quota": https://support.google.com/drive/answer/6374270 (fetched 9 September 2026)
• Dropbox Help Center, "Downgrade your Dropbox individual plan": https://help.dropbox.com/plans/downgrade-dropbox-individual-plans (fetched 9 September 2026)

clientgallery.io figures on this page describe the product as built on 9 September 2026 and are verified in its own code and pricing page.