How to plan a clean legacy review import

A clean import starts before anyone uploads a file. First, identify every source of existing reviews: prior review apps, CSV exports, marketplace exports, manually collected testimonials, post-purchase survey data, and media folders. Treat each source as a separate batch until it has been validated.

For each source, record the export date, owner, field definitions, product identifier format, media location, and whether the reviews were originally verified. This makes it much easier to explain the migration later if a merchant, support teammate, or compliance reviewer asks where a review came from.

Map product handles, product IDs, variant IDs, reviewer names, ratings, titles, bodies, dates, country or locale, verification flags, and media URLs before upload. Fixing mismatches after import is slower and more visible because review counts, product assignments, and storefront widgets may already be live.

Common cleanup work includes trimming empty rows, converting date formats, removing duplicate reviews, replacing invalid ratings, checking media URLs, and mapping retired product handles to current products. If the old platform allowed half-star ratings or custom fields, decide how those values should appear in Rava before the import begins.

• Use one canonical product identifier per row.
• Keep ratings in the range the destination app supports.
• Preserve original published dates when they are trustworthy.
• Do not mark reviews as verified unless the source can support that claim.

Imported reviews carry history. Keep source metadata where possible, even if it is only visible internally. Provenance helps support teams answer questions such as "Why did this review appear today?" or "Which system did this media file come from?" It also helps merchants feel confident that the migration did not invent or overwrite customer proof.

Never use migration as an opportunity to silently rewrite customer sentiment. Formatting cleanup is different from changing meaning.

If review bodies need light cleanup, keep it limited to obvious formatting problems: broken line breaks, encoding errors, or accidental export artifacts. Preserve critical language, rating, date, and media context.

Run a small import before moving the full dataset. The pilot should include simple products, variant-heavy products, reviews with media, older reviews, recent reviews, low ratings, and rows from each source system. After the pilot, inspect the admin queue and the storefront.

1. Confirm review counts by product.
2. Check that ratings and dates match the source file.
3. Open media attachments on mobile and desktop.
4. Verify low ratings, hidden reviews, and featured reviews behave as expected.
5. Search for duplicated reviewer names or repeated review bodies.

Use the help guide import existing reviews as the operational checklist for the import day.

Large review migrations should not go live blindly. Import in controlled batches, pause after each major category or source, and compare product review counts with the expected totals. If the store is changing review apps during a launch window, keep the previous export, the transformed import file, and the final imported batch list.

A good migration finish line is not only "all rows imported." It is "the right reviews appear on the right products, media renders correctly, support can explain the source, and the merchant knows what changed." For complex migrations, route the project through Rava support before launch.