Review Migration

Also known as review import, review app migration

Reviews are the one asset in a Shopify stack that cannot be bought back: a thousand of them represent years of orders, which is why changing review apps feels heavier than changing anything else in the store. A migration is two jobs at once. There is a data move, where rows leave one database and arrive in another, and a search event, where the structured data behind your star ratings stops being printed by one app and starts being printed by another. Most migrations that fail, fail on the second job, because the first one looked like it worked.

An export is rarely a complete copy. The rating, the review body, the author name, and the original date travel reliably. Four things often do not. Verified-buyer status is usually derived by the old app from its own order matching rather than stored as a portable flag, so the destination either accepts a verified column or re-derives it by matching reviewer emails against Shopify orders; confirm which, rather than assuming the badges reappear. Photos normally export as URLs pointing at the old app's storage rather than as files, so they resolve only while that account is live: download them before you uninstall. Merchant replies sit in a separate table and are frequently missing from the export. And original dates can be silently replaced with the import date, which resets every recency signal you had.

The mapping column is where migrations break without announcing it. Apps disagree about how a review points at a product: some store the Shopify product ID, some the handle, some a SKU, and none of the three is unconditionally safe. Product IDs are stable but do not survive a catalogue rebuild. Handles are readable but editable, and a product renamed two years ago may carry a handle nobody remembers setting. SKUs live on the variant rather than the product, so a review keyed to one has to be lifted to its parent, and a blank SKU is no key at all. Pick the key both apps genuinely agree on, and check ten products by hand before importing the full file.

The file itself is a plain CSV, one row per review, with roughly these columns: product identifier, rating, title, body, author name, author email, date, moderation status, and sometimes a verified flag and a list of image URLs. Two mechanical details do more damage than anything conceptual. Review bodies contain commas and line breaks, so the file depends on correct quoting and comes apart if a tool resaves it differently. And opening the export in a spreadsheet is how SKUs lose their leading zeros, dates get rewritten into a local format the importer cannot parse, and accented names turn into garbled characters. Keep the original download untouched as the backup.

The star-snippet gap is the part that costs money quietly. Google does not store your ratings. It reads AggregateRating and Review markup from the page on each crawl, so the stars exist only while some app is printing that markup. Uninstall the old app on Monday, populate the new one on Thursday, and every page crawled in between reports a product with no rating. Recovery is not instant: the markup has to be live again and the page recrawled, on Google's schedule rather than yours. The order that avoids the gap is to install and populate the new app while the old one still renders, verify valid markup on real product pages, then remove the old widget, so exactly one set of review markup is live at every moment. Two sets at once is its own defect.

Consider a Shopify merchant selling ceramic pour-over coffee gear: 68 products, 1,900 reviews over four years, averaging 4.6. The export is keyed on the old app's internal product ID, which the new app has never seen, so they build a lookup from a Shopify product CSV and re-key everything to handles. 140 reviews belong to products since merged or discontinued and have nowhere to land, so those are held back rather than force-fitted onto a similar item. Photos arrive as links to the old app's storage, so the images are downloaded while it is still installed, and the original date column is mapped explicitly so the importer does not stamp everything with the day of the move. After import the new widget reports 4.6 across 1,760 reviews, and the shortfall matches the 140 orphans exactly, which is the reconciliation that says nothing else went missing. The old widget stays live three more days, until ten product pages have been checked for valid markup.

Sometimes the honest answer is not to migrate. If the old app offers no export, this is not a migration but starting over, and that should be decided deliberately rather than discovered after uninstalling. With a few dozen reviews, the mapping work costs more than re-collecting from recent buyers. If the catalogue was rebuilt since the reviews were written, the identifiers may no longer exist anywhere, and a mapping that mostly works will misattribute reviews in ways that are painful to unpick later. Peak trading season is the wrong week to cut over, because the cost of a blank product page scales with traffic. And if the reason for moving is that your reviews are invisible to search, confirm the destination renders them into the page rather than inside a widget a crawler cannot read, or the migration relocates the problem instead of solving it. That test applies to every destination app, including ours.

The same test decides how answer engines treat you afterwards. When ChatGPT, Perplexity, or Google AI Overviews weigh whether a product is worth buying, they work from review content they can actually retrieve, and a migration is when that content is most exposed: dates rewritten, verified status dropped, replies gone, text landing inside a widget no crawler reads. Keeping the record intact is not the same as making it legible. Getting the reviews you already have read, corroborated, and cited by search and AI is the separate gap BeyondReviews is built to close, and a migration is the natural moment to fix it rather than carry the same blind spot into the next app.