Shopify Review Migration: The Fields That Break and How to Fix Them

Your star ratings will survive. What frays in a review migration is everything around them: the product each review points at, the date it was written, and the badge that made it credible.

Most migration advice stops at export, import, uninstall. That sequence is right, and how to move reviews between Shopify review apps walks it end to end. This post is the layer underneath: what is actually in the file, which columns decide the outcome, and what to do with the rows that land without a product.

What is actually inside a review export?

A flat table, one row per review, plus a media column that is really a list of URLs.

Judge.me, Okendo, and Loox all export CSV, and the core columns line up more than you would expect: a product reference, a star rating, a title, a body, a reviewer name, a date, and some flavor of status. The vendor fingerprints live in the extras. Okendo files carry datecreated and isverifiedbuyer. Judge.me files carry reviewername, reviewdate, and a metaobject handle. Loox files carry photourl and displayname. Importers that offer automatic detection are reading those header patterns and choosing a column mapping for you.

Open the file in a text editor before you open it in Excel. Spreadsheet apps reformat dates on sight, and a date column that leaves as 2025-11-04T09:12:00Z and comes back as 11/4/25 is a column most importers will reject.

Which fields decide whether the import works?

Five, roughly in order of how much damage they do when they are wrong.

Product reference. This is the field that determines whether a review has a home. Exports carry a Shopify product ID, a handle, a product URL, or some combination. Importers usually resolve the numeric ID first and fall back to the handle. SKU and product title are almost never used as matching keys, which surprises people who assume the SKU is the universal identifier. It is not.

Rating. Required, and almost always an integer from one to five. The one real hazard is a source app that used a different scale or stored half stars. Check the minimum and maximum in your export before you import.

Date. The field most likely to fail silently. Importers that care about correctness want an ISO 8601 timestamp with an explicit timezone, and reject ambiguous slash dates because 03/04/2025 means two different days depending on which country wrote it. If your dates arrive as slashes, convert them before import rather than letting a parser guess. Wrong dates reorder your review feed and quietly damage the "recent reviews" story on every product page.

Verified flag. Worth understanding precisely. When you import a verified-purchase badge, you are importing an assertion the old app made. The new app did not re-check the order. Honest systems record that as source-asserted rather than treating it as their own verification, and it is a distinction you want on your side when someone asks how you know a review is real.

Body and title. These transfer well. The failure mode is encoding, not mapping: smart quotes, emoji, and non-Latin characters that arrive as mojibake because a step in the chain assumed the wrong character set. Spot-check a review in every language you sell in.

Two more that behave differently from the rest. Media is usually a list of URLs pointing at the old vendor's CDN, so a destination that stores references rather than copying files leaves you depending on an app you are about to uninstall. Ask what happens to those images, and consider archiving them yourself. Merchant replies often export as a single column next to the review, which means they transfer, but threaded conversations with several replies rarely survive as a thread.

Why do some reviews arrive without a product?

Because the reference in the file did not resolve in the destination store.

The usual causes, in rough order of frequency:

1. Handles changed. You renamed a product, and the export carries the old handle.
2. Products merged or were rebuilt. The reviews point at IDs that no longer exist.
3. The catalog is not fully synced. The destination app can only match against products it knows about, so a partial catalog sync produces unmatched rows that would have matched fine an hour later.
4. Wrong store. Reviews exported from a development or regional store carry IDs that mean nothing in the destination.

What matters is what the importer does with those rows. Discarding them is the bad outcome, because the count reconciles to a smaller number and you have no list of what went missing. The better behavior is to import the row, count it, and label it as needing a product match, so the gap is visible and recoverable. AgentReady's importer does the second thing, then gives you somewhere to fix it. Unmatched rows are kept, counted, and collected in a "Reviews waiting for a product" card that shows the product reference the file actually carried and which rows used it, so you attach the right synced product by handle instead of guessing at what went wrong.

