Quick answer
Write a script when you already know exactly which file goes where, the person running it is technical, it is a one-off, and you have backups and a way to undo.
Use a proper workflow when the filenames are inconsistent, somebody other than you has to resolve the uncertain ones, you need to know a file is not used elsewhere, the run might be interrupted, or you will be doing this again next quarter.
The real question is not plugin versus code. It is whether you have a predictable file operation, or a job that needs a person in the middle and a way back.
When a script is the right answer
- every file maps to exactly one place
- you know the paths or the IDs
- it is a one-time job
- you can test it on staging first
- you already have logging and a way to restore
- nobody non-technical needs to look at it.
WP-CLI is genuinely excellent for this.
A job a script does well
You have a CSV with the source path, the destination, and a checksum for each row. Every row is exact.
The script checks the file exists, backs up what it is about to overwrite, replaces it, logs what it did, and stops loudly if anything is wrong.
That is less work than installing anything.
Where a script starts turning into a product
It gets complicated the moment you need to tidy up inconsistent filenames, produce candidate matches, handle abbreviations, give somebody a screen to make decisions on, deal with files that are new rather than replacements, find out what else uses a file, resolve two files wanting the same place, retry safely, resume after a failure, undo one item, keep a history, import and export decisions, and remember rules between runs.
At that point you are building the thing rather than using it.
Other people change the maths
A developer can edit a CSV.
The person who actually knows whether HRG-2026-v2.pdf is the right file usually cannot, and should not be given a WordPress admin login to find out.
If more than one person needs to resolve mappings, a screen built for that is worth more than it looks.
Safe retries
Scripts can absolutely be safe to re-run. They just have to be written that way.
A good one records enough to answer two questions: did this row already succeed, and is it safe to try again? Those are easy to skip when you are writing something you expect to run once.
Knowing what else uses the file
A script happily overwrites a file without any idea what points at it.
You can add that check. It is real work, across post content, custom fields and page-builder data — and then it is yours to maintain.
Undo
Scripted recovery can be very good: a backup directory, a manifest, checksums, a restore script.
The difference is whether undoing one file is something you built and have to remember how to use, or just something that is there.
How often does this happen?
Once? A script probably wins.
Every month or every term, for the same site? Then the uncertainty repeats too, and remembering last time’s corrections starts to matter more than the execution does.
What each one costs
The script: developer time to write it, testing, maintenance, documenting it for whoever runs it next, and every edge case you have not met yet.
The workflow: a license, learning how it works, and fitting your site into what it supports.
Neither is cheaper in general.
The quick version
Script if the mapping is exact, whoever runs it is technical, it is one-time, and the environment is unusual.
Workflow if the mapping is ambiguous, other people review it, it repeats, you need shared-file checks, and you want undo to be standard rather than something you wrote.
Example: an agency’s quarterly job
Every quarter a client sends 150 files. The names drift. Five departments have renamed things since last time.
A script needs maintaining every quarter, by whoever is free.
Something that remembers the corrections from last quarter gets less work each time, which is the opposite trajectory.
A middle path
It does not have to be one or the other.
Use a review screen to produce an approved list of what goes where, then have a script execute exactly that list.
That splits the human decisions from the machine work, and it is a good fit for a site with unusual storage that still needs somebody to check the mapping.
What any replacement script should have
At minimum: a dry-run mode, an explicit mapping rather than inference, checks that things exist before touching them, a backup before every write, checksums where they help, the ability to resume safely, a structured log, and a documented way to restore.
A script without those is fast, and hard to trust.
When to stop extending it
If every new client or batch adds another branch — a special abbreviation, a different review spreadsheet, a new rule about shared files, another retry case — you are now maintaining a product.
That is usually the point where something off the shelf gets cheaper.
Summary
Use the simplest thing that safely does the job.
Predictable and one-off: write the script. Recurring, with people in the middle: use a workflow built for it.
Related: FTP comparison · Large-batch safety · Agencies