The migration that takes a month, not a weekend.

Yotpo's migration help article is 1,200 words. Okendo's is 1,400. Both describe the same procedure. Export your reviews as CSV. Map the columns. Import. Re-install the widget. Done by Sunday night.

The procedure is correct. The procedure is also not the migration.

A real review-platform migration takes about thirty days. It loses photo and video assets that no migration tool transfers. It breaks the structured-data identifiers that Google has been indexing for two years. It interrupts the post-purchase email flow at the worst possible moment, the moment when the new platform has no warmed sender reputation. It drops fresh-review velocity by somewhere between 30 and 60 percent for the first month. And it quietly orphans every citation an answer engine has built pointing at the old widget URL.

None of this appears in the help doc, because the help doc is written by the company you are leaving or the company you are arriving at. Neither has an incentive to tell you what a migration actually costs.

This essay is the version of the help doc nobody publishes. It uses Yotpo to Okendo as the canonical example, because both publish enough documentation to be specific. The shape of the work is the same for any pair.

The first thing that happens on day one is not a corruption. It is an admission. The CSV you export from Yotpo contains the review text, the star rating, the verified-buyer flag, the reviewer name, the timestamp, and the product SKU. It does not contain the photos. It does not contain the videos. It does not contain the review replies you wrote over three years. It does not contain the answer-engine citations that point at the old widget. It does not contain the review-request email history that the old platform used to decide when to ask a customer for a second review.

The CSV is a flat representation of an object graph. The graph is the corpus. The CSV is the corpus minus its memory. See software that remembers for the longer argument about why operator software splits into systems that count and systems that remember; a migration is the test of which kind you were running.

Yotpo's photo and video uploads live on Yotpo's own CDN. The URLs in the CSV (if they are in the CSV at all) point at a host that the destination platform cannot read from. Okendo will not pull those photos for you. The photos will not appear in the new widget on Tuesday morning unless someone, somewhere, runs a script that downloads each one, re-uploads it to Okendo's media library, and rewrites the join row.

