How do we decide whether to migrate ALL subscribers at once versus staggering the cutover by cohort (e.g., newest subscribers first, as a lower-risk test group)?
Cohort-staggered cutover beats a big-bang migration above roughly 2,000 active subscribers, and the right first cohort is newest subscribers on cards held by your current processor. Newest subscribers carry the freshest payment credentials and the lowest tenure-weighted LTV, so a failed transfer costs least there. Below about 2,000 contracts, a single-window migration with a parallel billing run is simpler and cheaper.
The criteria, in the order they decide it
- Subscriber count. Under roughly 2,000 active contracts, the vendor's own migration service is the sensible buy and a single window is fine. Deploi scores the build-or-buy line there (per our subscription-platform-migration decision, September 2026). Above it, stagger.
- Vault portability. If cards must be re-collected, stagger regardless of count: you are running a comms campaign, not a data move, and campaigns need a test cell.
- Billing-date distribution. Anniversary billing gives you natural cohorts. Fixed-date billing does not, and staggering means deliberately splitting a single billing event, which is harder.
- Rollback appetite. A staggered cutover keeps a rollback cheap for the first cohort. A big-bang migration's rollback is a second migration.
Picking the first cohort. Newest subscribers, on payment methods held by your current processor, excluding anyone on a legacy grandfathered price or a bespoke discount. That group has the freshest credentials, the least tenure at stake, and the fewest odd contract fields. Aim for a cohort large enough to produce a readable transfer rate: a few hundred contracts, not a dozen.
What to read before cohort two. Payment-method transfer rate at seven days. Charge accuracy on the first billing event. Support ticket volume per thousand migrated. If any of the three is outside expectation, the answer is to stop and fix, not to proceed more carefully.
When NOT to stagger. Three cases. First, when your contract with the outgoing vendor has a hard termination date that does not allow a multi-cycle run, then you are migrating in one window and the mitigation budget goes up. Second, when the two platforms cannot both be live against the same gateway at once, which happens and should be confirmed in week one. Third, when the program is small enough that the staggering overhead exceeds the risk it retires.
The cost nobody prices. A staggered cutover means running two platforms, two sets of subscriber emails and two support scripts for as long as the stagger lasts. That is real operational drag on a team that also has a day job. Budget the calendar, not just the engineering.
The Deploi point of view
Our own position, from building on Shopify. Separate from the facts above.
- Our take: Stagger by payment-credential freshness, not by subscriber value. The instinct to protect high-LTV subscribers by migrating them last is right; the reason it works is that their cards are the oldest.
- What we’ve seen: Cohort one is where you discover the contract field your export did not carry: a legacy discount, a paused state, a custom cadence. Finding it in a few hundred contracts is a Tuesday. Finding it in forty thousand is a quarter.
- Where we disagree: Vendor migration services quote for a single window because a single window is cheaper to deliver. That is a legitimate commercial preference and it is not the same as a recommendation.
- What this page adds: the cohort-selection rule and the three read-outs that gate cohort two.
Reviewed by Martin Dejnicki, Director of SEO & AI Search. Facts verified 2026-09-13.