{"id":4259,"date":"2026-10-08T07:39:41","date_gmt":"2026-10-08T07:39:41","guid":{"rendered":"https:\/\/www.liquidwebdevelopers.com\/blog\/?p=4259"},"modified":"2026-10-19T10:47:15","modified_gmt":"2026-10-19T10:47:15","slug":"migrating-product-reviews-between-platforms","status":"publish","type":"post","link":"https:\/\/www.liquidwebdevelopers.com\/blog\/migrating-product-reviews-between-platforms\/","title":{"rendered":"Migrating Product Reviews Between Platforms"},"content":{"rendered":"

Reviews are the most commonly lost asset in a migration, and the loss is usually discovered afterwards.<\/p>\n

The reason is structural. Reviews rarely live in your store’s core data. They live in an app or plugin with its own storage, and migration plans<\/a> are built around products, customers, orders, and content \u2014 the things that appear in the platform’s own export. Reviews sit outside that list, so nobody checks the path until the switch has happened and the product pages are bare.<\/p>\n

The cost is larger than it looks, because it lands twice.<\/p>\n

<\/span>Why this matters more than people think<\/span><\/h2>\n

Conversion.<\/strong> Reviews are among the most reliable conversion<\/a> levers available, and their effect is strongest exactly where hesitation is highest \u2014 expensive items, unfamiliar brands, products where fit or quality is uncertain. A product page going from 40 reviews to zero does not lose a decoration. It loses the thing that was answering the customer’s actual question.<\/p>\n

Search star ratings.<\/strong> Reviews generate review and aggregate rating schema, which is what produces star ratings in search results. Those stars measurably lift click-through. Lose your reviews and you lose the stars, which means a meaningful drop in traffic at unchanged rankings \u2014 the most invisible kind of loss, because your position reports look fine.<\/p>\n

Years of accumulated work.<\/strong> You spent months or years collecting those reviews through request emails, follow-ups, and incentives. Rebuilding that volume takes as long again.<\/p>\n

Content.<\/strong> Review text contains the language customers use about your products, which is useful for copy, for search, and for understanding your own catalogue.<\/p>\n

So treat reviews as a first-class migration asset, on the same footing as your product data<\/a>.<\/p>\n

<\/span>Establish the path before you commit<\/span><\/h2>\n

The order of operations here matters, and most stores get it backwards.<\/p>\n

Do not choose your new review app first and check the import path second.<\/strong> Check the path first, then choose from what is actually viable. A slightly less impressive app that imports your 4,000 reviews beats a better one that does not.<\/p>\n

Find out where your reviews currently live.<\/strong> Native platform functionality, a plugin, or a third-party app with its own database. This determines what you can extract.<\/p>\n

Test an actual export.<\/strong> Not the documentation \u2014 run the export and look at the file. You need to know which fields you actually get, because the fields determine how much survives.<\/p>\n

What you want in that export:<\/strong> product identifier, rating, review title, review body, reviewer name, reviewer email, review date, verified purchase status, images or video, replies from you, and helpful votes. Most exports carry the first six. Later fields are where losses happen.<\/p>\n

Then check the destination’s import.<\/strong> Which fields does your chosen app accept, in what format, and does it support the fields you have? Ask support directly with your actual file rather than relying on a feature list.<\/p>\n

Test with a sample.<\/strong> Import fifty reviews before committing to the full set, and check what arrived intact.<\/p>\n

<\/span>What typically gets lost, and what it costs<\/span><\/h2>\n

Review dates.<\/strong> The most common and most damaging loss. If reviews import with today’s date, four years of accumulated social proof appears to have arrived this week, which reads as manufactured \u2014 precisely the opposite of what reviews are for. Verify date preservation specifically, and treat it as a requirement rather than a preference.<\/p>\n

Verified purchase badges.<\/strong> These carry real weight with customers, and the flag often does not survive. Some apps can re-derive it by matching review emails against your order data, which is worth asking about.<\/p>\n

Photos and videos.<\/strong> Customer images are among the most persuasive review content and the most likely to be lost, because they are hosted by the old app and the export usually contains links rather than files. If your reviews carry many images, establish this early \u2014 you may need to download them before you lose access.<\/p>\n

Your replies.<\/strong> Public responses to reviews demonstrate that you engage, particularly on critical reviews where a good reply converts a negative into a positive signal. Frequently not exported.<\/p>\n

Product associations.<\/strong> Reviews link to products by identifier, and if your product IDs or SKUs change during migration, the mapping breaks. You may end up with reviews attached to the wrong products or to nothing. This is a specific and unpleasant failure, and it requires building a mapping table between old and new product identifiers before importing.<\/p>\n

Reviewer emails.<\/strong> Needed for verified purchase matching and for any future review requests to those customers.<\/p>\n

Helpful votes and sort order.<\/strong> Minor, but it affects which reviews customers see first.<\/p>\n

Multi-language reviews<\/strong>, if you sell internationally, and their locale association.<\/p>\n

<\/span>The sequence<\/span><\/h2>\n

Inventory what you have.<\/strong> Total review count, count with photos, count with replies, date range, and average rating. You need these numbers to verify the import later \u2014 “it looks like they came across” is not verification.<\/p>\n

Export early, and keep the file.<\/strong> Do this while you still have full access to the old app. Stores that cancel the old subscription before exporting lose everything, and it happens.<\/p>\n

Download review images if they are hosted by the old app.<\/strong> Before access ends. This is the item most often realised too late.<\/p>\n

Build a product mapping table<\/strong> if identifiers are changing: old ID or SKU to new ID or SKU. This is what keeps reviews attached to the right products.<\/p>\n

Choose the destination app based on import capability<\/strong> as well as features.<\/p>\n

Test import a sample of fifty<\/strong>, deliberately including reviews with photos, with replies, with unusual characters, and from your oldest date range.<\/p>\n

Verify the sample thoroughly:<\/strong> correct product, correct rating, correct date, correct reviewer name, photos present, replies present, verified badge where applicable.<\/p>\n

Import the full set,<\/strong> then reconcile against your inventory numbers. Count, date range, average rating, photo count. Discrepancies mean something silently failed.<\/p>\n

Verify schema output.<\/strong> Load product pages and confirm review and aggregate rating schema is emitting correctly, with a structured data<\/a> testing tool. This is the step that protects your search stars, and it is skipped almost universally.<\/p>\n

Check display on the storefront.<\/strong> Reviews appearing in the admin does not mean they render. The widget needs placing in your theme.<\/p>\n

Monitor search appearance for a few weeks.<\/strong> Star ratings may take time to reappear, but they should reappear. If they do not after a month, your schema is wrong.<\/p>\n

<\/p>\n

<\/span>A worked example: the stars that vanished<\/span><\/h2>\n

A skincare brand migrating to Shopify<\/a> had around 6,800 reviews across their catalogue, with an average of 4.6 and a large number carrying customer photos \u2014 before-and-after images that did a great deal of their selling.<\/p>\n

Their migration moved the reviews. The count was right, the ratings were right, and everybody signed it off.<\/p>\n

Two things had not come across. Every review carried the import date, so a four-year review history appeared to have been collected in a single week. And the photos were gone, because the export contained links to the old app’s hosting and those links stopped resolving when the subscription ended.<\/p>\n

Conversion fell 14%. Separately, their star ratings disappeared from search results, because the new app’s schema was not configured on their theme \u2014 the reviews rendered, but the markup was absent. Organic click-through fell noticeably at unchanged rankings, which took a while to diagnose precisely because nothing had moved in the ranking reports.<\/p>\n

Recovery was partial. Dates could not be restored \u2014 the original data was gone with the old subscription, and reconstructing 6,800 dates was not feasible. They set the review app<\/a> to hide dates entirely, which was the least bad option available.<\/p>\n

Photos were partly recovered from a database backup the old vendor still held, after some persuasion. Roughly 60% came back.<\/p>\n

The schema was fixed in an afternoon, and stars returned within three weeks.<\/p>\n

Two hours of checking before launch \u2014 verify dates in a test import, download the images, validate the schema \u2014 would have prevented all of it. The reviews had been treated as a count to reconcile rather than an asset to preserve.<\/p>\n

<\/span>If reviews cannot be migrated<\/span><\/h2>\n

Sometimes the path does not exist. Options, in order of preference.<\/p>\n

Reconsider the destination app.<\/strong> If your preferred app cannot import and another can, the import capability is worth more than the feature difference. This is the right answer more often than people accept.<\/p>\n

Ask both vendors directly.<\/strong> Support teams sometimes have migration paths that are not documented, or will build a one-off import for a large enough review set. Worth an email.<\/p>\n

Consider a manual or scripted import.<\/strong> If you have the data in a usable export, a developer can often build an import against the destination app’s API even without an official path. For a large review set this is straightforwardly worth the cost, and it is well-defined integration work<\/a>.<\/p>\n

Delay the migration<\/strong> until a path exists, if reviews are central to your conversion.<\/p>\n

Accept the loss deliberately, and plan the rebuild.<\/strong> If you proceed without them, launch an aggressive review collection programme immediately: request emails to recent customers, follow-ups, and a request to your whole customer base explaining that the site has moved and asking them to re-share their experience. That last one works better than people expect, and it is far better than hoping volume rebuilds on its own.<\/p>\n

What you must not do is proceed casually and discover the loss afterwards. If you are going to lose reviews, know it in advance and have the recovery plan ready on launch day.<\/p>\n

<\/span>The product mapping problem, in detail<\/span><\/h2>\n

This deserves expanding because it produces the most confusing failures, and because it is invisible until reviews appear in the wrong place.<\/p>\n

Reviews reference products by an identifier \u2014 a product ID, a SKU, or a handle. When you migrate platforms, those identifiers usually change. Shopify assigns its own product IDs on import, and your handles may differ from your old URLs even when the slug looks similar.<\/p>\n

So a review file referencing product ID 4471 means nothing to the new store, and a review file referencing SKU values only works if your SKUs came across unchanged and unique.<\/p>\n

Build the mapping table during your product migration, not afterwards.<\/strong> When you import products, capture the old identifier alongside the new one. Most migration tools can output this, and if yours cannot, you can reconstruct it by matching on SKU or title \u2014 but matching on title is unreliable where you have similar product names.<\/p>\n

Match on SKU where you can.<\/strong> It is the most stable identifier across platforms, assuming your SKUs are unique and were not regenerated during import. Check for duplicates before relying on it.<\/p>\n

Watch for products that split or merge.<\/strong> If a product exceeded Shopify’s variant limits and was split into several, its reviews need a decision about where they land. If several old products became variants of one new product, their reviews may need consolidating. Neither has an automatic answer.<\/p>\n

Handle discontinued products explicitly.<\/strong> Reviews for products you no longer sell have nowhere to go. You can drop them, or attach them to a successor product \u2014 but only if it is truly the same thing, since attaching reviews of a discontinued formulation to its replacement is misleading.<\/p>\n

Verify a sample by product, not just by count.<\/strong> Pick ten products, note their review counts and average ratings in the old system, and confirm both match after import. A correct total count can still conceal reviews attached to the wrong products, and that error is much worse than a missing review.<\/p>\n

Check your highest-value products individually.<\/strong> Your ten bestsellers carry the most conversion weight. Verify each by hand.<\/p>\n

<\/span>Using the migration to improve your review programme<\/span><\/h2>\n

Since you are already handling this data, a few things worth doing at the same time.<\/p>\n

Audit what you actually have.<\/strong> Review counts by product often reveal that a handful of products carry nearly all your reviews while your newer or higher-margin lines have almost none. That is a collection targeting problem worth fixing, and you will not notice it until you look at the distribution.<\/p>\n

Check your request timing.<\/strong> Most stores send review requests at a default interval that bears no relation to when customers have actually used the product. For consumables, ask after they have had time to form an opinion; for considered purchases, later than you think.<\/p>\n

Set up photo review incentives<\/strong> if your category benefits from them. Customer images are the highest-converting review content, and most stores collect far fewer than they could simply by not asking.<\/p>\n

Plan to reply to reviews<\/strong>, particularly critical ones. A good public reply to a two-star review converts a liability into evidence that you engage \u2014 and it is worth choosing a destination app that exports replies, given how often they are lost.<\/p>\n

Make sure reviews appear where hesitation happens.<\/strong> Product page is table stakes. Collection page star ratings, cart, and relevant content pages all help, and many stores only ever place the main widget.<\/p>\n

Confirm your schema is complete,<\/strong> not merely present. Aggregate rating, review count, individual reviews with authors and dates. Partial markup produces inconsistent search appearance.<\/p>\n

<\/span>The bottom line<\/span><\/h2>\n

Reviews are a first-class migration asset and they sit outside every platform’s standard export, which is exactly why they get lost.<\/p>\n

Check the export and import paths before you choose your destination app. Verify date preservation specifically, since imported reviews dated today undermine the credibility you were trying to preserve. Download your review images while you still have access. Build a product mapping table if identifiers are changing. Reconcile counts, dates, and photo counts after import rather than glancing at the total.<\/p>\n

And validate your structured data afterwards, because reviews that display without emitting schema cost you the star ratings in search results \u2014 a quiet loss of organic click-through<\/a> at rankings that look entirely healthy.<\/p>\n

<\/span>Frequently asked questions<\/span><\/h2>\n

<\/span>Can I migrate my product reviews to a new platform?<\/span><\/h4>\n

Usually, but it depends on where they currently live and which destination app you choose \u2014 so check the path before choosing the app rather than after. Reviews stored in native platform functionality or a common plugin can often be exported to CSV and imported into a review app that supports the format. What matters is which fields survive: product association, rating, text, reviewer name, and crucially the original date. Test an actual export and a sample import of fifty reviews before committing, including reviews with photos and replies, since those are where losses concentrate.<\/p>\n

<\/span>Will I lose my review dates when migrating?<\/span><\/h4>\n

Often, and it is the most damaging loss because of what it implies. If reviews import stamped with today’s date, several years of accumulated social proof appears to have been collected in a single week, which reads as fabricated \u2014 the precise opposite of what reviews are meant to establish. Make date preservation an explicit requirement, verify it in a sample import before doing the full set, and if dates cannot be preserved, consider configuring the app to hide dates entirely rather than displaying misleading ones. Also keep your original export file indefinitely.<\/p>\n

<\/span>What happens to review photos when I switch review apps?<\/span><\/h4>\n

They are the most likely thing to be lost, because they are hosted by your old app and the export typically contains links rather than the image files themselves. Once you cancel the old subscription, those links stop resolving and the images are gone. If your reviews carry customer photos \u2014 and for many categories these are the most persuasive content on the page \u2014 download them before you lose access, and confirm whether your destination app can accept them. Stores discover this problem after cancelling the old app with some regularity.<\/p>\n

<\/span>Why did my star ratings disappear from Google after migrating?<\/span><\/h4>\n

Almost certainly because your review schema is not emitting, which is separate from whether reviews display on the page. Reviews can render perfectly on your product pages while the structured data that produces star ratings in search results is absent \u2014 usually because the review app’s schema was not configured on the new theme, or the widget placement does not include the markup. Validate your product pages with a structured data testing tool and confirm review and aggregate rating markup is present. Fixing it is typically quick, and stars generally return within a few weeks.<\/p>\n

<\/span>Should I keep my old review app running during migration?<\/span><\/h4>\n

Yes, for longer than feels necessary \u2014 at least a month after you believe the import succeeded, and ideally longer. The old app is your only source for anything that did not transfer, including image files, your replies, and original dates, and once the subscription ends that data becomes difficult or impossible to retrieve. Stores that cancel immediately to save a month’s fee routinely discover a gap a fortnight later with no way back. Export everything while you have access, download the images, and treat the overlapping subscription as cheap insurance on an asset that took years to build.<\/p>\n

<\/span>How long does it take to rebuild reviews if I lose them?<\/span><\/h4>\n

Longer than the migration that lost them, which is why prevention is worth the effort. Realistically you are looking at six to twelve months to approach your previous volume, and only if you run an active collection programme rather than waiting. If you do lose them, act on launch day rather than drifting: enable review request emails immediately, send a request to recent purchasers first since their experience is freshest, and email your wider customer base explaining that the store has moved and asking them to re-share their experience. That last message performs better than people expect, particularly from brands customers feel warmly toward.<\/p>\n

<\/span>Are reviews worth paying a developer to migrate?<\/span><\/h4>\n

For any substantial review set, usually yes. If your preferred destination app has no official import path but you have a usable export, a developer can generally build an import against the app’s API \u2014 it is well-defined work with a clear finish line. Weigh that one-off cost against what the reviews are worth: the conversion effect on every product page, the star ratings in your search listings, and the months of collection effort they represent. For a store with a few thousand reviews carrying real conversion weight, the development cost is modest against the alternative of starting from zero.<\/p>\n","protected":false},"excerpt":{"rendered":"

Reviews are the most commonly lost asset in a migration, and the loss is usually discovered afterwards. The reason is structural. Reviews rarely live in your store’s core…<\/p>\n","protected":false},"author":7,"featured_media":4296,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[375],"tags":[],"class_list":["post-4259","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-migration-guides"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t