This is not a Yotpo problem and it is not an Okendo problem. It is the problem of every review platform that hosts media on its own infrastructure. The CSV format does not carry binaries. The migration tool does not, in practice, deep-fetch them. The default outcome is a clean review corpus with the visual evidence missing. For a category where photo reviews convert at roughly 2.4x the rate of text-only reviews (Okendo's own conversion data, 2024), the visual evidence is most of the value.

The day-one practical move is to budget two to four days of engineering to run the photo migration as a separate job. Most teams skip this. Most teams then re-import photos manually over the following six months, one product at a time, when they notice.

By day three the new widget is installed and rendering. The new widget emits structured data. Google receives the structured data. Google notices that the AggregateRating IDs do not match the ones it had been crawling.

Schema.org's Review and AggregateRating types do not require a stable identifier. In practice, every review platform mints its own. Yotpo's identifiers look like `yotpo-review-{numeric-id}`. Okendo's look like `okendo-{uuid}`. When you switch, the identifier namespace switches with you. Google's index now contains two thousand review entities under the old namespace and two thousand new entities under the new namespace, attached to the same product URLs.

Most of the time Google handles this gracefully. The aggregate rating in the product snippet updates within a week. The total review count, sometimes, takes a month. Occasionally a review-rich snippet disappears for ten days during the transition and reappears with the new count. This is the kind of thing that does not show up in any documentation because no platform writes about it, and Google writes about schema generically without naming platforms.

The deeper problem is the answer-engine layer. GPTBot and ClaudeBot do not just read schema. They cache pages with the schema in them, and they build internal references to the entities. When a model is asked "does product X have any issues with sizing" three months after your migration, the citation it returns may quote a review that no longer exists at the URL it points to, or that exists with a new platform's URL fragment. This is not a hypothetical. Ahrefs's March 2026 study of AI Overview citation drift found that 22 percent of cited URLs returned content that had been moved or rewritten between the crawl and the citation. Migrations are one of the most common reasons.

We have written elsewhere about how the widget itself is the wrong shape for the work. See the end of the review widget. The migration period is the moment when that wrongness becomes visible. The widget shape is the part that does not survive a switch.

Yotpo's review-request email goes out from a Yotpo subdomain that has spent two years warming up its sender reputation with the inbox providers that matter. Gmail, Apple Mail, Outlook, Yahoo. Okendo's review-request email goes out from a different Okendo subdomain that has, from the inbox's perspective, no relationship with your store.

The new sender starts from cold. The new sender will see open rates 15 to 25 percent below the old sender for the first two weeks. The new sender will be silently rate-limited by Gmail if you send too many too fast. The new sender will land in the Promotions tab more often than the old one did.

There is a re-warming playbook for sender reputation. It is the same playbook Klaviyo and Postmark have published a dozen times. Start with your most-engaged segment (recent purchasers, prior reviewers). Hold volume below 5,000 sends per day for the first three days. Ramp 25 percent per day after that. Do not send to bounced or unengaged addresses for the first month.

The re-warming is straightforward to execute. The honest thing is that nobody plans for it. The default migration assumes the email flow turns on at Tuesday 9 a.m. and runs at full volume by Tuesday 9:15. The default migration is wrong.

By day fourteen the new platform has been running for two weeks. It has, in principle, started asking your customers for reviews. In practice, it does not yet know who to ask.

Review-request automations are not generic. They are conditioned on a buyer's purchase history, prior review history, post-purchase email engagement, and (in the better implementations) the product's category-specific review-latency window. Skincare wants six weeks. Apparel wants ten days. Electronics wants the week of arrival. Yotpo learned this for your store over two or three years. Okendo will learn it over two or three months.

In the meantime, the new platform makes default-shaped decisions. It sends a request fourteen days after purchase regardless of category. It does not know that the customer who bought a sunscreen in May has already reviewed it in June; it sends a duplicate request. It does not know that your moisturiser line has a 5 percent first-touch return rate, so it sends a review request to a customer who is currently waiting for a return label.

The trigger inheritance problem is not a bug in the new platform. It is the absence of a state that the old platform had accumulated. The state was implicit, kept in the operator's head and in two years of automation rules. The migration does not transfer it.

We have argued before that the dashboard is not the work. See the dashboard is not the work. The argument is exactly this. The work is the trigger logic, the timing rules, the buyer-fatigue thresholds, the category-specific windows. The dashboard reports on the work; it does not contain it. When the dashboard moves, the work does not move with it.

Three weeks in, the operator finally has a dashboard view that shows what happened. Fresh-review velocity, the number of new reviews collected per week, has dropped 30 to 60 percent compared to the four-week trailing average from the old platform. The exact number depends on category, sender-reputation outcomes, and whether the email flow was throttled correctly.

This is the moment when the operator considers rolling back. Most do not. Rolling back loses another three weeks. Rolling back also signals to the team that the migration was a mistake, when in fact the velocity drop is a property of the migration itself, not of the destination platform.

The recovery curve is well-documented in adjacent categories. Email-platform migrations show the same shape (Klaviyo's own benchmark report, 2024). Help-desk migrations show it (Zendesk, Intercom). CRM migrations show it. The recovery typically takes 30 to 60 days from the velocity trough. By day 60, fresh-review velocity is back to within 10 percent of the pre-migration baseline. By day 90, it is usually above.

The companion piece to this essay walks through the re-warming in detail. See re warming review velocity.

The final problem appears late, because it is the slowest to surface. Two years of answer-engine citations have pointed at the old widget URL. The widget URL changed. The citations did not.

GPTBot's user agent string has been stable since late 2023. The crawler revisits high-citation URLs on a roughly 60-day cadence. When it next crawls your product page, it will find the new widget at a new URL fragment. It will re-cite the new content. The old citations stop being repeated.

The transition period is roughly the same 30 to 60 days as the email re-warming. During that window, an answer engine asked about your product may quote a review that still exists in the model's cache but whose URL no longer resolves to the same content. The quote will read correctly. The link will land on a generic product page. The citation is technically still attributable to you. It is no longer attributable to the place a buyer can find more of the same.

Most operators never notice this happen. The metric does not exist on any dashboard. Search Console reports on Google, not on ChatGPT or Perplexity. The only way to know is to run the same five queries through three answer engines on day zero and day sixty, and compare which sentences they quote and whether the URLs still resolve.

The dashboard reports on the work. The work is the trigger logic, the email cadence, the photo migration, the URL stability, the citation maintenance. None of these are in the CSV.

Most migration dashboards show a reassuring picture for the first two weeks. Sends are happening. Reviews are coming in. The numbers are smaller than the old platform's, but the new platform's onboarding emails attribute the smaller numbers to "early ramp" and tell the operator to be patient. By day fourteen the operator stops worrying.

The bad data appears between day fourteen and day thirty. The dashboard's seven-day rolling average finally rolls over the gap. The cumulative review count for the month is now visible against last month's. The fresh-review velocity chart, which was lying for two weeks (because the lookback window was still partially in the old platform's data), is now reporting honestly. The number is bad.

This is the moment when the rollback conversation happens. It is also the worst possible moment to roll back. By day thirty, the new platform's sender reputation is more than halfway warmed; rolling back means warming a third sender on the original subdomain. The trigger logic is half-rebuilt; rolling back loses the rebuild. The cohort cutover is settled; rolling back creates a second cutover in the opposite direction.

The operator who understands the recovery curve does not roll back at day thirty. The operator who looks only at the dashboard often does. This is one of the costlier observable failures in operator software, and almost no platform builds the chart that would prevent it: a velocity-vs-expected-recovery overlay, where the expected curve is the published 30-to-60-day migration baseline and the observed curve is the live data. With that overlay the conversation is calibrated. Without it the conversation is panic.

The honest plan has six parallel tracks. The CSV import is one of them. The photo and video re-host is the second. The email-sender re-warming is the third. The schema continuity audit is the fourth. The trigger and cadence re-implementation is the fifth. The citation monitoring is the sixth.

The CSV import takes a weekend. The other five take a month. This is not a failure of the destination platform. It is a property of the corpus, which is not a flat table.

For the operator considering a switch in the next two quarters, the practical move is to budget the month, not the weekend. Run the old platform and the new platform in parallel for the first three weeks. Throttle the email flow on the new platform aggressively for the first two weeks, then ramp. Audit the photo migration as a separate engineering job. Run the same five answer-engine queries before, during, and after, and watch which sentences move. Do not look at the dashboard for the first three weeks; the dashboard during a migration is misleading.

By day thirty, the new platform is in steady state. By day sixty, the fresh-review velocity has recovered. By day ninety, the citations have caught up. The thirty-day version of the story is the one the help doc should have told.

Switching review platforms is not the small operation that the marketing copy on the destination platform's site implies. It is also not a disaster. It is a thirty-day reshaping of a system that has been running on accumulated state, and the state has to be rebuilt. The platforms that pretend the migration is a weekend are selling the weekend. The state is what carries the value.

The future of operator software in commerce is going to belong to the systems that treat that state as the product, not the dashboard that reports on it. A platform that holds the trigger logic, the sender reputation, the URL stability, the citation graph, and the photo library as first-class objects is a platform that survives a migration without losing them. A platform that exports a flat CSV is one that confesses, at the moment of switching, what it actually held.