Migrating off Bazaarvoice, the 30-day plan

Why teams leave, and when they should not

Pricing is the usual trigger. Bazaarvoice's pricing page describes tiered packages (Essentials, Advanced, Enterprise) for ratings and reviews and for social commerce, but does not publish prices. Buyer-data site Vendr reports a median annual contract value of about $36,000 for Bazaarvoice, with implementation and onboarding fees on top. For a mid-market Shopify brand, that is often a large share of the retention and conversion budget, and renewal is when the question gets asked. Our Bazaarvoice comparison sets out where each product is stronger, with sources.

Syndication is the usual reason to stay. Bazaarvoice says its network lets brands syndicate content across more than 2,300 retailers, and describes a network of 13,000+ brands and retailers. If a meaningful share of your sales happens on retailer sites where your reviews appear because of that syndication, moving your on-site reviews elsewhere may not be worth losing it. Idukki does not offer review syndication to large retailers. Be clear-eyed about which side of that line you are on before any migration work starts.

The 30-day plan

Thirty days is realistic for a single storefront with a clean catalogue. Add a week per extra locale or storefront, and more if product IDs have changed over the years. Each week ends with a gate; if the gate fails, you extend that week rather than pushing on.

Export and field mapping

Request a complete export from your Bazaarvoice account team in week 1, in a structured format, and confirm in writing which fields it contains. Your contract's data and termination clauses govern what you are entitled to and when, so have the relevant clause to hand when you ask. The field list below is what a clean migration needs.

Prove the destination accepts it. Whatever platform you move to (Idukki included), ask the vendor to import a sample of your real export in week 2 and show you the result on a staging page: the right reviews on the right products, the badges intact, photos attached. A sales deck saying "we support migrations" is not the same as your file working. Idukki's reviews inbox, for reference, filters by status, rating, verified buyer and source, and approving or hiding a review there drives the PDP stars and the JSON-LD built from them.

The reconciliation check

Load the export into a table (a spreadsheet works for small catalogues; a database is easier beyond a few thousand products) and export the same fields from the new platform after import. The query compares count and average rating per product and returns only the mismatches. An empty result is the gate.

-- old_reviews: rows from the Bazaarvoice export (published only)
-- new_reviews: rows exported from the new platform after import
WITH old AS (
  SELECT product_id, COUNT(*) AS n, ROUND(AVG(rating), 2) AS avg_rating
  FROM old_reviews
  WHERE status = 'published'
  GROUP BY product_id
),
new AS (
  SELECT product_id, COUNT(*) AS n, ROUND(AVG(rating), 2) AS avg_rating
  FROM new_reviews
  GROUP BY product_id
)
SELECT
  COALESCE(o.product_id, n.product_id) AS product_id,
  o.n AS old_count, n.n AS new_count,
  o.avg_rating AS old_avg, n.avg_rating AS new_avg
FROM old o
FULL OUTER JOIN new n ON n.product_id = o.product_id
WHERE o.n IS DISTINCT FROM n.n
   OR o.avg_rating IS DISTINCT FROM n.avg_rating
ORDER BY old_count DESC NULLS LAST;

• Map IDs first. If product IDs changed over the years, join through a mapping table so old reviews land on current products.
• Check a second key. Count distinct original review IDs on both sides; matching totals with mismatched IDs means duplicates hiding a gap.
• Spot-check by eye. Open your ten best-selling product pages and compare what a shopper sees, old against new.
• Run it twice. Once at the end of week 3 on staging, once after cutover on live data.

Schema preservation

Star ratings in organic results depend on structured data Google can trust. Google's review snippet guidelines say the reviews you mark up must be readily available to users on the marked-up page (if you use AggregateRating, users should be able to see that rating on the page), and they say not to aggregate reviews or ratings from other websites. They also recommend validating with the Rich Results Test, testing deployed pages with the URL Inspection tool, and checking Search Console after deploying structured data or releasing new templates.

1. 1Record the baseline in week 1. Note which top product pages currently show review rich results, and save a Rich Results Test output for each.
2. 2Keep product URLs unchanged. The migration is a widget and data change, not a URL change.
3. 3Match markup to what is visible. If the new widget loads reviews after page load, confirm the structured data and the visible reviews agree, and that the markup is present when Google renders the page.
4. 4Remove the old markup at cutover. Two competing Product or AggregateRating blocks on one page is a common post-migration error.
5. 5Watch for three to four weeks. Compare Search Console against the baseline and fix any page that loses eligibility.

Idukki can serve schema.org Product, Review and AggregateRating JSON-LD for a merchant's pages, and the free review schema validator checks a page's markup. For background, AggregateRating schema and rich snippets explains the fields, and the review schema handbook goes deeper.

Procurement paperwork

Reviews contain personal data (names, locations, sometimes faces in photos), so the new vendor will process personal data on your behalf. The ICO explains that under UK GDPR the relationship between a controller and a processor must be governed by a written contract covering the points in Article 28(3), including the subject matter, duration, nature and purpose of processing, the types of personal data and the controller's rights and obligations. Legal will want the following before signature.

Be precise about certifications. Idukki, for example, states that SOC 2 is in audit (not certified yet) and that a security pack, sub-processor list and DPA are available under NDA; see the trust page. A vendor that answers these questions plainly in week 1 is less likely to surprise you in week 4. Pricing is published on the pricing page.