Re-warming review velocity after a platform switch.

The chart looks like a cliff. Two years of steady weekly review volume, ranging between 80 and 120 new reviews per week for a mid-size skincare store. Then a switch. Then four weeks at 40 to 60. Then a slow climb.

Every operator who has migrated review platforms has seen this chart. Very few were warned about it. Almost none have been told what produces it.

There are three forces. They compound. The good news is that each is reversible and the reversal is on a known timeline. The bad news is that the default migration plan does none of the reversal work, which is why the cliff looks the way it does.

This essay is the companion piece to the migration that takes a month. That essay walked through what breaks during a switch. This one is about how to put it back together.

The old platform knew when to ask. The new platform does not.

A review-request automation is conditioned on more state than the help docs describe. The buyer's purchase history. Their prior review history. Their engagement with post-purchase emails. The product's category-specific review-latency window. Skincare wants six weeks because that is how long it takes to know if a serum works. Apparel wants ten days because that is the wear-test window. Electronics wants the same week, because if the buyer is going to be frustrated they will be frustrated before the second weekend.

The old platform learned this over two or three years of your store running. Some of the learning was explicit; you set the windows by hand. Most of it was implicit, encoded in a thicket of automation rules and exception conditions that nobody documented. The CSV does not carry the rules. The new platform does not carry the rules. The new platform makes default-shaped decisions.

The default for most platforms is 14 days post-purchase. Klaviyo's documentation explicitly says "test 14 days." Yotpo defaults to 14. Okendo defaults to 14. The default is wrong for almost every category that is not apparel or accessories. Skincare, supplements, home goods, electronics, and any considered-purchase category have category-specific windows that range from 5 days to 8 weeks.

When the new platform asks at 14 days, three things happen. A fraction of customers respond before they have used the product. Their reviews are thinner. A fraction of customers do not respond at all because they have not formed an opinion yet, and the same customer is now less likely to respond to a second request later. A fraction respond appropriately, but the response rate is below what the old, tuned platform was achieving. The dashboard shows it. The dashboard does not show why.

The old platform's review-request email went out from a subdomain that had spent two years building trust with Gmail, Apple Mail, Outlook, and Yahoo. The new platform's email goes out from a different subdomain that has spent zero days building trust.

Inbox providers do not treat new senders as innocent. They treat new senders as suspicious. A new subdomain sending 5,000 transactional emails a day from day one will see its open rate suppressed by 15 to 25 percent for the first two weeks. Some fraction of mail will land in Promotions, some fraction in Spam, some fraction never delivered at all.

The re-warming playbook is published. Klaviyo's own deliverability guide describes it. Postmark's guide is more detailed. SendGrid's is the most operationally specific. The pattern is the same across all three. Send only to your most-engaged segment for the first three days. Hold daily volume below a threshold (typically 5,000 sends per day, lower if your list is small). Ramp 25 percent per day after the first week. Suppress bounced and unengaged addresses aggressively for the first month. Do not send to addresses that have not opened anything in 180 days, full stop, for the first six weeks.

Most migrations do not follow this playbook because the destination platform turns the email flow on at full volume on day one. The destination platform's marketing pages promise "no interruption to your review collection." The technical reality is the inverse. The interruption is invisible because the dashboard reports sends and clicks, not deliverability and inbox placement. Sends and clicks look fine. The reviews do not arrive because the emails are not being read.

The most operator-specific of the three forces. If the migration runs in parallel, with the old platform and the new platform both alive for the first three weeks, the same buyer may receive two review requests for the same purchase. One from each platform. One on day 12, one on day 14.

The buyer's response is predictable. They open neither. They mark one as spam. The next time either platform asks them anything, the deliverability has degraded for the sender that landed in spam, and the buyer's affinity for review requests has dropped one notch. This compounds across the segment. Three thousand buyers double-receiving review requests in the same week is a fatigue event that takes two months to recover from.

The default migration plan runs the old platform until "the new one is working," which usually means three to four weeks of overlap. This is the wrong default. The overlap should be measured in days, not weeks, and the cutover should be planned by purchase cohort, not by calendar date.

The cohort-based cutover is straightforward to describe. Every buyer who purchased before the cutover date is owned by the old platform's request flow. Every buyer who purchases after the cutover date is owned by the new platform. The cutover date is set once, communicated to both platforms, and respected. No buyer should be in both queues for the same purchase.

This is operator work. The dashboard does not do it for you. See the dashboard is not the work. The cohort-based cutover is the kind of decision that lives outside both platforms, in a state the operator carries and enforces.

