What kind of “thing” is each option?
Subscription migration sits at the intersection of three product categories — billing platforms, paywall + entitlement tooling, and growth services. Different alternatives sit in different categories, so the comparison isn’t apples-to-apples by default.| Shape | What it is | What it does for migration |
|---|---|---|
| Managed migration platform | Subscription-engine + framework + delivery, all on one rail | Owns the end-to-end migration — cohort design, wave operations, email, checkout, entitlement sync, reporting |
| Billing platform (DIY) | Subscription infrastructure for new web acquisition | You build everything migration-specific on top — cohort labelling, wave runner, email send, gating, holdout, dashboards |
| Paywall / entitlement tool | In-app subscription UX + entitlement abstraction | Adjacent to migration but operates inside the app — doesn’t move subscribers off store rails |
| Consulting / services | Strategy + people, not infrastructure | Tells you how; you build and run it |
Dimensions worth pricing into the decision
1. Time to first wave
How long from “we want to do this” to “the first migration email lands in subscriber inboxes”? A managed platform with the framework + delivery layer compresses this. A DIY build on raw billing infrastructure stretches it — you’re building cohort labelling, wave orchestration, email composition, identity bridging, gating thresholds, dashboards, the holdout cohort mechanic. Each one is solvable; together they’re 6–12 months of work that isn’t on your roadmap.2. Cohort discipline + retention safeguards
Migration is a multi-touch campaign on a live revenue base. Bulk migration (“email everyone, see what sticks”) makes the retention question moot — you’ve already migrated everyone before you know whether it hurt churn. Cohort-by-cohort waves with a matched holdout makes the retention question answerable. Whether that discipline is the vendor’s default or something your team builds + enforces changes the cost shape materially.3. Who runs the work day-to-day
Some setups put the day-to-day operating load on the customer’s team (campaign send, cohort selection, copy review, gating sign-off, support coordination). Others put it on the vendor. For early-stage teams without dedicated lifecycle / retention headcount, the difference compounds — every hour spent operating the migration is an hour not spent on the next product release.4. Framework depth and policy posture
Migration runs at the seam between three policy surfaces (Apple, Google, regional regulation). The framework needs to take a posture on out-of-app communication, in-app pointers, anonymous subscribers, identity continuity through Apple Sign In private relay, and policy drift over time. The depth of the framework — and how clearly the posture is documented — varies. If you’d otherwise need a legal review on each of those points individually, that’s a real cost.5. Post-migration extensibility
A migrated subscriber base is the substrate for lifecycle motions — winbacks, annual upgrades, cancel deflections, payment recovery. The work density on those motions is structurally different from a one-time migration. Whether the platform extends into those motions or stops at migration changes the long-term roadmap. If lifecycle motions are out of scope for the migration vendor, you’ll add a second platform — and a second integration — later.6. Architectural exit posture
Subscription billing is sticky. The structural answer to “what if we leave?” matters more than the contractual answer. If the platform sits in the legal payment chain (acting as Merchant of Record itself), exit is harder — subscribers re-card on the next platform. If the customer is Merchant of Record on a Stripe Connect account in their own name, exit is cleaner — the platform layer is removable while subscriptions continue. See exit and portability for Recurr’s architectural posture.7. Total cost (not just the headline)
Three components determine the real cost of a migration approach:- Platform fees — the percentage on web-billed revenue
- Performance fees — what’s earned per converted subscriber (and on what trigger)
- Operational load — the headcount required to run the migration if the vendor doesn’t
A practical evaluation checklist
When you’re comparing options, the questions that surface the real differences:- How fast can the first migration wave actually ship? Who owns each step that gates that timeline?
- Who designs the pilot cohort, the matched holdout, and the gating thresholds? Who signs off wave-to-wave?
- What’s the engineering integration scope on the customer side? Hours, not weeks.
- Who handles policy drift on Apple / Google over the engagement window?
- How are subscriber data and the payment relationship structured if we leave?
- What does the lifecycle-motion roadmap look like after migration finishes?
- What’s the total commercial structure — platform fee + performance fee + any other line items + what’s earned on what trigger?