Quick answer
Replacing hundreds of files safely takes more than a faster upload.
A big run needs to: hold the new files somewhere harmless first, show you where each one is going, be honest about the ones it is unsure about, stop when a file is used elsewhere or two files are aimed at the same place, back up before it overwrites, get through the job without timing out, pick up where it left off if it stops, tell you what happened to every row, and let you undo any single one.
The bigger the batch, the more the last two matter. A run that dies halfway through is only safe if you can tell exactly what it had already done.
Why 500 files is a different problem from 5
A mistake across five files is annoying.
A mistake across 500 is an incident.
At that size: one wrong assumption about naming affects hundreds of rows at once; one timeout leaves you with a half-finished job; one retry can redo work that already succeeded; one shared file can change pages nobody was looking at; and one bad match overwrites the wrong document hundreds of times over.
Know what you have before you start
Before anything is replaced, look at what actually arrived.
Roughly how many are revisions of existing documents, how many are brand new, how many belong in an archive rather than replacing anything, how many are file types that will not work, and how many are duplicates of each other.
You do not need every match settled yet. You need to know what kinds of decisions are in front of you.
Upload first, replace later
Uploading should never mean “go”.
Putting the files somewhere of their own gives you a stable list to work through, and lets you see the count, the file types, the suggested matches, the rows with nothing suggested, and any clashes — all before a single page changes.
Match on the reliable things first
Good matching leans on the things that are hard to get wrong: an exact identifier like a SKU, an exact filename match, an abbreviation you have already explained, or the field a file belongs to.
“These two names look similar” is a useful hint. It is not, on its own, a reason to overwrite something.
Separate the uncertain from the obvious
A 500-file job becomes manageable the moment the uncertain 10% is in its own list and the obvious 90% is out of your way.
The exceptions usually fall into a few kinds: nothing matched, several things matched, a department or product was renamed, the file is new, the file you would be replacing is used elsewhere, or two new files want the same home.
Check again just before writing
Sites change while you are reviewing. Somebody adds a page that links to a file you approved an hour ago.
Anything that would stop a replacement is worth checking again immediately before the write, not only at the point you first looked.
Back up before, never after
The order that matters: find the original, copy it somewhere safe, record where that copy went, confirm it really saved, and only then overwrite.
Do it the other way round and the one moment you actually needed the backup is the moment you did not have one.
It has to be safe to resume
If the run dies after file 37, the retry has to know that file 37 is already done.
That means every row carries its own state — waiting, in progress, replaced, failed, held back — and the run reads that rather than starting again from the top. A retry that redoes completed work is not a retry, it is a second batch.
Work in chunks
Long runs die for boring reasons: PHP timeouts, proxy limits, a closed laptop, memory.
Working through the batch in chunks avoids most of those and gives the job natural places to stop and pick up again. Chunks on their own are not enough, though — they only help if each row is safe to resume, as above.
“Done” is not a result
At the end of a big run you want counts you can act on: how many replaced, how many added as new, how many held back, how many failed, how many still need you.
You should not have to rebuild that in a spreadsheet afterwards.
Undo one file, not the batch
Undo should work on a single row: put file 317 back and leave the other 485 alone.
Your normal full-site backups still matter for the bigger kinds of trouble. This is for the ordinary kind.
Example: a 500-document refresh
A large organization uploads 500 PDFs. The first look says:
- 410 clear matches
- 55 need checking
- 15 new documents
- 10 held back because the file is used elsewhere
- 6 where two files are aimed at the same place
- 4 unsupported file types.
A safe tool does not offer to “run the 500”. It hands you a queue.
After review, say 486 rows are approved. The run works through them in chunks. If it stops partway, it picks up from where each row actually got to rather than starting again.
Checking a big run afterwards
Reconcile the counts against what you approved, open a sample of the files directly, look at everything that failed or was held back, check the cache on a couple of them, and — if it matters — undo one row as a test to prove you can.
Two people, one batch
A big batch raises a question a small one never does: what happens if two people run it at the same time?
The same row should never be replaced twice at once, a run should have a clear “this is running” state, and editing rows while it is executing should not be possible. Otherwise two people can fight over the same file and both believe they won.
Knowing when to stop
A long run should stop, not soldier on, when something systemic breaks: the backup folder becomes unwritable, the database connection drops, the disk fills, or writes start failing one after another.
Pushing through another 300 rows after that only multiplies the damage.
Being able to see what is happening
For a long run you want to know which chunk it is on, the last row that succeeded, why anything failed, how many retries there have been, and how far through it is.
None of that needs elaborate monitoring. It does need the run to keep proper track of itself rather than leaving you watching a progress bar.
Summary
At this size, safety is mostly about keeping track.
The pattern: know what arrived → upload → match → review → re-check → back up → run in chunks → verify → undo selectively.
Related: Bulk replace files · Replacement checklist · Undoing a replacement