> ## Documentation Index > Fetch the complete documentation index at: https://recurr.dev/docs/llms.txt > Use this file to discover all available pages before exploring further. # Should you migrate your existing web subscribers too? > If you already sell subscriptions on the web, here is the case for consolidating that book onto Recurr alongside your migrated store subscribers — the operational reason, the cost, and the alternative. Store-to-web migration recovers the app-store cut on your existing app-store subscribers. If you already sell some subscriptions directly on the web, a second question follows: do you move that existing web book onto Recurr as well, or leave it on your current setup? Recurr's recommendation is to consolidate. This page explains why, what it costs, and what staying split actually involves. ## The default: one platform, web first The recommended path brings your whole subscription book onto Recurr, in this order: Because they already pay by card, moving them onto Recurr is a near-silent backend cutover. Payment methods carry over, there is no subscriber-facing campaign, and it completes in days. Your app-store subscribers move across in measured cohorts, gated on retention, the way [controlled migration](/getting-started/store-to-web-subscriber-migration) always runs. The end state is your entire subscriber base — formerly-store and already-web — on one platform. ## Why one system beats two The strongest reason is operational, and it lands on the surface your subscribers actually touch. When you migrate your store book to Recurr, those subscribers are no longer app-store subscribers. They are web subscribers now. So if your existing web subscribers stay on a separate system, you do not have "app subscribers here, web subscribers there." You have two groups of web subscribers, in two different billing systems, who look identical to themselves and to your support team. A subscriber who wants to update a card, change a plan, or cancel has to reach the system that holds their subscription. There is no reliable way for them to know which one that is. That leaves two options, and neither is good: * **Build and maintain a router** that identifies each subscriber and sends them to the correct billing portal. This is real, permanent infrastructure for a billing edge case. * **Run two portals and ask subscribers to choose.** "Are you a web subscriber, or a web subscriber?" is not a question anyone can answer. Support inherits the same fork. Every billing question starts with "which system is this person on?" before anyone can help. Consolidating removes the problem. One platform means one place to manage subscriptions, one help center, one support queue, and one view of subscription revenue across your whole base. ## What it costs The economics differ sharply between the two books. * **The store book is a large recovery.** You move subscribers off the 15-30% app-store cut onto direct web billing at roughly 5-7% all-in. That recovery is the reason to migrate at all. * **The existing web book is a small premium.** Those subscribers already run on cheaper card rails, so consolidating them onto Recurr adds Recurr's platform fee on top — but that fee includes the subscription billing, dunning, and tax handling you run separately today, so in practice the net premium on the web book is around a point. That premium is what buys the single system — the unified management, support, help center, and reporting, with lifecycle tooling building on top. Set against the cost of running two billing systems, it is a small number. Your [Migration Audit](https://recurr.dev/audit) resolves the exact figures for your country, rate, and ARPU, and the [pricing model](/working-with/pricing-model) has the full structure. ## You are not locked in Consolidating onto Recurr does not mean depending on Recurr. You are the merchant of record on your own Stripe Connect account. The money never routes through Recurr. If you ever choose to leave, you disconnect Recurr and every subscription keeps running on your account, uninterrupted. Portability is structural, not a contract clause. [More on portability and reversibility →](/trust/portability-and-reversibility) How the management experience sits with your existing web app is your choice: * **Standalone** — Recurr hosts the management and help surfaces. Lowest lift, live in days. * **Embedded** — subscription management lives inside your own web app, calling Recurr through its API, using your authentication and your design. More integration work, available when you want it seamless. ## What one platform makes possible Avoiding two systems is the floor. The reason to want your whole base on Recurr is what one platform can then do across all of it. The core is there from your first deployment — refunds, subscription management, and a help center. Building on that over time: * **Lifecycle motions across the whole base** — payment recovery, cancellation saves, and winbacks run on every subscriber, not just the half on one system. [Lifecycle motions →](/product/lifecycle-motions) * **One measurement view** — revenue, retention, and cohort behaviour across formerly-store and already-web subscribers in one place, instead of two exports stitched together. [Measurement →](/product/measurement) * **Pricing and checkout control** — adjust and test pricing, paywalls, and checkout flows on rails you own, without the store's constraints. The migration creates the single system. The platform compounds on top of it. ## The alternative: keeping web separate You can keep your existing web subscribers on your current setup and migrate only the store book. It is your call. But it is worth being clear-eyed about what that involves: two billing systems, the subscriber login and support fork above, split reporting, and a router you build or maintain yourself. Recurr does not offer a bridge for running two systems side by side. For most teams, the simpler answer is to consolidate. ## How each role tends to read this One platform for the whole subscription business. Recover the store cut, and stop running two billing systems as you grow. A large recovery on the store book, a small premium on the web book, and one view of subscription revenue instead of two reconciliations. No billing router to build or own. Merchant-of-record on your own Stripe Connect, a near-silent web cutover, and a standalone-or-embedded choice on integration. One support queue and one customer record across your whole base. No "which system are you on?" triage, and refunds and plan changes handled in one place. ## Next step The first step is the same as for any migration — a quick model of the opportunity. [Run the 60-second audit](https://recurr.dev/audit) or read [how the engagement works](/getting-started/how-it-works).