Replatforming is the one project where product images quietly cost you the most money. Everyone plans the theme, the checkout and the URL redirects. Almost nobody plans the images — and then, two weeks after launch, half the catalogue is showing grey placeholders, Google Shopping starts disapproving items, and the old CDN that everything still points at gets switched off.
This guide covers moving a product image catalogue between platforms — Shopify, WooCommerce, BigCommerce, Wix, Squarespace, or a custom build — without breaking photos, feeds or rankings. It is written for sellers doing the migration themselves or supervising an agency doing it for them.
Why images break during a migration
Images fail in migrations for four predictable reasons, and every one of them is avoidable:
- The old image URLs die too early. Most importers do not copy image files. They copy image links, then download from those links. If the old store is already offline or password-protected, the import silently skips the image and you get a product with no photo.
- Only the first image comes across. Gallery images live in a different column or field on every platform, and a naive export drops everything after image one.
- Alt text and image order are treated as disposable. They are not stored with the file, so they vanish unless the export mapping includes them.
- Downstream systems keep pointing at the old host. Your Google Merchant Center feed, marketplace listings, email templates, blog posts and affiliate feeds all contain hard-coded image URLs from the old domain.
Step 1: Export images as URLs, not as a ZIP
Almost every platform importer wants a publicly accessible https:// URL ending in a real image extension. Shopify's product CSV requires exactly that in the Image Src column — no local file paths, no password-protected links, no Google Drive or Dropbox share pages. If the URL sits behind a login or firewall, the row imports and the image does not, usually with no error at all.
So the practical rule is: keep the old store live and public until the new one is fully populated and verified. The old site is your image host during the transition. Do not cancel the old plan on launch day. Budget one extra month of hosting; it is the cheapest insurance in the whole project.
If the old platform is already gone, you will need to re-host the exported files somewhere public — an S3 bucket, a Cloudflare R2 bucket, or a simple static host — before the import will work.
What your export must contain
A usable export has one row per image, not one row per product, with these fields:
- Product handle or SKU (the join key)
- Full image URL
- Image position or sort order
- Alt text
- Variant SKU, where the image is a variant image rather than a gallery image
Variant images are the field most often lost. On a 40-SKU apparel catalogue with six colourways each, losing variant image mapping means the swatch clicks do nothing and the customer sees the wrong colour. Check this explicitly before you sign off.
Step 2: Know the target platform's limits before you import
Uploading 8000 px, 12 MB masters into a platform that caps at 5000 px means either rejection or silent downscaling you did not choose. Resize before import, not after.
| Platform | Max upload | Practical target | Images per product |
|---|---|---|---|
| Shopify | 5000 x 5000 px, 20 MB | 2048 x 2048 px, 100–300 KB | 250 |
| WooCommerce | Set by your host (commonly 2–50 MB) | 1200–2048 px source, under 200 KB served | Unlimited (gallery field) |
| BigCommerce | No documented platform cap | 1280–2048 px square | Practical limit, not a hard one |
| Wix / Squarespace | Platform-managed resizing | 2000 px longest edge | Varies by plan |
Shopify resizes anything above 5000 x 5000 px automatically, and its official recommendation is 2048 x 2048 px square at 100–300 KB after compression. WooCommerce regenerates its own thumbnail sizes from whatever you upload, so a 1200 px minimum source is the floor if you want a clean 800 x 800 product page image and a 600 x 600 grid image.
This is the point in the project where a bulk resize tool pays for itself. Running a few thousand masters to one consistent square dimension and file size before import — rather than fixing them individually afterwards — is a single afternoon's work with something like PixelPrep, and it means every product in the new store starts life at the same spec.
Step 3: Handle galleries and CSV formatting correctly
Every platform encodes multiple images differently, and this is where most botched imports happen.
Shopify: each additional image gets its own row, repeating the product handle and leaving the other product columns blank. Image Src, Image Position and Image Alt Text are per-row. Up to 250 images per product will import via CSV; videos and 3D models will not.
WooCommerce: the native importer takes one Images column. Multiple URLs go in that single cell, comma-separated and wrapped in quotation marks. The first URL becomes the featured image; the rest become the gallery. Variation images go in the Images column of that variation's own row.
Test with ten products before you run four thousand. Import ten, look at them on the storefront, check the gallery order and the variant mapping, then delete and re-import with corrections. A ten-product test loop costs twenty minutes; a bad four-thousand-product import costs a weekend of cleanup.
Step 4: Redirect the old image URLs
Page redirects get planned. Image redirects get forgotten — and image URLs earn traffic through Google Images, they are embedded in your own blog posts, and they are cited by other sites linking to your products.
Rules that matter:
- Map old image URLs to new ones with 301 redirects, the same as you would for product pages.
- Avoid redirect chains. Each old URL should point straight at its final destination, not through an intermediate hop.
- Verify every destination returns 200. A 301 pointing at a 404 is no better than no redirect.
- Crawl the old site before you switch, so you have a complete inventory of image URLs to map against.
After launch, watch Search Console for crawl errors and 404 spikes for at least six weeks. Image 404s tend to surface later than page 404s because image crawling is lower priority.
Step 5: Sequence the Google Merchant Center changeover
This is the step that catches out even experienced sellers, because Google's own guidance pulls in two directions.
Google Merchant Center wants stable image URLs — no timestamps, no components that change on every feed submission — because every URL change forces a re-crawl and re-evaluation. But it also says that if you genuinely change an image, you should submit a new, unique URL, because an image swapped at the same URL can take up to six weeks to be detected, whereas a new URL is typically crawled within 24 to 72 hours.
During a migration your URLs change whether you like it or not. So sequence it:
- Get the new store fully populated with images and confirm each image URL loads publicly.
- Switch the feed to the new URLs in one clean cut, not gradually, so you do not have half a catalogue in re-crawl limbo.
- For a very large catalogue, pace the update in batches — roughly 10% per day — so crawling stays continuous rather than queuing.
- Keep the old image host alive throughout, so any product still on the old URL keeps serving a 200 rather than a 404 mid-review.
- Check the Merchant Center diagnostics daily for the first week for "image not processed" and "unable to show image" errors.
Also confirm your new images clear Google's current specification: minimum 500 x 500 px, maximum 64 megapixels, maximum 16 MB, in JPEG, PNG, WebP, GIF, BMP or TIFF. The 500 x 500 px floor is enforced from 31 January 2027, so anything you migrate now should already meet it.
Step 6: Find the other places your old image URLs live
Search your content and your integrations for the old domain. The usual hiding places:
- Blog post bodies and landing pages with hard-coded
<img src>tags - Email templates in Klaviyo or Mailchimp, including evergreen automated flows
- Marketplace listing descriptions on eBay, Lazada or Shopee that embed images hosted on your own site
- Meta and TikTok catalogue feeds
- Size charts and infographics referenced across many products
- Any app or spreadsheet that stores an image URL as data
Automated email flows are the sneakiest of these. An abandoned-cart flow written two years ago can sit there silently sending broken product images to real customers for months.
Migration image checklist
- Keep the old store live and public for at least 30 days past launch.
- Export one row per image with product key, URL, position, alt text and variant SKU.
- Crawl the old site to build a complete image URL inventory.
- Resize all masters to one consistent spec before import — square, within the new platform's cap, under 300 KB.
- Import ten test products, verify galleries, order and variant mapping, then run the full import.
- Spot-check 20 random products on the live storefront, including mobile.
- Confirm alt text survived; re-import it if it did not.
- Set 301 redirects for old image URLs, with no chains and no 404 destinations.
- Cut the Merchant Center feed to new URLs once every image loads publicly; batch at 10% per day for large catalogues.
- Search-and-replace old image URLs in blog posts, email flows, marketplace listings and social catalogues.
- Monitor Search Console and Merchant Center diagnostics for six weeks.
- Only then decommission the old host.
The single most valuable line in that list is the first one. Almost every catastrophic image migration traces back to the old host being switched off before the new one stopped depending on it. Pay for the extra month, and everything else on the list becomes fixable rather than fatal.