Skip to main content
The audit numbers anchor on what migration recovers from your existing book. The compounding piece is what happens afterwards.

​
What changes structurally

Migration shifts the billing rail. Not just for the subscribers who get migrated — for every subscriber who arrives after you have web rails in place. Before migration:
  • Existing subs on app-store billing at 15–30%
  • New subs on app-store billing at 15–30%
After migration:
  • Existing migrated subs on web: 6% Recurr take in Y1 (3.5% platform + 2.5% performance fee), 3.5% Recurr take in Y2+, plus your country-specific Stripe processing
  • Existing un-migrated subs still on app-store billing (untouched)
  • New subs acquired through web channels: 3.5% Recurr take from day one (no migration performance fee on new web subs), plus Stripe processing
The compounding is in the third bucket. Web acquisition was always available; what migration unlocks is a safer path to make web subscriptions the default for more of the business — both the migrated existing book and new cohorts acquired through paid, organic, or partnership channels.

​
Why this matters for paid acquisition

Assumptions in this section. US-based app on Stripe (2.9% + 0.30/txn),0.30/txn), 17 ARPU. At $17 ARPU the per-transaction flat fee adds ~1.76 points to the Stripe percentage basis, so all-in Stripe is ~4.66%. Your live Migration Audit uses your country-specific rate and actual ARPU.
A migrated app’s web acquisition runs at roughly 8% all-in on a new subscriber (3.5% Recurr platform + ~4.66% Stripe at $17 ARPU, US baseline) instead of the 22% blended store fee. A campaign that was barely profitable at a 22% take can run materially deeper into the LTV curve when the take drops to ~8%. Concretely: if a subscriber’s lifetime value is 200netoftheoldfeestructure,thesamesubscriber′sLTVunderwebrailsiscloserto200 net of the old fee structure, the same subscriber's LTV under web rails is closer to 240–$260 (depending on cohort retention and Y1/Y2+ mix). That’s not a marginal improvement — it shifts which channels and which CACs are economically viable. Apps that move first see compounding in two places:
  • Existing book: the migrated cohort recovers margin permanently for the lifetime of each subscription (see where the recovery comes from for the worked numbers)
  • New cohorts: every dollar of paid acquisition spent post-migration runs on the lower fee structure from the first charge

​
The earlier you start, the longer compounding has to run

For an app expecting to operate for 5+ years, the compounding window is the dominant variable. A migration that takes 12 weeks frees the next 200+ weeks of acquisition + retention to run on web rails. For an app planning a sale in 18 months, compounding still matters — buyers value LTV-based metrics, and the ones that reflect web economics are more attractive than the ones blended with store fees.
The audit shows a multi-year view alongside the year-one figure for exactly this reason. Year one is the entry; later years are where the default rail matters. The full lifetime number depends on retention curves the public audit doesn’t see.
The migration framework →