> ## 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.

# Portability and reversibility

> What you keep if you leave Recurr — your Stripe account, your subscribers, your branded subdomain, the migration outcome. Migration is permanent without making you locked-in.

A reasonable concern from any infrastructure-stage product: **if I migrate via Recurr, am I locked in?**

The answer is no. Migration is **permanent in outcome** (your subscribers stay on web rails) but **reversible in vendor** (the rails are yours, not Recurr's). This page lays out exactly what stays with you if the relationship ends.

## What you keep — by default, not on request

<CardGroup cols={2}>
  <Card title="Your Stripe Connect account (you're the Merchant of Record)" icon="stripe">
    The account is in your company's name from day one. You're the Merchant of Record on every subscription — Recurr never sits in the legal payment chain. The banking relationship, the tax records, and every charge ever processed are yours. Recurr is the operational interface; remove the `application_fee` integration and you have a standard Stripe account regardless of which Connect model the engagement is on.
  </Card>

  <Card title="Your subscribers" icon="users">
    Every migrated subscriber is a customer in your Stripe account, paying you directly. Their card is on file in your Stripe vault. Their renewal cycle continues independently.
  </Card>

  <Card title="Your branded subdomain" icon="globe">
    The CNAME for `subscribe.yourdomain.com` is your DNS record. Point it at any other endpoint — your own infrastructure, a different platform — and the same domain serves the new flow.
  </Card>

  <Card title="Your subscriber data" icon="database">
    Subscriber records (email, plan, tenure, status, lifecycle history) are exportable as CSV or JSON at any point during the engagement, and as part of the standard offboarding.
  </Card>
</CardGroup>

## What's portable

| Asset                                   | Format                 | Where it lives                                                                   |
| --------------------------------------- | ---------------------- | -------------------------------------------------------------------------------- |
| Subscriber records                      | CSV / JSON export      | Recurr dashboard + your entitlement system                                       |
| Payment methods + history               | Standard Stripe export | Stripe Dashboard (always yours)                                                  |
| Cohort + wave performance data          | CSV / JSON export      | Recurr dashboard, retained 13 months                                             |
| Email engagement events (opens, clicks) | Resend export          | Resend (your sending domain)                                                     |
| Branded subdomain SSL cert              | DNS-validated cert     | Provisioned to your domain; portable to any host                                 |
| Identity tokens (Apple, Google)         | OAuth client config    | Recurr's OAuth apps; on exit, you migrate to your own OAuth client registrations |

## Subscriber portability

The harder question: if you leave Recurr, **what happens to migrated subscribers?**

Answer: nothing. Their subscription continues exactly as it was.

* They're paying via Stripe Connect into your account; that doesn't depend on Recurr
* Their card is on file in your Stripe vault; renewals continue
* The branded checkout page is on your domain; you can serve it from any backend
* Their identity (Apple Sign In / Google Sign In) is an OAuth relationship that survives Recurr leaving the picture

What changes for the subscriber: nothing visible. Their plan, price, billing cadence, support channels — all unchanged.

What changes operationally: you're now managing the subscription billing rather than Recurr. Stripe's standard tools (Dashboard, customer portal, dunning rules) cover the basics. For more sophisticated lifecycle work, you'd swap in your own billing tooling.

## Migration is not reversible — and that's by design

One thing that **doesn't** revert: subscribers don't auto-go-back-to-app-store-billing if Recurr disappears. Once a subscriber is on web rails, they're on web rails. Their store subscription was canceled during migration; reactivating it would require them to manually re-subscribe through the App Store.

This is the right outcome — the recovered margin is permanent — but it does mean the decision to migrate is one-way. The framework's gating + holdouts are designed around exactly this: you don't migrate cohorts you can't measure first.

## Standard offboarding

If you decide to leave Recurr after the annual commitment term:

<Steps>
  <Step title="30-day notice via your named contact">
    Standard contractual notice. The framework prepares the export bundle.
  </Step>

  <Step title="Full data export delivered">
    Subscriber records, cohort + wave data, email events, billing history. CSV + JSON, encrypted.
  </Step>

  <Step title="Application-fee splits stop accruing">
    Stripe stops routing the per-charge `application_fee` to Recurr. Your Stripe account is unchanged otherwise.
  </Step>

  <Step title="Sub-processor list updated">
    Your DPA's sub-processor disclosures end. Stripe, your entitlement system, and any OAuth providers continue independently.
  </Step>

  <Step title="DNS handoff">
    You point the branded subdomain wherever you want next. Recurr's hosted target is decommissioned for your domain.
  </Step>
</Steps>

The end-to-end offboarding process typically completes within 30 days of formal exit notice.

## Status + uptime

Recurr's operational status is published at [recurr.instatus.com](https://recurr.instatus.com), monitoring the marketing site, the customer dashboard, and platform-side integration health.

<Note>
  The trust frame here is intentional. Recurr's job is to do the migration well enough that you stay because the platform is the right ongoing fit — not because leaving is hard. Every component above is designed so leaving is genuinely possible. The depth Recurr keeps is the **operational know-how** (cohort sequencing, offer strategy, framework iteration) — that comes with the relationship and goes when the relationship ends. The outcome (your subscribers on web rails) stays with you regardless.
</Note>
