Before removing local product images after a media migration, check that WordPress can still regenerate a thumbnail from an original. Existing CDN images can load perfectly while the source needed for a new size is missing. I include that recovery path in the migration test.
Delivery and rebuilding are different jobs
A CDN can serve the existing small image perfectly while the application no longer has the source it needs to create a new size. A successful homepage check would miss that problem. I include regeneration in the recovery checks before deciding that local originals can be retired.
I keep recovery of missing originals inside a controlled media-regeneration workflow. Ordinary shop visits and admin page loads should not unexpectedly start a remote transfer. Those requests need predictable response times, not a surprise remote transfer.
Recover only what is expected
I restricted the recovery path to the approved public media source and recognised historical image paths inside the uploads directory. Existing local files were left alone. This was not a general downloader for arbitrary URLs supplied by a request.
The transfer went into a temporary file, with an expected response status, a size limit and a length check where the server supplied one. Only a successful download was moved into its final location. A half-downloaded original must not look like a valid source to the image processor.
Verify the original and the new sizes
For the trial I retained the known local files in a protected recovery location, ran regeneration and checked that the recovered original matched the expected bytes. I then checked the generated image files, their publication to storage and the URLs the browser would use.
That last step matters when an image optimiser produces WebP or AVIF files alongside WordPress’s normal sizes. A sync process which follows only one metadata list can miss useful derivatives. I check the files the site actually emits, not just whether the upload job returned success.
Keep fresh files until a fresh backup protects them
An independent backup taken before regeneration cannot be assumed to contain the newly generated object versions. I retain the recovered and regenerated local files until a later backup protects those versions and the recovery route is understood.
I also keep private shop downloads outside this public-image process. The fact that product photographs are meant for everyone says nothing about files a customer should only receive after purchase.
Be precise about what was tested
A command-line regeneration check does not establish that every plugin’s admin button or background image queue can recover missing sources. I keep originals where an untested workflow still depends on them.
This extends my earlier note on moving WordPress media to object storage safely: verify not only today’s delivery, but the maintenance work the site will need tomorrow.