The shape of the recovery is well-mapped. Email-platform migrations show it (Klaviyo's own 2024 benchmark report, 30 to 60 days to baseline). Help-desk migrations show it (Zendesk to Intercom case studies, 45 days median). The review-platform recovery follows the same curve because the underlying mechanics are the same: new sender reputation, fresh trigger logic, segment re-engagement.

The thirty-day playbook is a single sequence with five phases. None of the phases require unusual tools. All of them require the discipline to not rush.

Days one through three. Cohort cutover. Set the cutover date. Disable the old platform's outbound flow for all post-cutover purchases. Disable the new platform's flow for all pre-cutover purchases. The old platform finishes its queue over the next 30 days; the new platform starts a queue from zero. No double-sends.

Days one through fourteen. Sender warming. The new platform's request flow runs only to the warmest 20 percent of the list. The warmest 20 percent is defined by purchase recency (last 60 days) and prior review engagement (any prior review, or any open of a prior review request). Volume capped at 25 percent of normal daily send. Open rate watched closely. If open rate drops below 30 percent during this window, pause sends for 48 hours and audit.

Days seven through twenty-one. Trigger re-implementation. The category-specific windows from the old platform are rebuilt in the new platform. The 14-day default is replaced. Buyer-fatigue thresholds (no more than one request per 90 days per buyer) are rebuilt. Exception conditions for refunds, exchanges, and returns are rebuilt. This is engineering work, two to four days of focused configuration. Most teams underestimate it and ship the new platform with the defaults intact for three months.

Days fourteen through thirty. Volume ramp. The 25-percent cap lifts in three steps over two weeks. By day thirty, the new platform is at full daily send. The opened-and-not-clicked rate is now within 10 percent of the old platform's baseline. The clicked-and-not-submitted rate (the rate at which buyers open the request, click through, but do not write the review) is harder to recover; it usually takes another two weeks.

Days twenty-one through sixty. Velocity recovery. Fresh-review volume climbs back toward baseline. The shape is sigmoid, not linear. The middle two weeks are the steepest. By day sixty, fresh-review velocity is within 10 percent of pre-migration. By day ninety, it is usually above, because the new platform's trigger logic, once tuned, often performs marginally better than the old platform's accumulated cruft did.

The thirty-day curve is the average across categories. It is not the shape every store will see. Three category-specific patterns are worth flagging because they break the average in predictable ways.

Skincare and supplements. The recovery is slower because the category-correct review-latency window is longer (six to eight weeks). A migration in March means the first cohort of new-platform reviews does not appear in volume until mid-May. The dashboard at day thirty shows a deeper trough than the average. This is not a problem with the migration; it is the category's natural latency. Operators who panic at day thirty in skincare are often the same operators who would have seen a healthy day-sixty if they had waited.

Apparel and accessories. The recovery is faster because the latency window is shorter (seven to fourteen days). The trough is shallower and the climb is steeper. The risk in apparel is not the trough; it is sender-reputation damage during the warm-up. Apparel buyers are the most likely to mark transactional email as spam, so the warm-up rules need to be stricter (segment to the warmest 10 percent for week one, not the warmest 20 percent).

Electronics and considered purchases. The recovery is bimodal. The early-week request flow produces a small spike (buyers who got their product, used it for three days, and have a strong opinion). The two-week and four-week request flows produce a second spike (buyers who got past the honeymoon and have an opinion). The migration breaks both. The dashboard at day thirty often looks worse than it is because only the first spike has had time to fire on the new platform.

The honest version of the thirty-day playbook is category-aware. Most migrations are not. The dashboard the destination platform shows is category-blind by default.

Every metric in the recovery playbook is observable. None of them are on the default dashboard.

Sender reputation is observable via Postmaster Tools, Litmus, or any reputable deliverability service. Most review platforms do not surface it. Inbox placement is observable via seed-list testing (Litmus, Email on Acid). Most review platforms do not surface that either. Cohort-level send tracking is observable in any half-decent ESP integration; most review-platform dashboards aggregate sends across cohorts and lose the structure.

The trigger-inheritance gap is observable by running the old platform's automation rules and the new platform's automation rules side-by-side as a spreadsheet, line by line. This is the most boring artifact of any migration. It is also the one that decides whether month three looks like month one or month thirteen.

The overlap-month fatigue is observable by querying your support inbox for "stop emailing me" messages in the four weeks around the cutover. The spike is the signal. The absence of a spike means the cohort cutover worked.

We have written about this distinction before. See software that remembers. The software that remembers is the software that survives a migration; the software that only counts is the software that loses a month of context every time you switch it out.

Migrations are reversible operations made irreversible by impatience. The thirty-day recovery is on a known timeline. The five-phase playbook is mostly mechanical. The teams that follow it land at day sixty with their velocity back and their trigger logic tighter than it was before. The teams that do not follow it land at day sixty wondering why the dashboard is still down and quietly considering a second migration.

The work, as always, is not in the switch. The work is in what you carry through the switch. The operator software that wins the next decade is the kind that carries trigger logic, sender reputation, cohort state, and citation continuity as objects you can move. The kind that exports a CSV and calls itself migrated is not that.