How photographers manage 10,000+ images without chaos

A working wedding photographer shoots 1,500-3,000 photos per event. Multiply by 30-50 weddings a year and you’re looking at 75,000 to 150,000 images annually. Without a system, that’s career-ending chaos. With one, it’s a smooth machine. Here’s what actually works.

The 4 stages of a photo’s life

Every image in a pro workflow goes through four predictable stages. The naming and folder system needs to support all four:

Capture — RAW files come off the card with camera-default names.
Cull & edit — keepers selected, edited in Lightroom/Capture One.
Deliver — exported JPEGs sent to client, posted online.
Archive — kept long-term in case the client comes back in 5 years.

A name like IMG_4521.NEF survives stage 1. By stage 4 it should look like 2026-04-26_smith-wedding_001.jpg. The transformation happens at well-defined moments.

Folder structure for a working photographer

The structure that scales from 1 wedding to 10,000:

~/Photos/
├── 01_Active/                          ← currently editing
│   └── 2026-04-26_smith-wedding/
│       ├── 01_raws/                    ← original NEF/CR3/ARW
│       ├── 02_selects/                 ← culled keepers
│       ├── 03_edited/                  ← finished JPEGs
│       └── 04_delivered/               ← what the client got
│
├── 02_Archive/                         ← finished, long-term storage
│   └── 2026/
│       ├── 2026-01_jones-wedding/
│       ├── 2026-02_corporate-acme/
│       └── 2026-04_smith-wedding/
│
└── 03_Personal/                        ← not work

Each shoot lives in one folder, named YYYY-MM-DD_event-slug, with a fixed sub-structure. After delivery, the entire folder moves from 01_Active/ to 02_Archive/YYYY/.

This is the system most pros converge on. It works because:

The folder itself encodes date + event in the name.
Sub-folders correspond to the stages of work.
Archive is browsable by year, then by event.
Nothing is lost: even after archive, raws + selects + edits + delivered are all together.

Naming inside the folder

Inside the shoot folder, all files use a consistent prefix:

2026-04-26_smith-wedding_001.nef
2026-04-26_smith-wedding_001.jpg
2026-04-26_smith-wedding_002.nef
...

That _001, _002 counter is continuous across the whole shoot, not restarted per sub-folder or per camera. Why: the same image number always refers to the same moment, regardless of whether you’re looking at the RAW, the edited JPEG, or the delivered version.

Renaming 2,000 RAWs from IMG_4521.NEF to 2026-04-26_smith-wedding_001.NEF is the kind of task that takes 90 minutes manually. With a browser-based batch renamer, it’s 30 seconds: drop the folder, set the rule, export.

When to rename: as early as possible

Tempting to leave files as IMG_4521 until you deliver. Don’t. Rename at import time, before culling. Reasons:

Lightroom catalog references the renamed files; if you rename later, you have to relink.
You can search by event name from day one.
Backup tools see consistent names.

The pro workflow:

Card → import folder (raws still camera-named).
Batch rename to YYYY-MM-DD_event_NNN.ext — including RAW + JPEG sidecar pairs.
Import to Lightroom catalog.
Cull, edit, export.
Move folder to archive.

Step 2 is the multiplier. Skip it and pay later.

RAW + JPEG pairing: the silent killer

If you shoot RAW + JPEG simultaneously (most pros do), you get pairs:

IMG_4521.NEF
IMG_4521.JPG
IMG_4522.NEF
IMG_4522.JPG

Renaming them independently breaks the pairing. After rename:

2026-04-26_smith-wedding_001.NEF   ← was IMG_4521.NEF
2026-04-26_smith-wedding_001.JPG   ← was IMG_4521.JPG (correctly paired)
2026-04-26_smith-wedding_002.NEF   ← was IMG_4522.NEF
2026-04-26_smith-wedding_002.JPG   ← was IMG_4522.JPG

Critically, both members of the pair must get the same number. Most batch renamers (including Namyfixer) handle this if you process the whole folder at once with consistent sorting — but always verify before deleting originals.

Cameras with DNG sidecars (Leica, some Nikon) and XMP metadata files behave the same way. Treat each .xmp as paired with its primary file.

Backups: the 3-2-1 rule

10,000 images is also 100-500 GB of data. Lose it once, lose your business once.

The standard:

3 copies of every image
on 2 different storage media
with 1 copy off-site

Example setup:

Working drive (NVMe SSD in your laptop): copy 1.
External RAID drive at home: copy 2 (different medium).
Backblaze B2 / cloud cold storage: copy 3, off-site.

Sync the working drive nightly to the RAID. Sync the RAID weekly to cloud. Done.

What to delete (and what to never delete)

A controversial topic among photographers. The middle path:

Always keep:

All RAWs from delivered shoots, forever. Storage is cheap; client requests for “the unedited photo from 2019” do happen.
All delivered JPEGs.

Delete after 6 months:

Obvious rejects from culling (closed eyes, blurry, accidental triggers). Lightroom’s “rejected” flag plus a periodic “delete rejected from disk.”

Never keep:

Personal test shots and gear comparisons after they’re done serving their purpose.

This typically halves your storage compared to keeping everything.

When the catalog itself goes wrong

After 5 years and 100,000 images, your Lightroom catalog can become slow, corrupt, or just unwieldy. The pro workaround: one catalog per year.

catalog_2024.lrcat
catalog_2025.lrcat
catalog_2026.lrcat

Smaller catalogs = faster Lightroom = fewer corruptions. You can always export search results across catalogs if needed.

TL;DR

Folder per shoot, named YYYY-MM-DD_event-slug/, with fixed sub-structure.
Rename at import: event_NNN continuous counter, RAW + JPEG paired.
3-2-1 backups, no exceptions.
Keep RAWs forever; cull rejects after 6 months.
One Lightroom catalog per year if you’re shooting at scale.

For the renaming step — by far the highest-friction part of the workflow — try Namyfixer. Drop your import folder, hit export, get back to editing.