The repair edits the review in place, keeps whatever moderation status you had already chosen, and refreshes that product's storefront snapshot if the review was already published. It also recomputes the row's fingerprint, so a later corrected re-import collides with the repaired row instead of adding a second copy, and when it cannot prove which fingerprint the row started with it says so rather than guessing quietly.

Correcting the product reference in your CSV and re-importing does the same job, and it is the better move when hundreds of rows share one broken handle. Either route depends on re-importing being safe, which brings us to the part everyone skips.

Is it safe to import the same file twice?

Test it before you need the answer.

Two behaviors make a re-import safe. The first is file-level: the importer hashes the uploaded file and refuses to process bytes it has already processed, so a double click on Upload costs you nothing. The second is row-level and matters more: the importer fingerprints each review from its content (product, rating, title, body, author, date) and skips rows already in the library. With both in place, a corrected re-import adds only the rows you fixed.

Without them, a second upload doubles your review count, and unpicking that by hand across a few thousand rows is a bad week.

Run this test on any destination app before the real migration:

1. Cut a ten-row CSV from your export.
2. Import it. Note the count.
3. Import the identical file again. The count must not move.
4. Change one review body in the file and import a third time. Only that row should be new.

That test takes five minutes and tells you whether the "fix and re-import" loop is available to you at all. Content fingerprinting does have an edge: a review whose text was edited after your first import looks like a new review, so it comes in as a second copy. Correct product references, not review bodies, when you are re-importing.

Why does an exportable copy matter?

Because the reviews are yours, and the export is the only copy you actually control.

Your customers wrote that content because you asked them to. It lives in a vendor's database, rendered by a widget, priced per month. The day you want to leave, the export is the whole negotiation. Two things to check on any review app you are evaluating:

• Can you export everything, on demand, without a support ticket? A CSV of the current table page is not an export.
• Does the export include the fields that matter? Ratings and text are table stakes. Look for the product reference, the date, the verification state, the merchant reply, and the media URLs. An export missing verification state cannot be re-imported anywhere without losing your badges.

Pull one now, before you have a reason to. A current export is the cheapest insurance in your app stack, and it costs one click.

What about the schema during the cutover?

One rating story per product page, always.

During the overlap window you will have two apps installed and, if you are careless, two apps writing rating markup. Google drops the rich result, validators disagree with themselves, and answer engines get two different numbers for one product. Two review apps both adding review schema covers the diagnosis and the fix, and the rule is short: pick one emitter, turn the other off, then re-test.

The same discipline applies to Shopify's shared reviews.rating and reviews.rating_count metafields. They are a single shared namespace, so two apps writing them is two apps overwriting each other. A tool worth installing checks whether that namespace is already owned before it writes anything.

Where does AgentReady fit?

AgentReady Reviews is in a small merchant pilot, and it is deliberately narrow. It imports Judge.me, Okendo, Loox, and generic CSV exports, detects the format from the headers, matches on product ID then handle, and queues unmatched rows for repair instead of dropping them, with the reference the file carried shown next to the fix. Re-importing the same file does nothing, and re-importing a corrected file adds only the corrected rows. Imported reviews land pending until you publish them, you can reply publicly, and you can export the whole library back out to CSV with the fields above intact.

What it does not do today: display reviews on your storefront. There are no AgentReady review widgets, and I would rather say that plainly than let a feature grid imply otherwise. What it does do is the data side, which is the half of the category that tends to go unowned. Approved ratings can be published into Shopify's standard rating metafields and your product structured data, and only after a check confirms nothing else already owns that markup.

If you collect happily with Judge.me or Loox today, keep collecting there. The migration discipline in this post is the same either way.

Where should I start?

Export today. Open the file in a text editor, check the date format, and count how many rows carry a product handle you would still recognize. That five minute read tells you more about your migration risk than any vendor comparison.

Then, whenever you do move, run the double-import test, reconcile unmatched rows before you uninstall anything, and confirm one app owns the rating markup at the end. When the dust settles, check that your ratings are still readable to machines with the free AI-readiness checker, because a clean migration that leaves your ratings trapped in a client-side widget solves half the problem. Whether assistants can see your reviews at all is the other half.