# MoveMRR > MoveMRR is software for controlled Stripe-to-Stripe subscription migration and SaaS billing handover. It helps operators prepare, recreate, verify, reconcile, and document subscriptions in a destination Stripe account. Last factual review: 2026-08-15 Full corpus: https://movemrr.com/llms-full.txt (complete text of every English article and reference page in one file) ## Direct Answer Stripe provides a Billing migration toolkit for importing subscriptions, including migrations from an existing Stripe account. Stripe Customer Data Copy can copy eligible customer and payment-method data, but it does not copy Subscription objects. Cross-account migration therefore creates new destination subscriptions; it does not move the original Stripe Subscription objects. MoveMRR adds a controlled two-account workflow around that recreation: mappings, readiness checks, dry runs, configurable source deactivation, reconciliation, ID exports, and an audit record for buyer and seller. ## Important Limits - Eligible customer and payment-method data can be copied by Stripe in the background. - Zero customer action is not guaranteed for every customer. Unsupported payment methods, missing default payment methods, issuer declines, or SCA can require follow-up. - A migration creates new destination Subscription IDs. Applications, local ID mappings, entitlements, and account-specific credentials must be handed over deliberately. - Stripe webhook endpoints can optionally be recreated on the destination account. Stripe issues a new signing secret for every newly created endpoint, so those consumers must be re-deployed with the new secret; MoveMRR reports exactly which endpoints are affected and never stores the secret value. - Sandbox projects use Stripe test keys, are free, and have no run or subscription limit. Sandbox seeding recreates a live catalog and subscription shapes in a Stripe sandbox; it does not create customers there, which come from Stripe's own Customer Data Copy, and sandbox payment methods are Stripe test cards. - Transferring ownership of the existing Stripe account can be an alternative in some acquisitions. Confirm legal-entity and country changes with Stripe Support. ## MoveMRR Capabilities - Readiness checks and dry runs before a live migration - Customer, product, price, coupon, and subscription mapping - Billing-cycle, trial, metadata, and multi-item subscription handling - Configurable source-subscription deactivation - Idempotent execution records, reconciliation, and downloadable ID maps - Optional destination webhook-endpoint recreation with explicit signing-secret handover - Free, unlimited sandbox projects on Stripe test keys, running the same migration engine as a paid live project - Sandbox seeding that recreates a live catalog, discounts, tax rates, and active, trialing, and past-due subscription shapes in a Stripe sandbox from a read-only live key that is never stored ## Security - Purpose-specific restricted Stripe API keys with permission validation - Stored live keys use Supabase Vault, expire inside MoveMRR after 30 days, and are not returned to the browser; account owners must still revoke them in Stripe after the project - Raw card numbers are not handled by MoveMRR; eligible payment credentials are copied by Stripe ## Pricing One-time v2 pricing based on declared active subscriptions and estimated monthly recurring revenue. Currency: EUR. - Minimum: from 150€; formula-priced beyond the calculator slider range - Advanced: from 350€; formula-priced beyond the calculator slider range - Done-For-You: from 3.150€; capacity review above 25,000 active subscriptions Current exact pricing and scope: https://movemrr.com/pricing/ ## Key Pages - Home: https://movemrr.com/ - Pricing: https://movemrr.com/pricing/ - Security and access boundaries: https://movemrr.com/security/ - German home: https://movemrr.com/de/ - Spanish home: https://movemrr.com/es/ - Stripe subscription migration service: https://movemrr.com/stripe-subscription-migration/ - German Stripe subscription migration: https://movemrr.com/de/stripe-abo-migration/ - Spanish Stripe subscription migration: https://movemrr.com/es/migracion-suscripciones-stripe/ - SaaS acquisition and billing handover: https://movemrr.com/solutions/saas-acquisitions/ - Product manual: https://movemrr.com/docs/ - Knowledge base: https://movemrr.com/knowledge/ - Blog and operational runbooks: https://movemrr.com/blog/ - FAQ: https://movemrr.com/faq/ - Technical migration guide: https://movemrr.com/knowledge/stripe-subscription-migration-guide/ - Stripe Billing Migration Toolkit vs MoveMRR: https://movemrr.com/compare/stripe-billing-migration-toolkit/ - Migration without customer action: https://movemrr.com/knowledge/migration-without-customer-action/ - Sandbox seeding for a realistic rehearsal: https://movemrr.com/knowledge/sandbox-seeding-guide/ - Account ownership vs subscription migration: https://movemrr.com/knowledge/account-ownership-vs-subscription-migration/ - Application handover after migration: https://movemrr.com/knowledge/application-handover-after-stripe-migration/ - Compatibility and edge cases: https://movemrr.com/compatibility/ - Comparisons and alternatives: https://movemrr.com/compare/ - Customer migration outcomes: https://movemrr.com/customers/ - 2026 aggregate migration research: https://movemrr.com/research/state-of-stripe-account-migrations-2026/ - Stripe migration readiness assessment: https://movemrr.com/tools/stripe-migration-readiness/ ## German Resources - Ratgeber: https://movemrr.com/de/ratgeber/ - Blog: https://movemrr.com/de/blog/ - Lösungen: https://movemrr.com/de/loesungen/ - Kompatibilität: https://movemrr.com/de/kompatibilitaet/ - Vergleiche: https://movemrr.com/de/vergleiche/ - Fallstudien: https://movemrr.com/de/kunden/ - Studien: https://movemrr.com/de/studien/ - Bereitschaftsprüfung: https://movemrr.com/de/werkzeuge/stripe-migrationsbereitschaft/ - Preise: https://movemrr.com/de/preise/ - Sicherheit: https://movemrr.com/de/sicherheit/ ## Spanish Resources - Guías: https://movemrr.com/es/guias/ - Blog: https://movemrr.com/es/blog/ - Soluciones: https://movemrr.com/es/soluciones/ - Compatibilidad: https://movemrr.com/es/compatibilidad/ - Comparativas: https://movemrr.com/es/comparativas/ - Casos de clientes: https://movemrr.com/es/clientes/ - Investigación: https://movemrr.com/es/investigacion/ - Evaluación de preparación: https://movemrr.com/es/herramientas/evaluacion-preparacion-migracion-stripe/ - Precios: https://movemrr.com/es/precios/ - Seguridad: https://movemrr.com/es/seguridad/ ## Official Stripe Sources - Billing migration toolkit: https://docs.stripe.com/billing/subscriptions/import-subscriptions-toolkit - Customer and payment data copy: https://support.stripe.com/questions/data-that-can-be-copied-between-stripe-accounts?locale=en-GB - Account ownership: https://support.stripe.com/questions/change-the-owner-of-a-stripe-account?locale=en-GB - Business sale or acquisition: https://support.stripe.com/questions/transfer-a-stripe-account-to-a-different-entity-due-to-a-business-sale-or-acquisition?locale=en-GB - Subscription authentication and SCA: https://support.stripe.com/questions/saving-payment-methods-for-subscriptions-after-strong-customer-authentication-%28sca%29-regulations-take-effect?locale=en-GB - API key security: https://docs.stripe.com/keys-best-practices - Subscription webhooks: https://docs.stripe.com/billing/subscriptions/webhooks ## Contact - Email: jovanovic@thecodecave.de - Founder: Aleksandar Jovanovic --- Below is the full text of every English MoveMRR article and reference page. Each document starts with its canonical URL. --- # Stripe Account Ownership Transfer vs Subscription Migration Canonical: https://movemrr.com/knowledge/account-ownership-vs-subscription-migration/ > Decide whether a SaaS buyer should take ownership of the existing Stripe account or recreate subscriptions in a separate destination account. **Direct answer:** Transfer ownership of the existing Stripe account when Stripe confirms that the account, legal entity, country, history, and liabilities can remain with the acquired business. Migrate subscriptions when the buyer needs billing in a different Stripe account or a clean operational and legal separation. Do not choose based on convenience alone—confirm the permitted account path with Stripe and the deal's legal and tax advisers. An ownership transfer changes who controls an account. A subscription migration creates new subscription objects in a different account. They solve different transaction structures. ## Decision Table | Deal condition | Ownership transfer may fit | Subscription migration may fit | |---|---|---| | The same legal entity is sold through a share/equity transaction | Often | Only if the buyer wants a separate billing account | | Assets move but the seller's legal entity remains behind | Less likely; confirm with Stripe | Often | | Buyer and seller are in different countries | Stripe documents a different process; contact Support | Often, subject to payment-method and country support | | Buyer needs a clean account history and separate tax configuration | No | Yes | | Existing disputes, balances, reserves, or reporting history must stay with the business | Potentially | Requires explicit allocation and legacy access | | Product has many account-specific integrations | Fewer Stripe object-ID changes | Requires an application and webhook handover | | Seller must retain unrelated products in the source account | No | Yes, with carefully selected scope | | Buyer already operates a destination Stripe account | Usually not | Often | This table is operational guidance, not legal or tax advice. ## What an Account Ownership Transfer Changes Stripe allows a current account owner to transfer ownership to another user with the required Dashboard role. For a business sale or acquisition involving a different entity, Stripe tells the existing owner to contact Support first so Stripe can confirm which representative, owner, URL, legal name, tax ID, bank, statement, receipt, and contact details must change. If Stripe approves keeping the same account, the practical result is that existing Subscription objects remain in that same account because no cross-account recreation occurs. That is an inference from retaining the account, not a promise that Stripe will approve every entity change. Primary sources: - [Change the owner of a Stripe account](https://support.stripe.com/questions/change-the-owner-of-a-stripe-account?locale=en-GB) - [Transfer a Stripe account after a business sale or acquisition](https://support.stripe.com/questions/transfer-a-stripe-account-to-a-different-entity-due-to-a-business-sale-or-acquisition?locale=en-GB) ## What a Subscription Migration Changes In a migration, the destination account gets newly created Subscription objects. Customer Data Copy can copy eligible Customers and payment methods, but Stripe says it does not copy subscriptions, invoices, plans, coupons, events, or logs. A migration therefore requires: - destination Customers and usable default payment methods; - Product, Price, Coupon, Tax, trial, and billing-cycle decisions; - new destination Subscription IDs; - a source-deactivation plan; - application and webhook updates; - reconciliation and retained access to legacy records. Stripe's Billing migration toolkit and MoveMRR can both participate in destination subscription creation. MoveMRR focuses on coordinating the surrounding buyer/seller handover. ## A Five-Question Decision Path ### 1. Is the legal entity staying the same? If yes, ask Stripe whether account ownership and team access can be transferred while retaining the account. If the legal entity changes, do not assume that changing the Dashboard email is sufficient. ### 2. Is the acquiring entity in the same country? Stripe explicitly notes that acquisition by an entity in a different country follows a different process. Contact Support before signing a cutover plan. ### 3. Does the source account contain anything outside the deal? If the seller bills another product, entity, or retained customer population through the same account, handing over the whole account is unlikely to produce a clean separation. A scoped migration lets the parties define which subscriptions move. ### 4. Which history and liabilities should each party retain? An existing account contains balances, payouts, disputes, invoices, logs, tax settings, and reporting history. A new account separates future operations, but the source account must remain available for legacy records. Allocate access, retention, and responsibility in the purchase agreement. ### 5. Can the buyer update the application? A separate-account migration changes account-specific API keys, Subscription IDs, Price IDs, webhook endpoints, and signing secrets. If the buyer cannot safely deploy those updates, the billing migration is not complete. ## Handover Requirements by Path | Workstream | Existing account ownership transfer | Separate-account migration | |---|---|---| | Stripe Support review | Required for entity/acquisition questions | Required for customer/payment-data copy and country constraints | | Team roles and owner | Replace and verify | Configure destination team | | Bank and payout details | Update in existing account | Configure destination account | | Statement descriptor and receipts | Review for new operator | Configure and test in destination | | Existing Subscription IDs | Usually unchanged because account is retained | Replaced by new destination IDs | | API keys | Rotate after personnel changes | Replace source credentials with destination credentials | | Webhook signing secrets | Rotate/review | Create destination endpoints and deploy new secrets | | Historical invoices and logs | Stay in the retained account | Stay in source; preserve appropriate legacy access | | Source deactivation | Not applicable | Required and must be reconciled | ## Limits and Escalations Neither MoveMRR nor a generic checklist can decide: - whether contracts and payment mandates are assignable; - which entity must issue invoices; - how prepaid revenue, refunds, disputes, taxes, or reserves are allocated; - whether Stripe will approve a particular entity or country change; - what customer notice is legally required. Resolve those items with Stripe and qualified advisers before live billing changes. ## Related Guides - [SaaS acquisition billing handover checklist](/blog/saas-acquisition-checklist-billing-handover/) - [What happens to Stripe subscriptions when a SaaS is sold?](/blog/what-happens-to-stripe-subscriptions-when-you-sell-your-saas/) - [Stripe Billing Migration Toolkit vs MoveMRR](/compare/stripe-billing-migration-toolkit/) - [Application handover after a Stripe migration](/knowledge/application-handover-after-stripe-migration/) - [Technical migration guide](/knowledge/stripe-subscription-migration-guide/) --- # Application Handover After a Stripe Subscription Migration Canonical: https://movemrr.com/knowledge/application-handover-after-stripe-migration/ > A technical handover runbook for Stripe IDs, API keys, webhooks, entitlements, dunning, and reconciliation after subscriptions move to a new account. **Direct answer:** A Stripe subscription migration is not complete when destination subscriptions exist. The buyer's application must use the destination account's credentials and object IDs, verify webhook signatures with new endpoint secrets, map entitlements to the recreated subscriptions, and monitor the first renewals while the source account is deactivated according to plan. Treat billing-object migration and application cutover as two linked workstreams with one reconciliation gate. ## What Changes Across Stripe Accounts | Item | Expected handover | |---|---| | Subscription ID | New destination ID; update local references using the migration ID map | | Customer ID | Stripe currently says copied Customers keep their IDs, but reconcile the actual copy/export rather than assuming | | Product and Price IDs | Destination-account IDs; update configuration, lookup tables, and admin tooling | | Coupon and Tax IDs | Destination-account IDs where used | | Publishable key | Replace in the client environment for the destination account | | Server API key | Replace in the server secret store; never expose it to the client | | Webhook endpoint ID | New when recreated in the destination account | | Webhook signing secret | New endpoint secret; deploy it before accepting destination events | | Customer Portal configuration | Destination-account configuration and links | | Invoices, events, and logs | Historical objects remain in the source account | MoveMRR provides downloadable old-to-new ID results for migrated objects. The application team remains responsible for applying them to its own database and configuration. ## Phase 1: Inventory the Billing Contract Before cutover, document every place the application depends on Stripe: - environment variables and secret-manager entries; - source-account Customer, Subscription, Product, Price, Coupon, and webhook IDs stored in the database; - webhook event types and API version; - entitlement or feature-access logic; - checkout and Customer Portal links; - dunning emails and payment-update routes; - analytics, data warehouse, revenue recognition, tax, and support integrations; - scheduled jobs that query Stripe; - Connect or organization account context, if present. Search both code and operational tools. A migration can bill correctly while the product still revokes access because an internal job is querying the old account. ## Phase 2: Build and Validate the ID Map Use a durable table rather than replacing IDs ad hoc: | Local entity | Source Stripe ID | Destination Stripe ID | Verified state | Cutover owner | |---|---|---|---|---| | Customer or tenant | `cus_…` | Actual copied destination ID | Default method checked | Billing | | Subscription | `sub_…` | New `sub_…` | Status and next billing date checked | Engineering | | Price | `price_…` | New or mapped `price_…` | Amount, currency, interval, tax checked | Product/finance | Keep the source ID for audit and support. Do not overwrite it before the destination object has been independently retrieved and compared. Useful verification fields include: - status and collection method; - current period or next billing date; - recurring items, quantities, currency, and amounts; - trial end and cancellation state; - default payment method presence; - discounts and tax behaviour; - business metadata used by the application. ## Phase 3: Cut Over Credentials Safely Stripe API keys authenticate requests for a specific account context. Move the application to destination credentials through the normal secret-management and deployment process: 1. create the least-privilege production key needed by the application; 2. store it in a secret manager, not source code; 3. update the publishable key used by the browser or mobile client; 4. test the destination account in a non-production environment; 5. deploy the server and client changes together where required; 6. verify the account ID returned by an authenticated request; 7. rotate source credentials after the agreed observation window and personnel handover. Do not reuse MoveMRR's migration key as the application's permanent billing key. The permissions and lifetime serve a different purpose. Primary source: [Stripe API-key best practices](https://docs.stripe.com/keys-best-practices). ## Phase 4: Recreate and Verify Webhooks Webhook configuration is account-specific. A new endpoint has a new signing secret, even if the URL and enabled event types match. For each destination endpoint: 1. reproduce the intended URL, event types, and API version; 2. copy the new `whsec_…` signing secret into the application's secret manager; 3. deploy signature verification before enabling production traffic; 4. send a test event and verify a successful response; 5. confirm deduplication by Event ID; 6. handle events without relying on delivery order; 7. retrieve current Stripe objects when an event arrives before a related object is present locally. Stripe explicitly says event delivery order is not guaranteed. A resilient handler must also tolerate retries and duplicates. Primary source: [Receive and verify Stripe webhook events](https://docs.stripe.com/webhooks). MoveMRR can optionally recreate supported webhook endpoint configuration in the destination account. The signing secret still needs an explicit application deployment because it is a credential, not ordinary endpoint metadata. ## Phase 5: Protect Entitlements The product should not grant or revoke access based only on a successful object-creation response. Define the buyer's source of truth: - Stripe Entitlements, if the product uses them; or - local entitlement records driven by verified subscription and invoice events. At minimum, test: - `invoice.paid`; - `invoice.payment_failed`; - `invoice.payment_action_required`; - subscription created, updated, paused, resumed, and deleted; - trial ending; - past-due and unpaid policies; - manual refunds or credits that affect access. Stripe documents that subscription status and payment state are related but not interchangeable. For example, an `active` subscription does not prove that every historical invoice is paid. Primary source: [Using webhooks with subscriptions](https://docs.stripe.com/billing/subscriptions/webhooks). ## Phase 6: Reconcile Before Source Deactivation Choose a gate that both buyer and seller can sign off: - all in-scope rows have a destination object or an explicit exception; - sample and aggregate recurring amounts reconcile; - next billing dates and trial ends reconcile; - the destination application resolves the new IDs; - webhook signature verification and event processing pass; - the customer portal and payment-update path use the destination account; - the agreed source-deactivation action is complete or scheduled; - manual follow-ups have owners and deadlines. Do not infer success from equal subscription counts alone. Counts can match while prices, intervals, trial ends, tax behaviour, or local mappings differ. ## Phase 7: Observe the First Renewal Cohorts Monitor by renewal window, not only by elapsed time: - destination invoice creation and payment; - authentication-required and failed-payment events; - duplicate source invoices; - entitlement changes; - webhook delivery failures; - support tickets mentioning statement descriptors or payment updates; - MRR and subscription counts against the signed reconciliation report. Keep appropriate read access to the source account for historical invoices and logs. Stripe's account-copy process does not move those records. ## Limits An ID map cannot automatically update every custom application, warehouse, CRM, tax tool, or data contract. Webhook recreation cannot transfer a signing secret. A successful migration also cannot guarantee future issuer authorization. Assign a named engineering owner to the application cutover and a billing owner to the renewal observation period. ## Related Guides - [Technical Stripe subscription migration guide](/knowledge/stripe-subscription-migration-guide/) - [Stripe Billing Migration Toolkit vs MoveMRR](/compare/stripe-billing-migration-toolkit/) - [Migrate subscriptions without customer action](/knowledge/migration-without-customer-action/) - [Prevent double billing during migration](/knowledge/prevent-double-billing/) - [SaaS acquisition billing handover checklist](/blog/saas-acquisition-checklist-billing-handover/) - [MoveMRR product manual](/docs/) --- # Stripe billing_cycle_anchor & _config Explained (2026) Canonical: https://movemrr.com/knowledge/billing-anchors-explained/ > What billing_cycle_anchor controls, how billing_cycle_anchor_config differs, and how to keep renewal dates when creating or migrating subscriptions. **Direct answer:** The purpose of `billing_cycle_anchor` in Stripe subscriptions is to define the reference date that all future billing cycles align to: it determines when each recurring invoice is issued and how prorations are calculated. By default the anchor is the subscription's creation time; set it explicitly to bill on a different date, or use `billing_cycle_anchor_config` to pin billing to a fixed calendar day such as the 1st of the month. The anchor does not control the first charge on its own — `start_date`, `trial_end`, `collection_method`, and `proration_behavior` all interact with it. That interaction matters most when recreating subscriptions in another Stripe account: a migration must preserve the customer's **next expected charge date and paid service period**, not just copy a timestamp from the source subscription. Get it wrong and the customer is billed by two accounts, or the renewal silently shifts to the migration date. Stripe's Billing migration toolkit includes fields for both `start_date` and `billing_cycle_anchor`, which is a useful reminder that creation timing and recurring cadence are separate decisions. ## What Is the Purpose of billing_cycle_anchor in Stripe? The billing-cycle anchor influences: - the recurring renewal cadence; - when a full recurring invoice is expected; - how prorations are calculated when subscription configuration changes. It does not independently prove: - that the customer has a valid default payment method; - that the first destination invoice will not require authentication; - that no trial or scheduled phase changes the first charge; - that the source account has stopped collecting. ## What Is billing_cycle_anchor_config and How Is It Different? `billing_cycle_anchor_config` is the calendar-based way to set the anchor. Instead of passing one absolute timestamp, you pass a recurring rule — `day_of_month`, and optionally `month`, `hour`, `minute`, `second` — and Stripe derives the next matching anchor date itself. Use it when every subscription should bill on the same calendar day (for example, always on the 1st), rather than on the anniversary of its creation. Differences that matter in practice: - `billing_cycle_anchor` takes a Unix timestamp; `billing_cycle_anchor_config` takes a calendar rule. They are alternative ways to control the same anchor — do not send both on the same request. - `billing_cycle_anchor_config` can only be set when the subscription is created; changing the cycle later means updating the anchor through a subscription update with the appropriate proration setting. - With either variant, the period between start and the first full cycle is handled by `proration_behavior` — a calendar rule does not by itself decide whether that partial period is charged, credited, or skipped. - For months without the configured day (for example, the 31st), Stripe bills on the last day of the shorter month. In a migration, a source subscription created with `billing_cycle_anchor_config` still exposes its concrete next renewal via `current_period_end`. Recreating it in the destination account with a timestamp anchor on that date preserves the customer's schedule; re-applying the calendar rule is only necessary if the destination should keep the fixed-day behaviour for future plan changes. Primary source: [Stripe billing cycle documentation](https://docs.stripe.com/billing/subscriptions/billing-cycle). ## Which Fields Must Be Reconciled Together During a Migration? | Field or state | Migration question | |---|---| | `start_date` | When should the destination subscription or schedule begin? | | `billing_cycle_anchor` | Which recurring date should future cycles align to? | | `trial_end` | Is the remaining trial being preserved, ended, or restarted? | | `proration_behavior` | Should creation or a schedule change produce a proration? | | `collection_method` | Will Stripe charge a saved method or send an invoice? | | `cancel_at_period_end` | Was the source subscription already set to end? | | Source current-period boundary | Which account owns the final paid source period? | | Destination default payment method | Can automatic collection occur on the planned date? | The correct configuration is the one that matches the commercial agreement and expected next invoice. ## A Concrete Example Assume: - the source subscription renews monthly on 15 August; - the customer has paid through 14 August; - the migration project runs on 5 August. A controlled plan usually schedules the destination to take over at the next agreed boundary and prevents the source from also renewing on 15 August. Creating an immediately billable destination subscription on 5 August would shorten the paid period or create an overlapping charge. If the source renews during the cutover window, decide which account takes that renewal first. Do not "fix" it afterward by changing only the anchor. ## How Do You Preserve Renewal Dates When Recreating a Subscription? Three patterns cover most Stripe-to-Stripe recreations. All three aim at the same outcome — the destination's first full invoice lands on the date the customer already expects — but they behave differently around the start: 1. **Future anchor with no proration.** Create the destination subscription now, set `billing_cycle_anchor` to the source's `current_period_end`, and send `proration_behavior: "none"`. The subscription is active immediately and the first full invoice is issued at the anchor. This is the pattern Stripe's own Stripe-to-Stripe toolkit example follows. 2. **Trial until renewal.** Create the subscription with `trial_end` set to the source's `current_period_end`. No charge occurs during the trial, and the billing cycle anchors to the trial's end. Functionally similar to the first pattern, but the subscription reports `trialing` until cutover — relevant if your product logic or dunning treats trials differently. 3. **Backdated start.** Pass a historical `start_date`/`backdate_start_date` so the destination records when the relationship really began, combined with a future anchor for the next charge. Useful when invoice history context matters in the destination account; it does not by itself prevent an immediate charge — the anchor and proration settings still decide that. Whichever pattern is used, verify the destination's `current_period_end` equals the customer's expected renewal date after creation, and confirm the source is deactivated before that date arrives. ## Stripe Billing Migration Toolkit Rules Stripe currently documents: - a production `start_date` at least 24 hours in the future; - a one-hour minimum in a sandbox; - a 24-hour scheduled state before production subscriptions go live; - `billing_cycle_anchor`, `trial_end`, and `proration_behavior` fields in the CSV specification; - a Stripe-to-Stripe example that uses the source current-period end as the destination start and a future billing date as the anchor. Primary source: [Stripe Billing migration toolkit](https://docs.stripe.com/billing/subscriptions/import-subscriptions-toolkit). These are toolkit rules, not a universal API recipe. If an internal script or MoveMRR workflow is used, inspect the plan generated for each subscription type. ## Edge Cases ### Annual and Prepaid Subscriptions An annual customer may have many months of service remaining. The purchase agreement should say whether the seller retains the prepaid revenue, whether the buyer receives an adjustment, and when the destination first bills. This is an accounting decision as well as a Stripe configuration. ### Active Trials Preserve the intended trial end when that is part of the customer agreement. An anchor alone does not preserve a trial. ### Multiple Subscription Items All recurring items must have a compatible destination schedule. Check quantities, intervals, currencies, and any mixed-interval behaviour rather than sampling only the first item. ### Send-Invoice Subscriptions The due date and collection process matter in addition to the billing anchor. Verify `collection_method` and `days_until_due`. ### Past-Due or Unpaid State Open invoices do not move through Customer Data Copy. Decide whether the seller collects, writes off, or otherwise resolves source receivables, and document what the destination subscription represents. ### Billing Dates Too Close to Cutover Stripe recommends scheduling destination subscriptions after a near-term cycle so the source system can issue the final bill without overlap. Move the operational cutover boundary; do not improvise with an immediate creation. ## MoveMRR Review For each planned subscription, review: - source and destination Price mapping; - next expected billing date; - trial handling; - proration setting; - source-deactivation strategy; - warnings for states that need manual review. After the run, compare the destination result and exported ID map with the source snapshot. A successful API response is not a complete billing reconciliation. ## Related Resources - [Technical Stripe subscription migration guide](/knowledge/stripe-subscription-migration-guide/) - [Prevent double billing during migration](/knowledge/prevent-double-billing/) - [Billing-cycle anchor migration compatibility](/compatibility/billing-cycle-anchors/) - [Stripe Billing Migration Toolkit vs MoveMRR](/compare/stripe-billing-migration-toolkit/) - [SaaS acquisition billing handover checklist](/blog/saas-acquisition-checklist-billing-handover/) ## Frequently asked questions **What is the purpose of billing_cycle_anchor in Stripe subscriptions?** It defines the reference date all future billing cycles align to, determining when each recurring invoice is issued and how prorations are calculated. By default it equals the subscription's creation time. **What is the difference between billing_cycle_anchor and billing_cycle_anchor_config?** billing_cycle_anchor takes one absolute timestamp; billing_cycle_anchor_config takes a calendar rule such as day_of_month so every cycle bills on a fixed day. They control the same anchor and cannot be combined in one request. **Why should you not copy billing_cycle_anchor directly in a migration?** A copied timestamp can point into the past or into an already-paid period. Preserve the customer's next expected charge date instead — usually by anchoring the destination subscription to the source's current_period_end. **How do you keep the renewal date when recreating a subscription in another Stripe account?** Either set billing_cycle_anchor to the source's current_period_end with proration_behavior 'none', or create the subscription with trial_end on that date. Verify current_period_end afterwards and deactivate the source before it renews. --- # Migrate Stripe Subscriptions Without Customer Action Canonical: https://movemrr.com/knowledge/migration-without-customer-action/ > When a Stripe-to-Stripe migration can reuse saved payment methods without asking customers to sign up again, plus SCA and payment-method limits. **Direct answer:** Many Stripe-to-Stripe migrations can copy eligible customer and saved payment-method data in the background, so customers do not have to create a new account or re-enter a card during the cutover. That is not a universal guarantee. Unsupported payment methods, missing defaults, issuer declines, and Strong Customer Authentication (SCA) can still require individual customers to act. The accurate objective is **minimise customer action and prepare a remediation path**, not promise that no customer will ever be asked to authenticate. ## What Stripe Can Copy in the Background Stripe's current account-copy documentation lists: - customer name, email, phone, address, default payment method, and Customer metadata; - cards represented as Card, Source, or PaymentMethod objects; - ACH bank accounts represented as bank-account or PaymentMethod objects; - SEPA PaymentMethod objects. Stripe says copied Customers keep their Customer IDs, while payment-method IDs change. It also says customers are not informed when this background copy occurs. The same documentation excludes charges, invoices, plans, subscriptions, coupons, events, logs, SEPA **Source** objects, Bacs PaymentMethods, connected accounts, and guest customers. The original account retains its data because the operation is a copy, not a move. Primary source: [Data that can be copied between Stripe accounts](https://support.stripe.com/questions/data-that-can-be-copied-between-stripe-accounts?locale=en-GB). ## Customer-Action Decision Table | Condition | Likely cutover experience | Required preparation | |---|---|---| | Supported card or bank PaymentMethod copies and remains the default | No signup or payment re-entry during migration | Verify the destination Customer has the intended default before scheduling the subscription | | Destination Customer has copied methods but no valid default | Future automatic collection can fail | Select the correct default only when consent or prior payment behaviour supports that choice | | SEPA stored as a legacy Source | Stripe documents that it is not copied | Obtain a supported mandate/payment method or plan customer outreach | | Bacs PaymentMethod | Stripe documents that it is not copied between Stripe accounts | Create a separate Bacs remediation plan | | Issuer accepts the off-session recurring-payment exemption | Renewal can complete without an authentication session | Monitor payment and invoice webhooks | | Issuer rejects the exemption or requests 3DS | Customer action is required | Send the hosted authentication flow and track completion | | Card is expired, replaced, or declined | Customer needs to update payment details | Use destination-account dunning and payment-update communication | "Likely" is intentional: the bank and the payment network participate in the final authorization. ## Why SCA Prevents an Absolute Promise For recurring off-session card payments, Stripe can request a merchant-initiated-transaction exemption when the payment method was set up appropriately. Stripe also states that the card issuer decides whether to accept that exemption. If it is rejected, the customer must return on-session to authenticate. Your application therefore needs to handle: - `invoice.payment_action_required`; - `invoice.payment_failed`; - PaymentIntents with `requires_action` or `requires_payment_method`; - a secure destination-account page where the customer can authenticate or replace the method. Primary sources: - [Saving payment methods for subscriptions after SCA](https://support.stripe.com/questions/saving-payment-methods-for-subscriptions-after-strong-customer-authentication-%28sca%29-regulations-take-effect?locale=en-GB) - [Using webhooks with subscriptions](https://docs.stripe.com/billing/subscriptions/webhooks) ## Preconditions for a Low-Friction Migration Run these checks before recreating subscriptions: 1. **Classify payment methods.** Count supported copied methods separately from Bacs, legacy SEPA Sources, missing methods, and expired cards. 2. **Verify destination defaults.** Stripe's Billing migration toolkit requires a default payment method for automatic collection. 3. **Confirm recurring-payment authority.** Keep the seller's existing consent records and have counsel review whether the acquisition changes the customer-facing merchant or terms. 4. **Match statement details.** Prepare the destination statement descriptor, support email, receipt branding, and customer portal. 5. **Configure recovery.** Set destination dunning, failed-payment emails, and the authentication path before the first renewal. 6. **Rehearse with representative cases.** Test a normal card, a missing default, a trial, a failed payment, and each bank method in scope. MoveMRR can surface payment-method and mapping issues, but the buyer remains responsible for legal consent, destination Stripe settings, and customer communication. ## Cutover Sequence For eligible customers, a controlled sequence is: 1. complete Stripe's customer and payment-data copy; 2. reconcile the copied Customer population and default payment methods; 3. map source Prices and subscription configuration to destination objects; 4. run a dry run and separate automatic from manual-remediation cases; 5. create destination subscriptions on the agreed future billing schedule; 6. apply the selected source-deactivation strategy; 7. monitor the first renewal cohorts and action-required events; 8. contact only the customers who need remediation. This sequence avoids asking every customer to update their card merely because the Stripe account changed. ## What to Tell Customers Whether to notify all customers is a business and legal decision. Even when no action is expected, proactive notice can reduce disputes if the merchant name or statement descriptor changes. A precise message says: - the service and renewal cadence remain the same; - the billing entity or statement descriptor is changing; - most customers do not need to do anything; - Stripe or the business might contact an individual customer if their bank requires authentication or their method needs updating; - where to verify a legitimate payment-update request. Avoid saying "your card will definitely work" or "you will never need to re-authorize." ## What MoveMRR Does and Does Not Do MoveMRR coordinates the subscription side of the handover: readiness checks, mappings, dry runs, destination creation, configurable source deactivation, reconciliation, and ID exports. Stripe performs the copy of eligible payment credentials; MoveMRR does not receive raw card numbers. MoveMRR cannot override: - Stripe's account-copy eligibility; - bank authorization decisions; - SCA or payment-network rules; - missing customer consent; - unsupported payment methods; - a buyer's incomplete dunning or authentication integration. ## Related Guides - [Stripe Customer Data Copy capabilities and limits](/knowledge/stripe-customer-data-copy/) - [Stripe Billing Migration Toolkit vs MoveMRR](/compare/stripe-billing-migration-toolkit/) - [Prevent double billing during migration](/knowledge/prevent-double-billing/) - [Application handover after a Stripe migration](/knowledge/application-handover-after-stripe-migration/) - [Technical migration guide](/knowledge/stripe-subscription-migration-guide/) --- # Prevent Double Billing in a Stripe Migration (2026) Canonical: https://movemrr.com/knowledge/prevent-double-billing/ > One renewal period, one account: schedule the destination start, verify anchors, deactivate the source, reconcile invoices. Failure modes included. **Direct answer:** Prevent double billing by assigning each renewal period to exactly one account. Create or schedule the destination subscription, verify its configuration, and complete the agreed source deactivation before both accounts can collect for the same period. Then reconcile actual invoices and exceptions. No tool can honestly guarantee that a customer will never see a duplicate charge under every configuration. A defensible process reduces the risk, detects overlap early, and defines remediation. ## How Overlap Happens | Failure mode | Result | |---|---| | Destination bills immediately while source period is already paid | Customer pays twice for overlapping service | | Source remains active through its next renewal | Both accounts can invoice the same period | | Destination anchor or start date is wrong | Charge occurs earlier than the cutover plan | | A source invoice is already finalized or in flight | Cancelling the Subscription might not resolve that invoice | | Retry after partial failure creates another destination object | Duplicate destination subscriptions | | Catalog changes during the final snapshot | Dry-run assumptions no longer match live state | | Manual exception has no owner | Source stays billable after the automated run | The key control is a **billing boundary**, not a particular API parameter in isolation. ## Stripe's Recommended Sequence Stripe's Billing migration documentation advises creating destination subscriptions before cancelling the old subscriptions so a billing period is not missed. It also advises cancelling the old subscriptions before the new subscriptions are set to charge. For a renewal close to migration, Stripe recommends scheduling the destination start after that cycle so the source system takes the final bill. Primary source: [Stripe Billing migration toolkit](https://docs.stripe.com/billing/subscriptions/import-subscriptions-toolkit). This creates a safe operating window: 1. destination exists or is scheduled; 2. destination configuration is verified; 3. source collection is stopped according to plan; 4. destination reaches its first billing boundary; 5. both accounts are reconciled. ## Build the Billing-Boundary Table Before the live run, create one record per subscription or billing cohort: | Field | Example | |---|---| | Source Subscription ID | `sub_source…` | | Source current period end | 15 August, 10:00 UTC | | Last invoice owned by seller | Source renewal through 14 August | | Destination start | 15 August, 10:00 UTC | | Destination next expected invoice | 15 August | | Source deactivation | Cancel at period end before renewal | | Destination Subscription ID | Filled after creation | | Verification owner | Buyer billing lead | Use UTC timestamps in the migration record and render local time separately for operators. Avoid deciding cutover from a date without its timezone. ## Pre-Cutover Controls - Freeze or tightly control Price, Coupon, Subscription, and payment-method changes. - Reconcile source Subscription status and current-period boundaries. - Verify every destination Customer has the intended default payment method. - Map destination Prices, quantities, discounts, taxes, trials, and collection methods. - Run a dry run against the latest source snapshot. - Separate automatic cases from manual remediation. - Agree on source action: cancel at period end, cancel immediately, pause collection, or explicit manual handling. - Assign an owner for every source invoice already open, finalized, or in retry. If the operator selects no source deactivation, both accounts remain capable of billing until the manual list is completed. ## Live Cutover Controls ### 1. Use Idempotent Creation Stripe recommends an idempotency key for POST requests. MoveMRR also records source-to-destination provenance and run results so an interrupted run can distinguish existing work from a new create. Idempotency does not replace reconciliation. A changed payload, expired idempotency record, or manual Dashboard action can still produce unexpected state. ### 2. Verify Configuration, Not Only Status Before approving source deactivation, compare: - Customer and default payment method; - Price IDs, amounts, currency, intervals, and quantities; - next billing date and trial end; - collection method and invoice due date; - discounts and tax behaviour; - cancellation and pause state. An `active` destination Subscription alone does not prove the billing plan is correct. ### 3. Complete Source Deactivation Use the strategy agreed before close. MoveMRR supports configurable source-deactivation behaviour and surfaces cases that need manual follow-up. Confirm the resulting source state rather than assuming a successful destination create changed the source. ### 4. Inspect Both Invoice Queues Review: - source draft, open, and finalized invoices; - destination upcoming, draft, and open invoices; - payment retries and action-required events; - manual invoices for send-invoice subscriptions. Subscription cancellation and invoice state are related but not identical. ## After Cutover Monitor the first renewal cohorts in the destination account: - `invoice.paid`; - `invoice.payment_failed`; - `invoice.payment_action_required`; - unexpected source invoices; - entitlement changes; - support tickets and statement-descriptor confusion; - MRR and active-subscription totals against the signed reconciliation. Keep the source account available for historical invoices, events, and logs because Customer Data Copy does not move them. ## If a Duplicate Charge Occurs 1. Stop further overlap for the affected source/destination pair. 2. Identify which invoice does not belong to the agreed billing period. 3. Review refunds, credits, tax, and revenue-recognition consequences with the billing owner. 4. Contact the customer promptly with the exact resolution. 5. Record the source ID, destination ID, invoices, timestamps, cause, and corrective action. 6. Search the remaining migration population for the same failure condition. Do not issue an automatic refund blindly if the two invoices cover different service periods or legal entities. ## MoveMRR Safety Model MoveMRR contributes: - readiness checks and a dry run; - billing-cycle and trial handling; - configurable source-deactivation strategy; - idempotent execution records; - per-item results, warnings, and manual-deactivation follow-ups; - reconciliation and downloadable ID mappings. It cannot prevent a bank retry, Dashboard change, unsupported state, or operator-selected "no deactivation" from affecting billing. The final control is the reviewed cutover and reconciliation. ## Related Resources - [Stripe `billing_cycle_anchor` during migration](/knowledge/billing-anchors-explained/) - [Technical Stripe subscription migration guide](/knowledge/stripe-subscription-migration-guide/) - [Migration without customer action](/knowledge/migration-without-customer-action/) - [Application handover after migration](/knowledge/application-handover-after-stripe-migration/) - [SaaS acquisition billing handover checklist](/blog/saas-acquisition-checklist-billing-handover/) --- # Restricted Stripe API Keys: Scopes & Setup (2026) Canonical: https://movemrr.com/knowledge/restricted-stripe-api-keys/ > Which permissions a restricted Stripe key needs, how to create and validate one, and why source and destination accounts need separate scoped keys. **Direct answer:** A restricted Stripe API key is a secret key limited to the exact resources and permission levels you select — each resource (Customers, Subscriptions, Prices, …) is granted None, Read, or Write individually. You create one in the Dashboard under **Developers → API keys → Create restricted key**, and it behaves like a normal secret key everywhere the granted permissions suffice. Any tool that only needs part of your account should get a restricted key, never the full secret key. For migration work specifically: use separate, purpose-specific restricted keys for the source and destination Stripe accounts. Grant only the resources required by the selected migration features, validate the keys before a live run, store live keys in a secrets vault, and revoke them after the observation window. Do not paste a broad live secret key into migration software when a restricted key can perform the same scoped work. Primary source: [Stripe API-key security best practices](https://docs.stripe.com/keys-best-practices). ## Why the Two Keys Need Different Permissions The source and destination perform different jobs: - the **source** is read for Customers, subscriptions, catalog, and mappings, then may need Subscription write access for the selected deactivation strategy; - the **destination** is read and written because the migration creates or maps Customers, Products, Prices, Coupons, and subscriptions; - webhook permissions are only needed when webhook-endpoint migration is enabled. A read-only source key is not sufficient when MoveMRR is expected to cancel, pause, or mark source subscriptions to end. Conversely, granting write access to every Stripe resource would exceed the migration's needs. ## MoveMRR's Current Permission Profiles MoveMRR generates Stripe's restricted-key creation URL with these base permissions preselected: | Resource | Source key | Destination key | |---|---|---| | Customers | Read | Read and write | | Subscriptions | Read and write | Read and write | | Products | Read | Read and write | | Prices | Read | Read and write | | Coupons | Read | Read and write | | Payment methods | No base permission | Read | | Webhook endpoints | Read only when enabled | Read and write only when enabled | The profile can evolve with product capability. Use the permission list displayed inside the current MoveMRR project rather than copying an old checklist. ## Create and Validate Each Key 1. Open the Connect stage for the migration project. 2. Choose source or destination. 3. Review whether webhook-endpoint migration is enabled. 4. Open the generated Stripe restricted-key link. 5. Verify the preselected permissions in Stripe. 6. Create a clearly named key for that account and project. 7. Return it through MoveMRR's secure key form. 8. Confirm the reported account ID, live/test mode, and permission validation. 9. Repeat for the other account. Never send a live key through email, a ticket, chat, or a shared document. ## How MoveMRR Stores Keys The previous statement that MoveMRR "does not persist API keys" was inaccurate. MoveMRR stores project keys so that scheduled, rehearsed, and live work can use them. Current behaviour: - stored live keys use Supabase Vault; - live keys are not silently downgraded to insecure fallback storage when Vault is unavailable; - a stored key is not returned to the browser; - stored keys expire inside MoveMRR after 30 days, which does not revoke the underlying credential in Stripe; - rotation replaces the stored credential and resets its expiry; - the UI reports age, expiry, account, mode, and permission-validation status. This does not remove the account owner's responsibility to restrict, monitor, rotate, and revoke the key in Stripe. ## Key Lifecycle | Stage | Action | |---|---| | Preparation | Create one key per side and per purpose | | Rehearsal | Confirm test/live mode and validate required permissions | | Live cutover | Restrict operator access and monitor Stripe request logs | | Observation | Keep only the credentials required for agreed verification or follow-up | | Completion | Revoke migration keys in Stripe and remove them from the project | | Personnel change or suspected exposure | Rotate immediately and review Stripe activity | If a key appears in source code, logs, analytics, chat, or a public document, treat it as exposed and rotate it. ## Do Not Reuse the Migration Key in the Product The buyer's production application needs its own account-specific credential with a separate permission model and lifecycle. Do not turn a temporary MoveMRR migration key into the application's permanent Stripe key. After migration: - create or rotate the buyer application's production credentials; - deploy them from a secret manager; - verify the authenticated destination account; - replace the client-side publishable key separately; - deploy new webhook signing secrets; - revoke source and migration credentials when the cutover owner approves. See the [application handover runbook](/knowledge/application-handover-after-stripe-migration/). ## Security Limits A restricted key reduces impact; it does not make credential handling risk-free. A key with Subscription write access can still change financially important objects. Maintain: - two-step authentication for Stripe administrators; - the smallest operator group possible; - IP restrictions where compatible with the running environment; - Stripe request-log review; - an explicit live-run confirmation; - an incident owner and key-rotation procedure. MoveMRR never needs raw card numbers. Eligible payment credentials are copied by Stripe through the account-copy process. ## Related Resources - [Technical Stripe subscription migration guide](/knowledge/stripe-subscription-migration-guide/) - [Stripe Customer Data Copy](/knowledge/stripe-customer-data-copy/) - [Application handover after migration](/knowledge/application-handover-after-stripe-migration/) - [MoveMRR product manual](/docs/) --- # Stripe Sandbox Seeding for Migration Rehearsal Canonical: https://movemrr.com/knowledge/sandbox-seeding-guide/ > Seed realistic Stripe sandboxes with one-time keys, synchronized customers, mapping CSVs, and a controlled return to the MoveMRR migration pipeline. An empty Stripe sandbox can prove that buttons work. It cannot prove that your migration will work. Sandbox Seeding gives a MoveMRR sandbox project the catalog, discounts, tax rates, customers, and subscription shapes needed for a useful end-to-end rehearsal. It reads your live accounts with one-time keys, writes only to the corresponding Stripe sandboxes, and then creates the customer mapping needed to migrate between those sandboxes. This is an optional branch from the [main migration guide](/docs/#step-04). If both Stripe sandboxes already contain representative data, skip this article and continue with [Catalog](/docs/#after-seeding). ## First, Know Which Account Is Which You will work with four Stripe environments: | Role | Environment | What it represents | What MoveMRR does | |---|---|---|---| | Source live | Live | Seller’s current billing account | Reads it once to discover data | | Source sandbox | Test | Rehearsal version of the seller account | Creates the source test catalog and subscriptions | | Destination live | Live | Buyer’s current Stripe account | Reads it once to discover pre-existing data | | Destination sandbox | Test | Rehearsal version of the buyer account | Creates the destination’s pre-existing test data | The source and destination live accounts are never migration targets during seeding. All writes go to their Stripe sandboxes. ## What You Need Before opening the Seeding workspace, make sure: - You created a **Sandbox** migration in MoveMRR. Live projects cannot open the seeding route. - The source and destination cards on **Connect** contain the correct stored Stripe test keys. - You have administrator access to both live Stripe accounts and both Stripe sandboxes. - Two-step authentication is enabled where Stripe requires it to create restricted keys. - No migration run or seeding run is active on the project. - You can identify each account by its `acct_…` ID, not just its display name. MoveMRR uses two different key types for each side: 1. A **read-only live key** (`rk_live_…` or `sk_live_…`) to scan the live account. 2. A **write-capable sandbox key** (`rk_test_…` or `sk_test_…`) to create the discovered data in the matching Stripe sandbox. Both are validated for the current run and cleared after the run starts. They are separate from the stored source and destination keys used by the migration pipeline. ## What Gets Seeded | Entity | Behavior | |---|---| | Products and prices | Always selected. They are the dependency foundation for subscriptions and discounts. | | Coupons | Optional and selected by default. Existing fingerprinted objects are reused. | | Promotion codes | Optional and selected by default. Codes that cannot be recreated are reported as skipped or failed. | | Subscriptions | Optional and selected by default. Recreated against sandbox customers and mapped test prices. | | Tax rates | Optional and selected by default. Stripe creates new test IDs; MoveMRR tracks the mapping. | | Customers | Created in the destination by **Customer sync**, not by a source/destination seed toggle. | | Payment methods | Real card data is never copied. Customer sync attaches Stripe test payment methods. | | Stripe webhook endpoints | Not seeded. Configure them separately if your rehearsal depends on webhook delivery. | Seeding is designed to be repeatable. Objects carry fingerprints so completed work can be reused instead of duplicated. Still, always inspect **Created**, **Reused**, **Skipped**, and **Failed** counts after every run. ## Step 1: Open the Seeding Workspace Open the sandbox project and select **Connect** in the stage rail. Below the two key cards, find **Sandbox seeding** and select **Open workspace**. The workspace has three URL-backed tabs: - **Source** - **Destination** - **Customer sync** Refreshes and copied links preserve the selected tab. If MoveMRR redirects you back to Connect, verify that the project itself was created as **Sandbox**. Adding test keys to a Live project does not convert its environment. ## Step 2: Seed the Source Sandbox Open the **Source** tab. The page is deliberately divided into validation, entity selection, and execution. ### 2.1 Generate the source live key Under **1 · Validate live key**, select **Generate restricted key…**. Before following the Stripe link, verify: - You are signed into the seller’s **live** Stripe account. - The account ID shown in Stripe matches the source live account. - Stripe is in live mode, not a sandbox or test-mode view. The generated key should grant read access to the entities shown in MoveMRR’s permission matrix: customers, subscriptions, products, prices, coupons, promotion codes, and tax rates. Copy the key, paste it into **Read-only source live key**, then select **Validate live key**. ### 2.2 Review validation and preview counts A successful validation shows: - **Live account scanned** - The live `acct_…` ID - A **LIVE** badge - A permission matrix - Preview counts for products, coupons, promotion codes, subscriptions, tax rates, and customers Treat `100+` as “the preview page was truncated,” not as an exact total. The complete count becomes known during the seeding run. Stop if: - The account ID is wrong. - The badge says **TEST**. - A required permission is missing. - Counts are implausibly low or zero for a populated account. Edit the key or its permissions, then validate again. ### 2.3 Generate and validate the source sandbox key In the same card, continue to the sandbox key section and select the sandbox-key generator. In Stripe, confirm you are inside the **source sandbox**. Create a restricted test key with the requested write permissions, copy it, and paste it into MoveMRR. Select **Validate sandbox key**. A successful result shows: - **Sandbox writes validated** - The source sandbox `acct_…` ID - A **TEST** badge - The write-permission matrix This second validation prevents the most serious seeding error: scanning the correct live account but writing the result into the wrong sandbox. ### 2.4 Choose entities Products and prices are always selected. Keep Coupons, Promotion codes, Subscriptions, and Tax rates selected for the closest production rehearsal. Clear an entity only when you intentionally want to exclude it and understand what that removes from the test. Examples: - Clearing **Subscriptions** produces catalog data but gives the migration nothing to move. - Clearing **Coupons** can hide discount mapping failures. - Clearing **Tax rates** can hide tax-rate references used by subscriptions. ### 2.5 Start and inspect the run The **Start seeding run** button becomes available only after both one-time keys pass validation and no source seeding run is active. Select it and monitor the run card. Discovery can briefly show an indeterminate progress state while MoveMRR calculates total work. During execution, the card reports processed and total items. When terminal, expand the run and review: - Created - Reused - Skipped - Failed - Per-entity notes - Item errors and source IDs The displayed item-error list is capped at 200 entries. A cap notice means more errors may exist than are rendered. Do not continue to Customer sync until at least one source run is **Completed**. A completed run can still contain skipped items, so investigate the entity results first. ## Step 3: Seed the Destination Sandbox Open the **Destination** tab and repeat the same sequence for the buyer side: 1. Generate and validate a read-only key in the **destination live account**. 2. Verify the returned live account ID and preview counts. 3. Generate and validate a write-capable key in the **destination sandbox**. 4. Choose entities. 5. Select **Start seeding run**. 6. Expand the terminal result and review created, reused, skipped, and failed items. Why seed the destination too? A buyer account is rarely blank. Its existing catalog, coupons, customers, and identifiers are what expose collisions and incorrect assumptions during a real migration. Even if you want an almost-empty destination rehearsal, complete a destination seed run with the intended entity selection. The current Customer sync gate requires completed source and destination seeding evidence. Do not seed the migrating source customers directly into the destination sandbox. Customer sync handles those in the next step and generates the authoritative old-to-new mapping. ## Step 4: Run Customer Sync Open **Customer sync**. This tab does not ask for either live key. It uses the source and destination sandbox keys already stored on Connect. The **Run customer sync** button lists every unresolved blocker. It requires: - A stored source sandbox key - A stored destination sandbox key - A completed source seeding run - A completed destination seeding run - No active customer-sync run Select **Run customer sync**. MoveMRR: 1. Finds the customers behind the seeded source subscriptions. 2. Reuses matching destination sandbox customers when safe. 3. Creates missing destination sandbox customers. 4. Attaches Stripe test payment methods. 5. Generates the source-to-destination customer mapping CSV. 6. Registers that CSV as an upload on the project. Re-running customer sync is safe: existing customers are reused instead of duplicated. After completion, select **Open upload →** on the run card. MoveMRR takes you directly to **Customers** with the generated upload selected. ## Step 5: Verify the Seeded Rehearsal Data Before returning to the main migration path, make a short reality check in Stripe: - Source sandbox products and prices resemble the live source catalog. - Source sandbox subscriptions exist and reference the expected test customers and prices. - Destination sandbox contains the buyer-side objects you intended to reproduce. - Customer sync created or reused the expected number of destination customers. - The generated mapping upload is marked **Valid** in MoveMRR. - Payment-method coverage uses Stripe test methods and has no unexplained gaps. A clean “Completed” status means the run reached its end. It does not mean every source object was recreated. Skipped and failed entity counts are part of the result and must be reviewed. ## Safety Model Sandbox Seeding follows five boundaries: 1. **Live reads only.** The live key is used to scan; seeding never writes to a live Stripe account. 2. **Sandbox writes only.** The one-time sandbox key must validate as Test mode. 3. **Keys are one-time inputs.** Live and sandbox keys used for a seed run are cleared after the run starts and are not persisted as seeding credentials. 4. **Preview before execution.** Live validation shows account identity, permissions, and discovery counts before a run can start. 5. **One operation at a time.** Active seeding and migration operations are gated to avoid competing writes. ## Common Problems ### “Validate a live key first” The key was not validated, changed after validation, failed permissions, or is in Test mode. Paste a live-mode key and select **Validate live key** again. ### “Validate a write-capable sandbox key first” The second key is missing, in Live mode, belongs to the wrong sandbox, or lacks one of the required write permissions. Generate it from the current Source or Destination tab and validate it there. ### Preview says `100+` The preview reads only the first page of that Stripe resource. It is a lower bound, not an error and not the final total. ### Start is disabled Read the blocker list below the button. The UI names the missing validation or active run. Resolve every listed item; do not repeatedly click the disabled action. ### The run is stalled Check the heartbeat warning on the run card, then use **Refresh**. If the run remains active without a fresh heartbeat, keep its run ID and contact support before starting another operation. ### Customer sync is disabled Confirm both sandbox keys are stored on Connect and both Source and Destination have at least one completed seed run. The blocker list identifies the missing prerequisite. ### The generated CSV is not visible Expand the completed Customer sync run. **Open upload →** appears only when the run completed and produced a `csv_upload_id`. Refresh the run list if the card still shows an active status. ## Sandbox Fidelity Limits A sandbox is a rehearsal, not a byte-for-byte clone: - Real payment credentials never leave Stripe; test payment methods replace them. - Webhook endpoints are not seeded. - Account-level Stripe Tax, payment-method, branding, and business settings are not cloned. - Failed-payment history and every invoice state cannot be reproduced exactly. - Stripe may assign new IDs to recreated objects; MoveMRR records mappings and fingerprints. - External systems that react to Stripe webhooks need their own sandbox configuration. Interpret the rehearsal accordingly: it is strong evidence for catalog mappings, customer mappings, subscription creation, configuration, and run behavior. It is not proof that unrelated account-level settings are identical. ## Return to the Main Migration Seeding and customer sync are now complete. Continue with: 1. **Catalog** — map or auto-create the migration catalog. 2. **Customers** — keep the generated customer-sync upload selected and verify payment-method coverage. 3. **Configure** — review source deactivation, billing cycles, trials, metadata, and scope. 4. **Rehearse** — validate readiness, dry run, and simulate. 5. **Launch** — execute the sandbox migration. 6. **Verify** — reconcile the two sandboxes and inspect follow-ups. [Return to the main guide at Catalog →](/docs/#after-seeding) ## Related Resources - [MoveMRR product manual](/docs/) - [Restricted Stripe API Keys](/knowledge/restricted-stripe-api-keys/) - [Stripe Customer Data Copy](/knowledge/stripe-customer-data-copy/) - [Preventing Double Billing](/knowledge/prevent-double-billing/) --- # Stripe Customer Data Copy: Capabilities and Limits Canonical: https://movemrr.com/knowledge/stripe-customer-data-copy/ > What Stripe can copy between accounts in 2026, what remains in the source account, and how payment-method limits affect subscription migration. **Direct answer:** Stripe can copy eligible Customer records and supported saved payment methods from one Stripe account to another. It does not copy Subscription objects, invoices, plans, coupons, events, or logs. Subscription migration is a separate recreation and cutover process. Stripe calls this a **copy**, not a move. Source data remains available in the original account. ## Current Copy Matrix Stripe's current support documentation lists the following: | Data | Copy status | Important detail | |---|---|---| | Customer name, email, phone, and address | Supported | Customer-level fields | | Customer default payment method | Supported when the underlying method is eligible | Verify the destination default after the copy | | Customer metadata | Supported | Subscription metadata is a separate object | | Cards | Supported | Card, Source, and PaymentMethod representations are listed | | ACH | Supported | Bank-account and PaymentMethod representations are listed | | SEPA PaymentMethod | Supported | Legacy SEPA Source objects are excluded | | Subscription | Not copied | Recreate or import in the destination | | Invoice and charge history | Not copied | Retain appropriate source-account access | | Product, plan, and Price configuration | Not copied through Customer Data Copy | Prepare destination catalog separately | | Coupons | Not copied | Recreate and map where supported | | Events and logs | Not copied | Keep source records for audit and support | | Bacs PaymentMethod | Not copied between Stripe accounts | Plan customer remediation | | Connected accounts and guest customers | Not copied | Requires a separate account-specific plan | Primary source: [Data that can be copied between Stripe accounts](https://support.stripe.com/questions/data-that-can-be-copied-between-stripe-accounts?locale=en-GB). ## What Happens to Stripe IDs? Stripe currently states that copied Customer objects keep the same Customer ID in the destination account. Payment-method IDs change even though the copied objects refer to the same eligible payment credentials. Do not extrapolate this to every object: - destination subscriptions get new `sub_…` IDs; - destination payment methods get new IDs; - Products, Prices, Coupons, Tax objects, and webhooks are account-specific; - historical invoices, charges, events, and logs remain source-account objects. Reconcile the result of the actual copy and migration. Do not make an application cutover depend solely on the expected ID behaviour. ## Why Customer Data Copy Is Not Subscription Migration Customer Data Copy prepares the billing relationship at the Customer and payment-method layer. A destination subscription still needs: - a destination Customer with a valid default payment method; - a destination Product and recurring Price; - quantity and multiple-item configuration; - billing date, trial, and collection method; - discount and tax treatment; - metadata needed by the application; - a coordinated source-deactivation decision. Stripe now provides a [Billing migration toolkit](https://docs.stripe.com/billing/subscriptions/import-subscriptions-toolkit) for importing this subscription configuration from a CSV, including Stripe-to-Stripe use cases. MoveMRR provides an alternative workflow that coordinates mappings, rehearsal, source deactivation, reconciliation, and the buyer/seller audit record. ## Can the Copy Avoid Customer Action? Stripe says customers are not informed when eligible data is copied in the background. That means a migration can often avoid asking every customer to register again or re-enter a card. It does not guarantee that every future renewal succeeds without customer action: - the payment method might be excluded from copying; - the destination Customer might not have a usable default; - the method might expire or be declined; - an issuer can require SCA or 3DS authentication; - legal consent or mandate requirements can differ by payment method and transaction. Use the [customer-action decision table](/knowledge/migration-without-customer-action/) to classify the migration population before cutover. ## Operational Checklist ### Before the Copy - Confirm source and destination account ownership with Stripe. - Identify every payment-method type in scope. - Separate unsupported methods and guest customers. - Preserve source account access for history and disputes. - Prepare the destination account's business, statement, invoice, tax, and dunning settings. ### After the Copy - Compare Customer counts and actual destination IDs. - Verify intended default payment methods. - Sample cards, ACH, and SEPA PaymentMethod cases. - Export explicit remediation lists for missing or unsupported methods. - Test the destination payment-update and authentication flow. - Only then schedule or create destination subscriptions. ## Using the Copy with MoveMRR MoveMRR does not receive raw card numbers and does not replace Stripe's credential-copy process. It uses the destination Customer state and project mappings to prepare subscription recreation. A MoveMRR project can then: 1. scan and validate the source data; 2. map destination catalog objects; 3. rehearse and run a dry run; 4. create destination subscription objects; 5. apply the selected source-deactivation strategy; 6. reconcile per-item results and export destination IDs. Any unsupported payment method remains an explicit follow-up rather than being hidden behind a "no customer action" claim. ## Related Resources - [Technical Stripe subscription migration guide](/knowledge/stripe-subscription-migration-guide/) - [Migration without customer action](/knowledge/migration-without-customer-action/) - [Stripe Billing Migration Toolkit vs MoveMRR](/compare/stripe-billing-migration-toolkit/) - [Application handover after migration](/knowledge/application-handover-after-stripe-migration/) - [Restricted Stripe API keys](/knowledge/restricted-stripe-api-keys/) --- # Migrate Stripe Subscriptions to Another Account (2026) Canonical: https://movemrr.com/knowledge/stripe-subscription-migration-guide/ > Step-by-step: copy customers, recreate subscriptions in the new Stripe account, keep renewal dates, deactivate the source. Toolkit vs MoveMRR compared. **Direct answer:** Stripe subscriptions are not moved as the same objects from one Stripe account to another. A cross-account migration prepares eligible customer and payment data, then creates new subscription objects in the destination account. Stripe now provides a Billing migration toolkit for this recreation. MoveMRR adds a controlled buyer/seller workflow for mappings, rehearsal, source deactivation, reconciliation, and application handover. Before migrating, check whether the business can keep the existing Stripe account and transfer ownership. That avoids recreating subscriptions, but Stripe must confirm any legal-entity or country change. ## Choose the Correct Account Path First | Situation | Path to evaluate | |---|---| | Same business entity and Stripe account can remain with the company | Stripe account ownership transfer | | Buyer needs its own Stripe account | Cross-account subscription migration | | Seller retains other products or customers in the source account | Scoped cross-account migration | | Acquiring entity is in a different country | Contact Stripe Support before choosing | | Buyer already operates a destination Stripe account | Cross-account migration, followed by application handover | See [account ownership transfer vs subscription migration](/knowledge/account-ownership-vs-subscription-migration/) for the full decision. ## Understand the Three Separate Data Layers ### 1. Customer and Payment Data Stripe Customer Data Copy can copy eligible Customers and supported saved payment methods between accounts. Stripe currently documents cards, ACH, and SEPA PaymentMethod objects among the supported types. It does **not** copy subscriptions, invoices, plans, coupons, events, or logs. Customer IDs currently remain the same according to Stripe's account-copy documentation, while payment-method IDs change. Reconcile the actual output from your copy rather than hard-coding that assumption. Primary source: [Data that can be copied between Stripe accounts](https://support.stripe.com/questions/data-that-can-be-copied-between-stripe-accounts?locale=en-GB). ### 2. Catalog and Subscription Configuration The destination needs valid account-specific Products, Prices, Coupons, Tax settings, collection methods, trial dates, quantities, and billing-cycle decisions. Source IDs generally cannot be used as destination IDs. Stripe's [Billing migration toolkit](https://docs.stripe.com/billing/subscriptions/import-subscriptions-toolkit) accepts CSV templates for basic, multi-price-item, and ad-hoc-price subscriptions. It validates the data and creates destination Subscription Schedules. An internal API importer or MoveMRR can provide alternative recreation workflows. ### 3. Application Integration The new destination subscriptions have new Stripe IDs. The buyer must update local database mappings, API credentials, webhook endpoints and signing secrets, Customer Portal links, analytics, and entitlement logic. Use the [application handover runbook](/knowledge/application-handover-after-stripe-migration/) before declaring the migration complete. ## Required Inputs Prepare: - written source and destination account ownership; - the exact in-scope Customer and Subscription population; - destination customer/payment copy results; - source-to-destination Product, Price, Coupon, and Tax mappings; - trial, billing-cycle, collection-method, metadata, and past-due rules; - a selected source-deactivation strategy; - destination account settings for tax, invoices, receipts, statement descriptors, dunning, and portal; - application owners for secrets, IDs, webhooks, and entitlements; - a rollback or manual-remediation owner for every known exception. Do not use subscription count alone as a readiness signal. ## Compare the Recreation Options | Option | Strength | Work the operator still owns | |---|---|---| | Stripe Billing migration toolkit | Official no-code CSV import, validation, scheduled go-live | Data preparation, destination IDs, source cancellation, application cutover, reconciliation | | Internal API workflow | Maximum control for a known billing model | Engineering, testing, idempotency, audit, maintenance, and incident response | | MoveMRR | Shared project for readiness, mappings, dry run, live execution, source deactivation, and results | Stripe account approval, payment-data eligibility, legal/tax decisions, and application deployment | Read the detailed [Stripe Billing Migration Toolkit vs MoveMRR comparison](/compare/stripe-billing-migration-toolkit/). ## Rehearsal and Readiness Gates Run a representative sandbox rehearsal and a no-write dry run. The live gate should confirm: - expected source and destination account IDs; - exact in-scope Customer and Subscription counts; - every required destination mapping; - supported and unsupported payment-method cases; - recurring amounts, currencies, intervals, and quantities; - billing-cycle anchors, next billing dates, and trial ends; - automatic collection vs send-invoice subscriptions; - tax and discount treatment; - source-deactivation consequences; - webhook and application owners; - explicit exception and remediation lists. A dry run validates known state. It cannot guarantee a future issuer authorization or remove SCA requirements. ## Cutover Sequence 1. Freeze or tightly control subscription/catalog changes during the final snapshot. 2. Complete and reconcile Stripe's eligible customer/payment-data copy. 3. Finalize destination catalog and object mappings. 4. Run readiness and dry-run checks against the latest source state. 5. Create or schedule destination subscriptions on the agreed billing boundary. 6. Independently verify destination configuration and counts. 7. Complete the chosen source-deactivation action before an overlapping source renewal. 8. Deploy destination API keys, IDs, webhook secrets, and portal configuration. 9. Reconcile exceptions and monitor the first renewal cohorts. Stripe advises creating destination subscriptions before cancelling the old subscriptions, while also cancelling the old subscriptions before the new ones are due to charge. When a renewal is too close to the migration, schedule the destination start after that cycle. ## Avoid These Four Failure Modes ### Double Billing Both accounts remain able to collect for the same period. Prevent it with a documented billing boundary, future destination start, verified source deactivation, and invoice monitoring—not with a blanket promise. See [preventing double billing](/knowledge/prevent-double-billing/). ### Missing or Wrong Default Payment Method A Customer can exist in the destination without a usable default. Separate automatic cases from remediation cases before scheduling. See [migration without customer action](/knowledge/migration-without-customer-action/). ### Billing-Date Drift Creation time, `start_date`, `billing_cycle_anchor`, `trial_end`, and proration interact. Compare the next expected charge, not only a single timestamp. See [billing-cycle anchors](/knowledge/billing-anchors-explained/). ### Application Still Uses the Source Account Billing can succeed while the product listens to the old webhook endpoint or looks up the old Subscription ID. Include the application deployment in the same cutover plan. ## What MoveMRR Adds MoveMRR provides: - restricted-key permission validation; - sandbox seeding and rehearsal support; - source/customer/catalog mapping; - readiness checks and a dry run; - configurable handling for billing cycles, trials, metadata, and source deactivation; - idempotent run records and per-item results; - reconciliation, exception follow-ups, and downloadable ID maps; - optional supported webhook-endpoint recreation. MoveMRR does not receive raw card numbers, decide legal/tax treatment, guarantee bank authorization, or eliminate unsupported payment-method remediation. ## Official Sources - [Stripe subscription migration overview](https://docs.stripe.com/billing/subscriptions/migrate-subscriptions) - [Stripe Billing migration toolkit](https://docs.stripe.com/billing/subscriptions/import-subscriptions-toolkit) - [Data that can be copied between Stripe accounts](https://support.stripe.com/questions/data-that-can-be-copied-between-stripe-accounts?locale=en-GB) - [Stripe account transfer after a sale or acquisition](https://support.stripe.com/questions/transfer-a-stripe-account-to-a-different-entity-due-to-a-business-sale-or-acquisition?locale=en-GB) - [Stripe subscription webhooks](https://docs.stripe.com/billing/subscriptions/webhooks) ## Related Resources - [MoveMRR product manual](/docs/) - [Stripe Billing Migration Toolkit vs MoveMRR](/compare/stripe-billing-migration-toolkit/) - [Migration without customer action](/knowledge/migration-without-customer-action/) - [Restricted Stripe API keys](/knowledge/restricted-stripe-api-keys/) - [SaaS acquisition billing handover checklist](/blog/saas-acquisition-checklist-billing-handover/) ## Frequently asked questions **Can you migrate Stripe subscriptions to another Stripe account?** Yes. Stripe cannot move a live subscription object between accounts, but you can copy eligible customers and saved payment methods with Customer Data Copy and recreate the subscriptions in the destination account so renewal dates are preserved. **Do customers have to re-enter their card details after a Stripe-to-Stripe migration?** Usually not. For eligible account pairs, Stripe copies supported saved payment methods between accounts, and recreated subscriptions charge the copied payment method. Verify payment-method eligibility for the specific account pair before cutover. **How long does a Stripe subscription migration take?** The API work itself typically completes within hours even for tens of thousands of subscriptions. Calendar time is dominated by preparation, sandbox rehearsal, the scheduled cutover window, and post-run reconciliation — plan in days, not minutes. **What is the difference between transferring a Stripe account and migrating subscriptions?** An account transfer changes who owns the existing Stripe account and keeps every object intact; a subscription migration recreates the data in a different account. Transfer when the legal entity and country allow it; migrate when the buyer needs its own account. --- # How to Sell Your SaaS Business: A Complete Exit Guide Canonical: https://movemrr.com/blog/how-to-sell-your-saas-business/ > Learn how to sell a SaaS business successfully — from valuation to closing. A practical exit guide covering every stage of the SaaS acquisition process. Selling a SaaS business combines valuation, diligence, legal structure, operational transfer, and a live customer handover. Preparation does not guarantee a price or timeline, but it gives a buyer reproducible financial evidence and a clear plan for taking control before the first letter of intent arrives. ## What Makes a SaaS Business Attractive to Buyers Before diving into process, it helps to think like a buyer. Acquirers — whether strategic operators, indie hackers, or private equity roll-ups — are underwriting risk. Every due diligence request is really a question: *"What could go wrong after we wire the money?"* The latest [Acquire.com acquisition-multiples report](https://blog.acquire.com/acquire-com-biannual-acquisition-multiples-report-jan-2026/) says profitable SaaS companies on its marketplace attracted stronger buyer interest and that confirmed 2024 and 2025 sales had a median profit multiple of 3.9×. The report covers Acquire.com's own transaction population—mostly businesses below $10 million enterprise value—not every SaaS transaction. Buyers also look for: - **Revenue predictability**: Monthly recurring revenue (MRR) from annual contracts or low-churn monthly plans signals stable cash flow - **Visible customer concentration**: Buyers can see how much recurring revenue depends on each major customer and when those contracts renew - **Clean infrastructure**: Documented codebase, reproducible deployments, no critical single points of failure - **Billing hygiene**: Subscription data that matches accounting records and can be transferred without disruption That last point is where many deals get complicated. Stripe subscriptions, billing anchors, and payment method portability are technical concerns that have real financial consequences at close. ## How to Value a SaaS Business Before You List SaaS business valuation follows a handful of established frameworks, but the market ultimately sets the price. Understanding the inputs helps you negotiate from an informed position. ### Profit and Revenue Multiples The valuation measure must match the company. Acquire.com's January 2026 report focuses on profit multiples for profitable, smaller SaaS transactions and says high-growth companies that reinvest heavily may instead be valued on revenue. | Measure | Calculation | Main diligence question | |---|---|---| | Profit multiple | Enterprise value ÷ normalized annual profit | Are costs and proposed add-backs complete and repeatable? | | ARR multiple | Enterprise value ÷ annual recurring revenue | Which revenue is genuinely recurring and currently contracted? | | Revenue multiple | Enterprise value ÷ trailing or forward revenue | Does growth and retention justify valuing revenue before current profit? | The same headline multiple can describe different economics if one party uses SDE and another uses EBITDA or ARR. Define the numerator, denominator, period, currency, debt, cash, working capital, and contingent consideration before comparing offers. The source-backed [2026 SaaS valuation guide](/blog/saas-valuation-multiples/) explains the current benchmark and its limitations. ### The Factors That Move Your Multiple Up - **Consistent growth evidence**: Monthly results use the same definitions and reconcile to financial records - **Retention quality**: Cohorts separate expansion, contraction, churn, refunds, and failed collections - **Sustainable acquisition**: Customer acquisition cost, payback, and lifetime-value assumptions are documented - **Documented processes**: SOPs that let a new owner operate without the founder - **Transferable contracts**: No personal guarantees or non-transferable enterprise agreements ### The Factors That Drag Your Multiple Down - Unexplained churn or changing cohort definitions - Heavy founder dependency — if you are the product, buyers price in key-person risk - Undocumented technical debt or outdated dependencies - Revenue that isn't truly recurring (lumpy one-off projects billed as subscriptions) - Billing infrastructure that can't be cleanly transferred ## How to Prepare Your SaaS for Sale Begin preparation early enough to correct records, document operations, and observe whether improvements persist. The right lead time depends on the company's condition and the intended transaction. ### Clean Up Your Metrics Dashboard Buyers will ask for P&L statements, MRR movement reports (new, expansion, contraction, churn), and cohort retention data. If you're pulling these from a spreadsheet, migrate to a proper analytics tool. [Baremetrics](https://baremetrics.com), ChartMogul, or even Stripe's built-in analytics give buyers confidence that the numbers are auditable. Reconcile your Stripe MRR against your accounting software. Discrepancies — even small ones — create doubt that derails deals. ### Document the Business Thoroughly Create a standard operating procedures (SOPs) document covering: - Customer onboarding and offboarding - Support escalation process - Infrastructure deployment and monitoring - Common bug patterns and known workarounds - Vendor relationships and renewal dates A buyer who can see themselves operating the business without you is a buyer who'll move quickly and pay your asking price. ### Prepare Your Billing Infrastructure for Transfer This is the step most founders overlook until they're already under LOI. Stripe does not automatically change the account or move existing Subscription objects when a business changes hands. The parties must choose an approved account-ownership or separate-account migration path. The [Stripe subscription migration guide](/knowledge/stripe-subscription-migration-guide/) covers the technical mechanics. For a separate-account migration, Stripe can copy eligible customer/payment data and its Billing migration toolkit can import subscription configuration. The buyer and seller still need to coordinate billing dates, source deactivation, reconciliation, and application IDs. Understanding [what happens to Stripe subscriptions when you sell your SaaS](/blog/what-happens-to-stripe-subscriptions-when-you-sell-your-saas) before you get to closing will save you from surprises that delay or kill deals. ## Where to List and Find Buyers for Your SaaS Business Your exit strategy determines where you should list your business. The main channels each attract different buyer profiles. ### SaaS Marketplaces - **[Acquire.com](https://acquire.com)**: A marketplace focused on startup acquisitions. The seller creates a listing; qualified buyers can review the opportunity and initiate contact. - **[MicroAcquire (now Acquire.com)](https://acquire.com)**: Same platform, rebranded. Focused on bootstrapped and early-stage SaaS. - **[Flippa](https://flippa.com)**: Broader marketplace including content sites and apps. SaaS deals happen here but buyer quality varies. - **[Empire Flippers](https://empireflippers.com)**: A curated marketplace for online businesses with its own listing and diligence process. ### M&A Advisors and Brokers A specialist SaaS adviser or broker can manage buyer outreach, confidentiality, qualification, and negotiation. Fees, minimum deal size, exclusivity, and service scope vary by provider; obtain the current terms in writing and compare the expected work with a direct process. Notable SaaS-focused advisors include FE International, Quiet Light Brokerage, and Website Properties. ### Direct Outreach Many of the best SaaS acquisitions happen off-market. If you know operators in adjacent spaces, a direct conversation can surface buyers who'd pay a strategic premium. This works best when you have a specific acquirer in mind — a competitor, a portfolio company of a relevant PE firm, or a founder who's been vocal about wanting to acquire. ## The SaaS Exit Process: From LOI to Close Once you have interested buyers, the process typically follows a predictable structure — though timelines vary significantly by deal size and complexity. ### Phase 1: Initial Interest and NDA Qualified buyers sign an NDA before accessing your financials. Treat this seriously: share a clean "teaser" document (high-level metrics without identifying information) before revealing the business identity. ### Phase 2: Letter of Intent (LOI) An LOI is generally intended to record the proposed deal structure: purchase price, payment terms, transition expectations, and exclusivity. Which clauses are binding and how long exclusivity lasts depend on the document and jurisdiction; obtain legal advice before signing. Detailed diligence usually takes place during the agreed exclusivity period. Negotiate the LOI carefully. Earnouts are common but create perverse incentives if structured poorly. Seller financing (where you carry a note for part of the purchase price) can increase your total take but introduces collection risk. ### Phase 3: Due Diligence Buyers verify everything in your listing. Expect requests for: - 24 months of bank statements and payment processor records - Stripe MRR reports and subscription export - Google Analytics or equivalent traffic data - Code repository access (often read-only) - Customer contracts and terms of service - Cap table and corporate structure documentation - Key vendor and infrastructure agreements Prepare a due diligence data room before entering exclusivity. Google Drive or Notion work fine for smaller deals; larger transactions use purpose-built VDR platforms. ### Phase 4: Closing and Asset Transfer For asset sales (the most common structure for smaller SaaS deals), closing involves: 1. Signing the Asset Purchase Agreement (APA) 2. Transferring the domain and DNS 3. Transferring the code repository 4. Migrating customer data and subscriptions 5. Handing over third-party accounts (analytics, support tools, etc.) 6. Receiving payment (often via escrow) The [SaaS acquisition billing handover checklist](/blog/saas-acquisition-checklist-billing-handover) breaks down the closing sequence for billing infrastructure specifically — it's worth reviewing before you begin any transfer conversation with a buyer. ## Common SaaS Exit Mistakes (and How to Avoid Them) ### Waiting Until You're Burned Out to Sell Buyers can tell when a founder is exhausted. Metrics often reflect it: slower growth, deferred maintenance, rising churn. Sellers who exit from a position of strength — growing, profitable, operationally healthy — command dramatically better terms. ### Underestimating Billing Migration Complexity Subscription migration is not a copy-paste operation. Stripe does not move an existing Subscription object between standalone accounts, but it now offers a Billing migration toolkit for recreating subscriptions from a validated CSV. Eligible payment data can be copied through Stripe, while billing dates, source deactivation, and application IDs still need a controlled handover. [Double billing](/knowledge/prevent-double-billing) remains a cutover risk. Using a purpose-built workflow like [MoveMRR](/) reduces manual coordination by keeping readiness, mappings, dry runs, source-deactivation choices, and reconciliation in one project. It does not replace Stripe approval, payment-method remediation, legal review, or the buyer's [application handover](/knowledge/application-handover-after-stripe-migration/). ### Negotiating Price While Ignoring Terms A $500K all-cash offer often beats a $650K offer with a $200K earnout tied to metrics you won't control post-close. Model different scenarios. Understand the tax implications of your deal structure — asset sales vs. stock sales have meaningfully different treatment in most jurisdictions. Work with a tax advisor who has SaaS M&A experience. ### Skipping Legal Review Template APAs circulate in founder communities. Don't use them for a transaction of consequence without having an attorney review representations, warranties, indemnification caps, and non-compete clauses. The cost of a few hours of legal review is trivial relative to the exposure a poorly drafted APA creates. ## Your SaaS Exit Strategy Checklist Before you list your business, confirm you can check each of these: - [ ] 24 months of clean, reconciled financials with MRR broken out - [ ] Churn and NRR documented by cohort - [ ] Technical documentation and SOPs exist - [ ] No undisclosed customer concentration issues - [ ] All contracts are assignable or the transfer mechanism is understood - [ ] Stripe subscriptions audited and migration path identified - [ ] Data room prepared with all due diligence documents - [ ] Legal counsel identified for APA review - [ ] Tax structure modeled with an advisor - [ ] Transition plan drafted (how long you'll support the buyer post-close) ## Handling the Subscription Migration at Close The billing migration is often the last obstacle between a signed APA and a funded escrow. Buyers are nervous about taking on recurring billing for customers they don't know, and sellers are nervous about canceling subscriptions before they've confirmed the new ones work. MoveMRR was built specifically for this handover moment. It coordinates Stripe-to-Stripe subscription recreation, handles supported billing anchors, validates [restricted API key setup](/knowledge/restricted-stripe-api-keys), and gives both parties a shared view of migration progress. Exceptions still require operator review. Visit the [MoveMRR product manual](/docs/) for a full walkthrough of how the platform handles each stage of the billing transfer. A documented billing migration gives both sides evidence about what was recreated, what remained in the source, which identifiers changed, and which exceptions still need an owner. --- Selling a SaaS business rewards preparation, but no checklist guarantees price, timing, or closing. Reconcile the numbers, document the operating system, obtain qualified legal and tax advice, and make the billing handover an explicit closing workstream instead of a last-day surprise. ## Sources and scope - [Acquire.com Biannual Acquisition Multiples Report, January 2026 edition](https://blog.acquire.com/acquire-com-biannual-acquisition-multiples-report-jan-2026/) - [Stripe: transfer an account after a business sale or acquisition](https://support.stripe.com/questions/transfer-a-stripe-account-to-a-different-entity-due-to-a-business-sale-or-acquisition?locale=en-GB) - [Stripe: data that can be copied between accounts](https://support.stripe.com/questions/data-that-can-be-copied-between-stripe-accounts?locale=en-GB) - [Stripe Billing migration toolkit](https://docs.stripe.com/billing/subscriptions/import-subscriptions-toolkit) This guide is educational information, not legal, tax, accounting, investment, brokerage, or valuation advice. Marketplace data describes its source population and should not be treated as a universal transaction benchmark. --- # SaaS Acquisition Checklist: Billing Handover Canonical: https://movemrr.com/blog/saas-acquisition-checklist-billing-handover/ > Complete checklist for handling billing and subscription transfer during a SaaS acquisition. Covers pre-close, closing, and post-close steps. Acquiring a SaaS business involves many moving parts. While code, domain, and customer data get attention, billing handover is often underestimated — until it becomes a problem. This checklist covers everything you need for a clean billing and subscription transition. ## Pre-Close: Preparation Phase ### 2-4 Weeks Before Close - [ ] **Choose the account path**: Ask Stripe whether the existing account can transfer with the entity or whether the buyer needs a separate-account migration - [ ] **Review subscription data**: Get a complete list of active subscriptions, including plan types, billing periods, and MRR breakdown - [ ] **Understand the billing setup**: Document what payment processor is used, any payment gateways, dunning settings, etc. - [ ] **Check for complexities**: Note any grandfathered plans, custom pricing, annual prepayments, or unusual configurations - [ ] **Verify customer payment methods**: Confirm payment methods are current and not failing ### 1-2 Weeks Before Close - [ ] **Start any required Customer Data Copy**: Confirm supported payment methods and timing directly with Stripe - [ ] **Create restricted API keys**: Set up keys in both source and destination Stripe accounts - [ ] **Set up destination account**: Ensure products and prices exist in the buyer's Stripe account - [ ] **Prepare price mapping**: If Price IDs differ, document the mapping ### 1 Week Before Close - [ ] **Receive mapping CSV**: Confirm Stripe has completed Customer Data Copy - [ ] **Validate the data**: Check that customer counts and payment methods match expectations - [ ] **Test with subset**: If possible, test the migration process with a small subset first - [ ] **Prepare communication**: Draft any customer notifications if needed ## At Close: Migration Execution ### Migration Day - [ ] **Freeze customer actions**: Consider temporarily pausing self-service subscription changes - [ ] **Run final validation**: Confirm all subscriptions are in expected state - [ ] **Execute migration**: Run the subscription recreation process - [ ] **Verify creation**: Confirm each new subscription is active in destination account - [ ] **Cancel old subscriptions**: Deactivate source subscriptions only after verification - [ ] **Document everything**: Save complete logs and audit trail - [ ] **Deploy the application handover**: Switch credentials, Stripe ID mappings, webhooks, portal links, and entitlement logic to the destination account ### Verification - [ ] **Count subscriptions**: New account subscription count matches source - [ ] **Check billing dates**: Sample subscriptions have correct billing anchors - [ ] **Verify amounts**: Subscription amounts match expected pricing - [ ] **Test Stripe Dashboard**: Buyer can access and manage subscriptions ## Post-Close: Stabilization ### First 24 Hours - [ ] **Monitor for errors**: Watch for failed payments or unexpected charges - [ ] **Check customer support**: Be ready for any billing-related questions - [ ] **Confirm webhooks**: Ensure new account receives subscription events ### First Week - [ ] **First billing cycle**: Verify that scheduled renewals process correctly - [ ] **Review any failures**: Address payment failures with appropriate dunning - [ ] **Customer communication**: Handle any questions or concerns ### First Month - [ ] **Complete audit**: Reconcile destination billing and any owned exceptions - [ ] **Retain legacy access**: Keep the source records required for historical invoices, events, disputes, tax, and support; do not close the account without an approved retention plan - [ ] **Archive documentation**: Store migration records for future reference ## Common Issues and Solutions ### Missing Payment Methods **Symptom**: Some customers show as "no payment method" in new account **Cause**: Payment method may not have been included in Customer Data Copy **Solution**: Customer will need to re-enter payment details; reach out proactively ### Incorrect Billing Dates **Symptom**: Customer reports being charged on unexpected date **Cause**: Billing anchor wasn't set correctly during recreation **Solution**: Adjust anchor or provide credit/refund as appropriate ### Double Charges **Symptom**: Customer charged by both old and new subscription **Cause**: Old subscription wasn't canceled before new one billed **Solution**: Immediate refund, customer communication, process review ### Subscription Not Found **Symptom**: Active subscription in source not appearing in migration **Cause**: Mapping CSV may be incomplete or subscription state changed **Solution**: Manually handle outliers, investigate root cause ## Special Considerations ### Annual Subscriptions Annual subscriptions have already collected revenue. Agree on: - How prepaid revenue is handled in purchase price - Whether subscriptions are migrated or left to expire ### Trials in Progress Customers on trial need careful handling: - Migration should preserve trial end date - First charge should align with trial completion ### Failed Payment States Subscriptions with past-due invoices: - Decide whether to collect the open invoice before the handover or write it off - MoveMRR can migrate past-due subscriptions as an explicit per-run opt-in: the open invoice on the source account is voided (the outstanding amount is written off) and billing restarts at the next regular cycle in the destination account ### Enterprise/Custom Deals Large customers with custom arrangements: - Document any special terms - May need individual migration approach ## Legal and Tax Considerations This is a billing transition, so involve appropriate advisors for: - Tax reporting implications of the transition - Revenue recognition for in-progress billing periods - Any contractual obligations around payment processing changes ## Tools and Resources ### For Migration - **MoveMRR**: Controlled subscription-migration workflow with readiness checks and reconciliation - **[Stripe Customer Data Copy](https://support.stripe.com/questions/data-that-can-be-copied-between-stripe-accounts?locale=en-GB)**: Official Stripe process and current eligibility limits - **[Stripe Billing migration toolkit](https://docs.stripe.com/billing/subscriptions/import-subscriptions-toolkit)**: Official CSV validation and destination subscription scheduling - **[Restricted API keys](https://docs.stripe.com/keys-best-practices)**: Stripe's security guidance for scoped credentials ### For Documentation - Spreadsheet of all subscriptions with mapping - Complete audit log from migration tool - Confirmation screenshots from Stripe Dashboard ## Primary-source checkpoint Before assigning dates in the purchase agreement, re-check Stripe's current guidance for [account transfer after a sale](https://support.stripe.com/questions/transfer-a-stripe-account-to-a-different-entity-due-to-a-business-sale-or-acquisition?locale=en-GB), [copyable account data](https://support.stripe.com/questions/data-that-can-be-copied-between-stripe-accounts?locale=en-GB), the [Billing migration toolkit](https://docs.stripe.com/billing/subscriptions/import-subscriptions-toolkit), and [webhook security](https://docs.stripe.com/webhooks). Availability and eligible payment methods can depend on the actual account pair, countries, and Stripe approval. --- *Planning a SaaS acquisition? See the [MoveMRR product manual](/docs/), compare [account ownership and subscription migration](/knowledge/account-ownership-vs-subscription-migration/), and include the [application handover runbook](/knowledge/application-handover-after-stripe-migration/) in the closing plan.* --- # SaaS Asset Sale vs Share Sale: Stripe Handover Canonical: https://movemrr.com/blog/saas-asset-sale-vs-share-sale-stripe-handover/ > A buyer-and-seller decision guide for keeping the existing Stripe account or migrating subscriptions to a separate account after a SaaS sale. **Direct answer:** A share sale can make keeping the existing Stripe account the practical starting point because the operating entity remains in place. An asset sale more often points to a separate buyer account because selected assets move to another entity. Neither outcome is automatic: Stripe must confirm the permitted account changes, and the transaction documents must define who owns billing, liabilities, records, and cutover work. For this guide, **share sale** means the buyer acquires ownership of the entity that operates the SaaS, while **asset sale** means selected business assets and obligations move to a buyer entity. The precise legal and tax treatment depends on the jurisdiction and the signed documents. This is an operational Stripe handover guide, not legal or tax advice. ## The Decision in One Table | Deal fact | Existing Stripe account may fit | Separate buyer Stripe account may fit | |---|---|---| | The operating entity continues after a share sale | Often, if Stripe confirms the required changes | If the buyer requires account separation | | Selected SaaS assets move to a different entity | Only if Stripe confirms that account transfer is permitted | Often | | The source account bills products excluded from the deal | Rarely | Usually, with an explicit in-scope population | | The buyer and seller entities are in different countries | Requires a different Stripe process and Support review | Often, subject to country and payment-method support | | The buyer wants historical objects and existing Stripe IDs to remain in place | Stronger fit | Historical records remain in the source account | | The buyer already has a configured Stripe account | Less likely | Stronger fit | | The transaction requires a clean future revenue boundary | Possible only if the whole account belongs with the business | Stronger fit, but the source cutover must be controlled | The deal label is only the first signal. The account's legal entity, country, product scope, historical liabilities, and application dependencies determine the implementation. ## Why “Share Sale” Does Not Automatically Mean “Transfer the Login” Stripe distinguishes the person who owns Dashboard access from the business information attached to the account. Stripe documents a process for a current account owner to transfer ownership to another eligible team member. For a business sale or acquisition, however, Stripe instructs the existing owner to contact Support first so Stripe can confirm which representative, owner, URL, bank, statement descriptor, receipt, legal-name, and tax-ID details must change. That means a buyer should not treat a password, email address, or team invitation as proof that the account handover is complete. The [Stripe account transfer guidance for a sale or acquisition](https://support.stripe.com/questions/transfer-a-stripe-account-to-a-different-entity-due-to-a-business-sale-or-acquisition?locale=en-GB) is the authoritative starting point. Stripe also publishes the separate [Dashboard ownership-transfer procedure](https://support.stripe.com/questions/change-the-owner-of-a-stripe-account?locale=en-GB). If Stripe confirms that the existing account can remain with the acquired business, no cross-account subscription recreation is taking place. Operationally, the existing Customers, Subscriptions, invoices, and IDs remain in that account. The team should still rotate credentials, remove seller access at the agreed time, update payout and public business details, and verify every downstream integration. Use the detailed [legal-entity-change path](/solutions/legal-entity-change/) when the entity details change even though the commercial team would prefer to keep the account. ## Why an Asset Sale Often Creates a Separate-Account Workstream An asset transaction commonly leaves the seller's entity, account history, and excluded products behind. When the buyer needs billing in a different Stripe account, the handover becomes three related projects: 1. **Customer and payment data:** Stripe can copy eligible Customer records and supported saved payment methods between accounts. 2. **Catalog and subscriptions:** The destination needs its own Products, Prices, Coupons, tax configuration, and newly created subscription objects. 3. **Application control:** The buyer's application must adopt destination credentials, object mappings, webhook signing secrets, portal configuration, and entitlement rules. Stripe's [account-copy documentation](https://support.stripe.com/questions/data-that-can-be-copied-between-stripe-accounts?locale=en-GB) says that subscriptions, invoices, plans, coupons, events, and logs do not copy. It also lists supported and excluded payment-data types. The original data remains in the old account, so appropriate legacy access and responsibility for refunds, disputes, and historical records must be agreed. For subscription recreation, Stripe's [Billing migration toolkit](https://docs.stripe.com/billing/subscriptions/import-subscriptions-toolkit) supports migrations from an existing Stripe account. It validates a CSV and creates destination Subscription Schedules. This is a real native migration path, but it does not decide the deal scope, complete source deactivation, deploy the buyer's application, or sign off reconciliation. Compare the operational scope on [Stripe Billing Migration Toolkit vs MoveMRR](/compare/stripe-billing-migration-toolkit/) before selecting the execution path. ## Five Questions That Decide the Stripe Handover ### 1. Does the Stripe account belong entirely to the sold business? If the source account also bills a retained product, another legal entity, or customers outside the transaction perimeter, handing over the entire account can transfer more than the buyer purchased. Define the in-scope subscription population from a dated source snapshot. The [account separation and consolidation guide](/solutions/account-separation-and-consolidation/) covers this carve-out pattern. ### 2. Will the legal entity or country change? Ask Stripe before the closing plan assumes an account path. Stripe says an acquisition by an entity in another country follows a different process. A cross-border migration may also expose payment-method, tax, currency, and account-availability differences that need individual review. Use the [cross-border Stripe migration guide](/solutions/cross-border-stripe-migration/) to build that review into diligence. ### 3. Which historical obligations stay with each party? The commercial agreement should allocate responsibility for at least: - pre-close invoices and credits; - refunds and disputes raised after close for pre-close payments; - negative balances, reserves, and payout timing; - tax records and invoice access; - customer support for old statement descriptors; - retention of source-account records. These are deal decisions, not settings a migration tool can infer. The parties should obtain legal, tax, and accounting advice for the allocation. ### 4. Can the buyer deploy the application handover? A destination account introduces account-specific credentials and new subscription IDs. Catalog IDs, webhook endpoints, signing secrets, Customer Portal configuration, scheduled jobs, analytics, and local entitlement records may also change. The billing move is incomplete until the application resolves the destination objects. Include the [application handover guide](/knowledge/application-handover-after-stripe-migration/) in technical diligence. ### 5. Which customers require an exception path? Eligible payment data can often be copied in the background, but passive customer handling is not universal. Unsupported payment methods, missing defaults, issuer declines, or authentication requirements can require customer follow-up. Review relevant configurations such as [past-due subscriptions](/compatibility/past-due-subscriptions/), [metered billing](/compatibility/metered-billing/), and [subscription schedules](/compatibility/subscription-schedules/) before close. ## What to Put in the Transaction Handover Schedule The purchase agreement and closing plan should turn the account decision into named deliverables. The exact legal wording belongs with counsel, but the operating schedule should answer these questions: | Control | What the schedule should specify | |---|---| | Account path | Existing-account transfer or separate-account migration, subject to Stripe confirmation | | Scope | Included Customer and Subscription population, timestamp, filters, and exclusions | | Preconditions | Stripe Support confirmation, destination readiness, customer/payment-data preparation, and catalog mappings | | Authority | Who can approve the live run, source deactivation, and exception treatment | | Billing boundary | Which account owns each renewal window and when source collection stops | | Evidence | Required counts, field-level reconciliation, ID maps, logs, and sign-offs | | Application handover | Credentials, webhooks, portal links, IDs, entitlements, and deployment owner | | Exceptions | Owner, customer-contact rule, deadline, and financial treatment for every unresolved item | | Legacy access | Who retains source-account access, for how long, and for which obligations | | Abort criteria | Conditions that stop the cutover before an irreversible source action | This schedule separates a commercial promise to transfer “the Stripe account” from the precise objects, permissions, and responsibilities that must actually change. ## Existing-Account Handover Checklist Use this path only after Stripe confirms it: 1. Record Stripe Support's account-path confirmation. 2. Invite the buyer's named administrators using individual accounts. 3. Require strong authentication and review assigned roles. 4. Transfer Dashboard ownership through Stripe's documented process. 5. Update the representative, legal, payout, statement, receipt, support, and public business details Stripe identifies. 6. Export team and security history for the closing evidence pack. 7. Replace or rotate API keys and webhook secrets through the buyer's secret-management process. 8. Remove seller access only when contractual and operational obligations allow it. 9. Verify payouts, live requests, webhooks, receipts, tax settings, and customer-facing descriptors. Stripe's [team-access documentation](https://docs.stripe.com/get-started/account/orgs/team) explains account-level roles, authentication controls, and security-history exports. Stripe's [API-key guidance](https://docs.stripe.com/keys-best-practices) covers least-privilege access, secure storage, and rotation. ## Separate-Account Migration Checklist 1. Confirm the destination account and country path with Stripe. 2. Lock a dated list of in-scope customers and subscriptions. 3. Complete and reconcile the approved customer/payment-data copy. 4. Map destination Products, Prices, Coupons, tax settings, and subscription behavior. 5. Rehearse representative cases in a Stripe sandbox. 6. Run a no-write readiness assessment against the final source snapshot. 7. Create or schedule destination subscriptions on the agreed billing boundary. 8. Verify destination configuration before the source can no longer be recovered. 9. Complete the agreed source-deactivation action before overlapping collection. 10. Deploy destination credentials, IDs, webhooks, portal configuration, and entitlement logic. 11. Reconcile exceptions and observe the first renewal cohorts. Start with the browser-only [Stripe migration readiness assessment](/tools/stripe-migration-readiness/), then use the [SaaS acquisition solution path](/solutions/saas-acquisitions/) for the complete buyer/seller workflow. ## Four Assumptions to Reject During Diligence ### “The buyer can just take the seller's Stripe password.” No. Use named team access and Stripe's ownership process. Shared credentials weaken security and do not resolve entity, bank, tax, or representative changes. ### “Customer Data Copy transfers the subscriptions.” No. Stripe explicitly excludes Subscription objects. A separate-account path needs destination subscription recreation. ### “A successful import means the handover is finished.” No. Source collection, application IDs, webhooks, secrets, entitlements, exceptions, and historical responsibilities remain. ### “No customer will ever need to do anything.” That cannot be promised. Eligible data can be copied, but future authentication, unsupported payment methods, missing defaults, and issuer decisions can still require customer action. ## A Defensible Decision Record Before signing off the Stripe handover, keep a short decision record with: - the transaction structure as described by counsel; - source and proposed destination account IDs; - legal entity and country for each account; - Stripe Support's account-path response; - included and excluded businesses or subscription cohorts; - reason the chosen path fits the deal boundary; - known customer/payment, billing, tax, and application exceptions; - named owner for each pre-close and post-close obligation; - final approval from buyer, seller, engineering, and finance. This record is more useful than a generic “Stripe transferred” line because it explains what stayed, what moved, and who accepted each residual risk. MoveMRR's [2026 migration benchmark](/research/state-of-stripe-account-migrations-2026/) shows the value of treating migration as a controlled handover rather than a single object-creation step. The published methodology and limits make clear what its aggregate evidence can and cannot establish. ## Frequently Asked Questions ### Does a share sale guarantee that the existing Stripe account can stay? No. It makes retaining the account a logical option to evaluate, but Stripe must confirm the required ownership, representative, legal-entity, and country changes. ### Does an asset sale always require a new Stripe account? No. The deal label alone is not decisive. Ask Stripe about the actual entities, countries, business scope, and account. Prepare a separate-account migration when the source account or legal boundary cannot move cleanly. ### Can the buyer receive all Stripe history in a new account? No. Stripe says its account-copy process does not copy invoices, charges, events, logs, subscriptions, plans, or coupons. The parties should preserve appropriate access to source records. ### Can a separate-account migration happen without customer action? Many eligible Customer and payment-method records can be copied in the background, but the outcome is case-specific. Unsupported methods, missing defaults, issuer declines, and SCA can create a remediation queue. ## Official Stripe Sources - [Transfer a Stripe account after a business sale or acquisition](https://support.stripe.com/questions/transfer-a-stripe-account-to-a-different-entity-due-to-a-business-sale-or-acquisition?locale=en-GB) - [Change the owner of a Stripe account](https://support.stripe.com/questions/change-the-owner-of-a-stripe-account?locale=en-GB) - [Data that can be copied between Stripe accounts](https://support.stripe.com/questions/data-that-can-be-copied-between-stripe-accounts?locale=en-GB) - [Migrate subscriptions with the Billing migration toolkit](https://docs.stripe.com/billing/subscriptions/import-subscriptions-toolkit) - [Manage organization and account access](https://docs.stripe.com/get-started/account/orgs/team) - [Stripe API-key best practices](https://docs.stripe.com/keys-best-practices) ## Next Step Use the [readiness assessment](/tools/stripe-migration-readiness/) to expose missing decisions, then turn the selected path into a timed [Stripe migration cutover runbook](/blog/stripe-migration-cutover-runbook/). --- # SaaS Valuation Multiples in 2026: Profit vs Revenue Canonical: https://movemrr.com/blog/saas-valuation-multiples/ > A source-backed guide to SaaS valuation multiples in 2026, including the latest Acquire.com transaction benchmark and a diligence-ready calculation framework. **Direct answer:** there is no credible universal SaaS revenue multiple for 2026. The most relevant public benchmark for smaller profitable SaaS acquisitions comes from Acquire.com's January 2026 report: SaaS businesses in its confirmed 2024 and 2025 transactions sold at a **median profit multiple of 3.9×**, with confirmed averages in the low-to-mid 4× range. Acquire.com says its observed market mostly covers businesses below $10 million in enterprise value and that exceptional high-growth companies may be valued on revenue instead. That is a market reference, not a price guarantee. The correct multiple depends on which earnings measure the parties use, the quality of the underlying revenue, growth, retention, concentration, owner dependence, and the deal structure. ## The Current 2026 Evidence The [Acquire.com Biannual Acquisition Multiples Report published in February 2026](https://blog.acquire.com/acquire-com-biannual-acquisition-multiples-report-jan-2026/) summarizes anonymized transactions completed on its marketplace during 2025 and compares them with 2024. It reports: | Reported measure | Acquire.com finding | Scope limitation | |---|---|---| | Median confirmed profit multiple | 3.9× in both 2024 and 2025 | Profitable SaaS transactions on Acquire.com | | Average confirmed profit multiple | Low-to-mid 4× range | Outcomes vary materially by company | | Typical market segment | Mostly enterprise values below $10 million | Not a benchmark for every public or venture-scale SaaS company | | Average time on market | 81 days | Marketplace transactions in the reporting period | | Average profit margin among published SaaS listings | 71% in 2025 | Listings, not necessarily completed deals | The report explicitly focuses on **profit multiples**, not ARR multiples. It says most profitable SaaS businesses are evaluated on profit, while high-growth companies that reinvest heavily may be valued on revenue. That distinction matters: applying a public-company revenue multiple to a small founder-operated SaaS can produce a misleading result. Acquire.com is a marketplace and has an interest in SaaS transactions. Its report is useful first-party marketplace data, but it is not the entire M&A market. Use it alongside actual offers, adviser input, and comparable transactions that match the company's size and economics. ## What a SaaS Valuation Multiple Measures A multiple expresses an agreed company value relative to one financial measure: - **Profit multiple** = enterprise value ÷ normalized annual profit - **ARR multiple** = enterprise value ÷ annual recurring revenue - **Revenue multiple** = enterprise value ÷ trailing or forward annual revenue The numerator and denominator must be defined before comparing offers. A headline “4×” is meaningless unless both sides know whether it means seller's discretionary earnings, EBITDA, recurring revenue, total revenue, or a forward estimate. ### Profit multiple A profit multiple is often useful for a smaller, profitable SaaS because it links the price to cash generation. The parties still need to agree on normalization: - Which founder compensation is added back? - Are one-time legal, migration, or development costs excluded? - Are hosting, support, and contractor costs complete? - Does the buyer need to replace the founder with paid staff? - Is the profit measured over the last twelve months or another period? Aggressive add-backs make the denominator look larger and the multiple look lower. Buyers normally rebuild the calculation from bank, accounting, billing, and payroll records. ### ARR or revenue multiple Revenue-based valuation may be more relevant when growth is strong and current profit is intentionally suppressed by reinvestment. ARR should include recurring contract value that exists at the measurement date and exclude one-time services, implementation fees, refunds, taxes, and test data. Revenue alone does not show how much it costs to retain and support customers. Two businesses with identical ARR can have very different value if one has stronger retention, margins, documentation, and transferability. ## A Diligence-Ready Calculation Start with three separate numbers instead of forcing one headline multiple: 1. **Verified recurring revenue.** Reconcile the subscription ledger to invoices, successful payments, credits, refunds, and current subscription states. 2. **Normalized annual profit.** Start with accounting profit and document each proposed add-back with evidence. 3. **Enterprise value and seller proceeds.** Separate the value of operations from cash, debt, working capital, escrow, holdbacks, earnouts, and transaction fees. For example, if an agreed enterprise value is €1.2 million and normalized annual profit is €300,000, the indicated profit multiple is 4.0×. That arithmetic is exact; whether €1.2 million is a fair price is a separate negotiation. Keep a calculation sheet that names: - the measurement date; - the accounting period; - the source system for every input; - currency conversions; - excluded revenue and expenses; - add-backs and their evidence; - debt, cash, and working-capital treatment; - contingent consideration. This makes the valuation reproducible and reduces disputes when diligence updates the figures. ## Factors Buyers Test Before Applying a Multiple The latest Acquire.com report associates stronger buyer interest with profitability and realistic asking prices. At company level, buyers usually test whether the reported economics are durable and transferable. ### Revenue quality and retention Separate new sales, expansion, contraction, churn, failed payments, refunds, and one-time revenue. Show the same cohort definitions across every period. If the application database, accounting records, and Stripe disagree, explain and reconcile the difference rather than selecting the highest number. ### Growth and profitability Document monthly revenue and profit using a consistent method. A buyer needs to see whether growth is repeatable, purchased with uneconomic acquisition spend, or driven by one unusual cohort. ### Customer concentration Calculate the percentage of recurring revenue represented by the largest customers and list contract renewal or termination terms. Concentration is not automatically disqualifying, but it makes the durability of those relationships more important. ### Founder dependence Identify every process that still requires the seller: deployment, support escalation, sales, partner access, billing exceptions, and security credentials. A transition plan is more credible when it assigns an owner, evidence, and completion date to each dependency. ### Technical and operational transferability Document source code, infrastructure, domains, data processors, support systems, analytics, intellectual property, incident history, and third-party contracts. A buyer is acquiring an operating system, not only a revenue chart. ### Billing handover For a Stripe-based SaaS, the parties must choose between transferring ownership of the existing account and migrating billing into another account. Stripe's official guidance says an account ownership change can fit some transactions, while a legal-entity or country change should be confirmed with Stripe Support. If a separate-account migration is required, Stripe can copy eligible customer and payment-method data, but it does not copy Subscription objects. The practical consequence is that the deal plan must include subscription recreation, destination ID mapping, source deactivation, application credentials, webhooks, entitlements, reconciliation, and exception handling. Read the [account ownership versus subscription migration decision guide](/knowledge/account-ownership-vs-subscription-migration/) before treating migration as the default. ## What Belongs in the Seller's Data Room A valuation becomes more defensible when another person can reproduce its inputs. Prepare: - monthly P&L and balance sheet; - bank and payment-processor reconciliation; - subscription-state export and recurring-revenue bridge; - retention and churn cohorts with written definitions; - customer concentration and contract schedule; - refunds, disputes, failed payments, and credits; - cloud, software, support, and contractor costs; - founder add-backs and replacement-cost assumptions; - product and infrastructure documentation; - security, privacy, tax, and compliance records; - asset list and account-ownership schedule; - billing handover and post-close operating plan. Do not present a Stripe dashboard screenshot as the entire revenue proof. The buyer needs to understand timing, failed collections, discounts, tax, one-time items, and how the billing ledger maps to the product's entitlement system. ## Asset Sale vs Share Sale The transaction structure affects the operational handover but does not by itself determine the valuation multiple. In a share sale, the legal entity may continue while its ownership changes. In an asset sale, selected assets and contracts move to a different owner or entity. Stripe account eligibility, customer contracts, tax, liabilities, and payment credentials still need transaction-specific review. Use the [asset-sale versus share-sale Stripe handover guide](/blog/saas-asset-sale-vs-share-sale-stripe-handover/) to frame the operational questions, then get legal and tax advice for the actual transaction. ## A Practical Seller Workflow 1. Define the valuation measure and period. 2. Reconcile billing, accounting, and product records. 3. Separate recurring from non-recurring revenue. 4. Document normalization adjustments. 5. Build retention and concentration schedules. 6. Inventory founder and third-party dependencies. 7. Decide the Stripe account path with Stripe and advisers. 8. Prepare a dated cutover and application-handover plan. 9. Obtain market feedback from more than one qualified buyer. 10. Compare cash at close, contingencies, liabilities, and transition duties—not only the headline multiple. For the billing workstream, use the [SaaS acquisition billing handover checklist](/blog/saas-acquisition-checklist-billing-handover/) and the [Stripe migration cutover runbook](/blog/stripe-migration-cutover-runbook/). ## Limits of This Guide This article is educational information, not a valuation, legal opinion, tax opinion, or investment recommendation. Marketplace averages cannot determine the value of an individual company. Deal terms, jurisdiction, accounting policy, risk, buyer strategy, and current market conditions can materially change the outcome. ## Sources - [Acquire.com Biannual Acquisition Multiples Report, January 2026 edition](https://blog.acquire.com/acquire-com-biannual-acquisition-multiples-report-jan-2026/) - [Stripe: transfer an account after a business sale or acquisition](https://support.stripe.com/questions/transfer-a-stripe-account-to-a-different-entity-due-to-a-business-sale-or-acquisition?locale=en-GB) - [Stripe: data that can be copied between accounts](https://support.stripe.com/questions/data-that-can-be-copied-between-stripe-accounts?locale=en-GB) - [Stripe Billing migration toolkit](https://docs.stripe.com/billing/subscriptions/import-subscriptions-toolkit) The valuation number and the handover plan answer different questions. A strong process makes both explicit: what the buyer is paying for, how the financial evidence was produced, and how the recurring-revenue system will keep operating after close. --- # Stripe Subscription Migration Cutover Runbook Canonical: https://movemrr.com/blog/stripe-migration-cutover-runbook/ > A time-boxed T-30 to T+30 runbook for safely coordinating destination subscriptions, source deactivation, application handover, and reconciliation. **Direct answer:** A Stripe subscription migration cutover should run like a controlled production release. Freeze the in-scope billing state, create or schedule destination subscriptions, verify their configuration, stop source collection before an overlapping charge, deploy the buyer's account-specific application configuration, reconcile every row, and monitor renewal cohorts. Every irreversible action needs a named owner, evidence, and a stop condition. This runbook uses **T0** for the agreed moment when the destination becomes the operational billing system. Adjust the calendar to the actual renewal distribution and Stripe workflow. Do not force a migration into a date that leaves no time for Stripe review, data preparation, validation, or customer remediation. ## What This Runbook Covers The runbook coordinates four systems that must agree: 1. **Source Stripe account:** the existing subscription population, invoices, and deactivation actions. 2. **Destination Stripe account:** copied Customers, mapped catalog objects, and recreated subscriptions. 3. **SaaS application:** API credentials, Stripe IDs, webhooks, portal links, and entitlements. 4. **Operating team:** buyer, seller, engineering, finance, support, and the person authorised to stop the run. It does not decide whether a migration is legally required. First choose between account retention and cross-account recreation using the [SaaS asset-sale vs share-sale decision guide](/blog/saas-asset-sale-vs-share-sale-stripe-handover/). ## Name the Cutover Roles Assign people, not departments: | Role | Decision authority | |---|---| | Cutover lead | Owns the clock, opens gates, pauses the run, and records decisions | | Seller billing owner | Confirms source scope, freeze, invoices, and source deactivation | | Buyer billing owner | Confirms destination account, settings, mappings, and subscription state | | Application owner | Deploys credentials, object mappings, webhooks, portal, and entitlements | | Reconciliation owner | Compares source snapshot, destination results, and financial totals | | Customer-remediation owner | Handles missing payment methods, authentication, and support cases | | Transaction approver | Accepts residual exceptions under the signed handover terms | No one should approve their own high-risk output without an independent verifier. For smaller teams, one person can hold multiple roles, but the evidence and second-person review should remain. ## Create the Evidence Pack Before T−30 Use one controlled location for: - source and destination Stripe account IDs; - Stripe Support confirmation of the account and customer-data path; - in-scope query or export definition; - source snapshot hash, time, and row count; - Customer and payment-data copy result; - Product, Price, Coupon, tax, and subscription mapping tables; - dry-run and sandbox results; - subscription old-to-new ID map; - source-deactivation result; - application deployment and webhook test evidence; - exception register with owner and deadline; - buyer/seller go/no-go decisions; - first-renewal reconciliation. Do not put Stripe secret or restricted API keys, webhook signing secrets, raw payment details, or customer-sensitive exports into a general deal folder. Stripe's [API-key best practices](https://docs.stripe.com/keys-best-practices) recommend least privilege, secure storage, access restrictions, and rotation. ## T−30 to T−14: Decide the Path and Remove Unknowns ### Account and data gates - Confirm with Stripe whether the existing account can remain with the business. - If a destination account is required, confirm its legal entity, country, payout details, tax settings, statement descriptor, receipts, and team access. - Ask Stripe which Customer and payment-method data can be copied. - Define the exact subscription population included in the transaction. - Separate excluded products, test data, canceled records, and subscriptions owned by a retained business. Stripe says its account-copy process can copy eligible Customer and supported payment data, but not subscriptions, invoices, plans, coupons, events, or logs. Review the live [data-copy matrix](https://support.stripe.com/questions/data-that-can-be-copied-between-stripe-accounts?locale=en-GB) rather than assuming every payment method will arrive. ### Billing-model inventory Count and classify: - monthly, annual, and mixed intervals; - multiple subscription items and quantities; - trials and future schedules; - automatic collection and send-invoice subscriptions; - discounts and promotion behavior; - automatic tax and fixed tax rates; - metered or usage-based items; - paused, past-due, unpaid, and cancel-at-period-end states; - custom billing anchors, prorations, credits, and pending invoice items. Use the compatibility guides for [billing-cycle anchors](/compatibility/billing-cycle-anchors/), [multi-item subscriptions](/compatibility/multi-item-subscriptions/), [Stripe Tax](/compatibility/stripe-tax/), and [metered billing](/compatibility/metered-billing/) to assign a treatment to each cohort. ### Application inventory Find every account-specific dependency: - server and publishable API keys; - Customer, Subscription, Product, Price, Coupon, and Tax IDs; - webhook endpoint configuration and signing secrets; - Customer Portal configuration; - scheduled jobs and background reconciliation; - database entitlements and subscription status rules; - support, analytics, warehouse, tax, and accounting integrations. **T−14 gate:** Stop if the account path is unconfirmed, the population cannot be reproduced, or a material billing cohort has no destination treatment. ## T−14 to T−7: Rehearse the Exact Work Run a representative sandbox migration that includes ordinary and difficult cohorts. Stripe's [API migration guide](https://docs.stripe.com/billing/subscriptions/import-subscriptions) recommends testing the pricing-model import in a sandbox and notes that sandbox and live-mode IDs must be mapped separately. The rehearsal must prove: 1. destination Customers resolve and automatic-collection cases have a usable default; 2. destination Price, Coupon, and Tax IDs belong to the destination account; 3. billing amounts, currencies, intervals, quantities, trials, and next charge dates match the approved treatment; 4. application code resolves the resulting destination IDs; 5. destination webhook signatures verify; 6. duplicate and out-of-order events do not corrupt entitlements; 7. source-deactivation behavior is understood before it is used live; 8. every unsupported case enters a visible remediation queue. Stripe does not guarantee webhook event order. Its [webhook documentation](https://docs.stripe.com/webhooks) instructs integrations to verify signatures and retrieve missing objects when necessary. Do not use receipt of one event as the only proof that a migrated subscription is correct. **T−7 gate:** Stop if the rehearsal cannot be reproduced, webhook verification fails, or the team cannot reconcile expected and actual results at field level. ## T−7 to T−3: Lock the Run of Show Publish a minute-by-minute run sheet with: - migration batch order; - exact subscription filters; - operator and independent verifier for each action; - destination start or go-live time; - source billing boundary; - application deployment window; - customer-change freeze start and end; - support coverage; - stop conditions; - escalation contacts; - the latest reversible point. Group subscriptions by operational risk, not arbitrary row count. A sensible batch structure might separate simple monthly automatic collection, annual subscriptions, trials, send-invoice customers, complex schedules, and owned exceptions. If the operation uses Stripe's Billing migration toolkit, review the current [toolkit specification](https://docs.stripe.com/billing/subscriptions/import-subscriptions-toolkit). Stripe currently requires production `start_date` values at least 24 hours in the future, validates the upload, creates Subscription Schedules, holds them in a scheduled state for 24 hours, and displays a 10-hour toolkit cancellation window. Record the actual cancellation deadline shown in the Dashboard. **T−3 gate:** Stop if the selected date conflicts with upcoming source renewals, the toolkit timing, a deployment freeze, or support availability. ## T−72 Hours to T−24 Hours: Take the Final Snapshot 1. Announce the subscription-change freeze to the operating team. 2. Disable or tightly control upgrades, downgrades, cancellations, trial changes, coupon changes, and admin edits for the in-scope population. 3. Capture the final source export and its exact timestamp. 4. Re-run the scope definition and compare it with the prior rehearsal input. 5. Reconcile destination Customers and payment-method readiness. 6. Rebuild live destination mappings; never reuse sandbox IDs. 7. Run the final no-write readiness check. 8. Upload or prepare the approved migration batches. 9. Record validation errors without editing the source snapshot in place. 10. Resolve errors through a versioned correction file and repeat validation. For an initial readiness pass, use the browser-only [Stripe migration readiness assessment](/tools/stripe-migration-readiness/). It does not upload Stripe credentials or replace field-level reconciliation. ### Snapshot-change rule Any in-scope source change after the snapshot must have one of three outcomes: - reverse the change before T0; - add it to the migration input and repeat affected checks; or - record it as an owned post-cutover exception. Silent drift is not an acceptable fourth option. ## T−24 Hours to T−1 Hour: Verify the Scheduled State For every batch, compare the destination output with the approved source treatment: | Field group | Required comparison | |---|---| | Identity | Source Customer and Subscription IDs mapped to actual destination objects | | Commercial terms | Currency, recurring amount, interval, quantity, and items | | Timing | Destination start, next expected invoice, trial end, and cancellation state | | Collection | Automatic collection or send invoice, days due, and default readiness | | Adjustments | Coupon, tax treatment, pending items, credits, and proration decision | | Application | Local tenant, entitlement, portal, and webhook mapping | | Control | Batch ID, operator, verifier, timestamp, and exception status | Counts are necessary but insufficient. Equal source and destination counts can hide a wrong annual price, shifted billing date, missing second item, or mismatched tax behavior. ### Inspect the source invoice boundary Before source deactivation, inspect open and draft invoices, pending invoice items, metered usage, scheduled cancellations, and renewals around T0. Stripe's [subscription cancellation documentation](https://docs.stripe.com/billing/subscriptions/cancel) explains that cancellation timing can affect invoices, pending items, usage, prorations, and collection. Choose the action per cohort; do not apply one cancellation assumption to every subscription. **T−1 gate:** Stop if any account-wide mismatch exists, any high-value exception lacks approval, or the source and destination could collect for the same service period without an owned resolution. ## T0: Execute the Cutover The cutover lead reads each control aloud and records its evidence: 1. Confirm the source-change freeze is still effective. 2. Confirm the migration input matches the final approved snapshot. 3. Confirm destination schedules or subscriptions exist with the agreed start state. 4. Retrieve a representative sample directly from the destination account. 5. Confirm the application release is ready with destination credentials and object mappings. 6. Confirm destination webhook signature verification and event handling. 7. Confirm the Customer Portal and payment-update paths point to the destination account. 8. Complete the approved source-deactivation action before a source charge can overlap the destination billing boundary. 9. Re-query both accounts and compare the final source and destination state. 10. Release the application deployment and subscription-change freeze only after the verifier signs off. Stripe advises creating the destination subscriptions before canceling the old subscriptions, while canceling the old subscriptions before the new subscriptions are set to charge. For a billing date close to migration, Stripe recommends scheduling the destination after that cycle so the old system produces the final bill. That guidance appears in the [Billing migration toolkit documentation](https://docs.stripe.com/billing/subscriptions/import-subscriptions-toolkit). The exact order of application deployment and source action depends on the architecture. The invariant is that the product must resolve the intended destination account when destination billing becomes authoritative. ## The Go/No-Go Board | Gate | Go evidence | No-go condition | |---|---|---| | Account | Destination account ID and Stripe path confirmed | Entity, country, or ownership path unresolved | | Scope | Reproducible snapshot and approved exclusions | Population changed without reconciliation | | Customer data | Eligible copy reconciled; exceptions assigned | Unknown or unusable defaults in an unowned cohort | | Catalog | Every required destination mapping verified | Source IDs used where destination IDs are required | | Billing | Amounts, timing, tax, trials, collection, and cancellation match | Material field mismatch | | Application | Keys, IDs, webhooks, portal, and entitlements tested | Application still depends on source-only configuration | | Source boundary | Action and time approved per cohort | Both accounts can collect the same period | | Recovery | Latest reversible point and remediation owners recorded | Team calls an irreversible action “easy to roll back” | Only the cutover lead changes the board. A deadline, senior stakeholder, or sunk migration effort does not convert a no-go condition into a go. ## Understand the Rollback Boundary “Rollback” means different things at different points: | State | Available response | |---|---| | Before destination creation | Correct input and repeat readiness checks | | Destination schedules created, source untouched | Cancel or correct destination schedules within the applicable Stripe path and verify the result | | Toolkit migration within its displayed cancellation window | Use the documented toolkit cancellation path, then confirm no destination schedule can activate | | Toolkit window elapsed, schedules not live | Follow Stripe's documented API or individual cancellation path and verify every schedule | | Destination live, source still recoverable | Pause the run and choose the safer billing system before any overlapping charge | | Source subscription canceled | Treat recovery as remediation, not a simple rollback | Stripe states that a canceled subscription cannot be reactivated. A new subscription must be created if service should resume. Never cancel the source population merely to make a dashboard count look complete. If an internal API workflow creates objects, use stable per-row idempotency keys and persist the resulting Stripe IDs. Stripe's [idempotent-request documentation](https://docs.stripe.com/api/idempotent_requests) explains how identical retries avoid duplicate side effects. Idempotency does not verify that the original parameters were commercially correct; reconciliation still does that. ## T+1 Hour to T+24 Hours: Stabilise Monitor and record: - unexpected source invoices or collection attempts; - destination schedule activation and subscription status; - `invoice.paid`, `invoice.payment_failed`, and `invoice.payment_action_required`; - webhook signature failures, retries, duplicates, and processing latency; - entitlement changes and account-access complaints; - portal or payment-update requests hitting the wrong account; - discrepancies in subscription count and recurring-value totals; - new exceptions from missing defaults, declines, or authentication. Stripe's [subscription webhook guide](https://docs.stripe.com/billing/subscriptions/webhooks) documents payment-failure and authentication-required events. These cases are why “no customer action” must remain an observed outcome, not a blanket promise. Keep support messaging factual. Tell an affected customer what needs attention without describing the entire population as impacted. ## T+2 Days to T+7 Days: Reconcile Renewal Cohorts Reconcile by expected renewal window: 1. list destination invoices expected in the window; 2. compare paid, open, failed, action-required, and uncollectible outcomes; 3. search the source account for any invoice covering the same service period; 4. compare entitlement state with the paid and subscription state; 5. assign every mismatch to an owner; 6. record customer contact only where a real case requires it; 7. update the signed exception register. An `active` subscription alone is not proof that every invoice is paid. Stripe's [subscription lifecycle documentation](https://docs.stripe.com/billing/subscriptions/overview) explains how subscription, invoice, and PaymentIntent states interact. ## T+8 Days to T+30 Days: Close the Handover Close the project only when: - all in-scope rows are migrated or have an accepted exception; - the old-to-new ID map is stored with the buyer's operating records; - source deactivation and residual invoices reconcile; - first-renewal cohorts match the expected destination behavior; - customer-remediation cases have an owner and outcome; - seller access and migration credentials follow the agreed rotation schedule; - support, finance, and engineering accept the operational handover; - legacy source access meets the transaction's record-retention plan. Use the transparent [State of Stripe Account Migrations 2026 research](/research/state-of-stripe-account-migrations-2026/) as a benchmark reference, not as a substitute for your own reconciliation. Its methodology states the size and limits of the observed MoveMRR customer set. ## Frequently Asked Questions ### When should source subscriptions be canceled? At the approved billing boundary, after destination objects are verified and before both systems can collect for the same service period. Immediate, period-end, and custom cancellation can have different invoice, usage, and proration effects, so choose per cohort. ### Is the Stripe toolkit's 24-hour scheduled state a rollback window? It creates review time, but the Dashboard toolkit's documented cancellation window is currently 10 hours. Record the deadline shown for the actual migration and independently verify any cancellation. ### Does a matching subscription count prove success? No. Reconcile amount, currency, items, quantity, next billing date, trial, collection method, discount, tax, state, payment readiness, and application mapping. ### Can every customer remain passive? No universal promise is supportable. Eligible data may copy successfully, but missing defaults, unsupported methods, future issuer declines, or authentication can still require action. ### What should happen if the run misses T0? Keep the last verified billing system authoritative, prevent overlapping collection, record the new snapshot, and reschedule with the affected checks repeated. Do not compress an expired control window into an unreviewed live action. ## Official Stripe Sources - [Billing migration toolkit](https://docs.stripe.com/billing/subscriptions/import-subscriptions-toolkit) - [Migrate subscriptions using Stripe APIs](https://docs.stripe.com/billing/subscriptions/import-subscriptions) - [Data that can be copied between Stripe accounts](https://support.stripe.com/questions/data-that-can-be-copied-between-stripe-accounts?locale=en-GB) - [Cancel subscriptions](https://docs.stripe.com/billing/subscriptions/cancel) - [Receive and verify webhook events](https://docs.stripe.com/webhooks) - [Using webhooks with subscriptions](https://docs.stripe.com/billing/subscriptions/webhooks) - [How subscriptions work](https://docs.stripe.com/billing/subscriptions/overview) - [Idempotent requests](https://docs.stripe.com/api/idempotent_requests) - [Stripe API-key best practices](https://docs.stripe.com/keys-best-practices) ## Next Step Run the [readiness assessment](/tools/stripe-migration-readiness/), review the [Stripe toolkit comparison](/compare/stripe-billing-migration-toolkit/), and use the [SaaS acquisition workflow](/solutions/saas-acquisitions/) to turn the runbook into a buyer/seller migration project. --- # Can You Transfer Stripe Subscriptions? No — Here's How Canonical: https://movemrr.com/blog/transfer-stripe-subscriptions-between-accounts/ > No — a sub_ ID can't move between Stripe accounts. But you can copy customers and recreate subscriptions. Your 3 options in a SaaS sale, compared. **The short answer:** You cannot move an existing Stripe Subscription object, with its original `sub_…` ID, into another standalone Stripe account. You can copy eligible customer/payment data and recreate the subscription configuration in the destination. Stripe now offers an official Billing migration toolkit for that import, and MoveMRR offers a broader buyer/seller handover workflow. That distinction matters. "Transfer" is convenient language, but the technical operation creates a new destination subscription and then handles the source subscription according to an agreed cutover plan. ## Three Ways to Handle a SaaS Sale | Option | What happens | Best when | |---|---|---| | Transfer ownership of the existing Stripe account | Account remains; control changes | Stripe approves the entity/country path and the complete account belongs with the business | | Stripe Billing migration toolkit | Operator maps a CSV and Stripe creates destination Subscription Schedules | Destination data is ready and one team owns source cancellation and application updates | | MoveMRR | Buyer and seller use a migration project for mappings, rehearsal, recreation, source deactivation, and reconciliation | The transaction needs a shared, auditable handover | Start with the [ownership-vs-migration decision](/knowledge/account-ownership-vs-subscription-migration/), not with a tool. ## What Customer Data Copy Does Stripe can copy eligible Customer records and supported saved payment methods between accounts. Stripe's current documentation lists cards, ACH, and SEPA PaymentMethod objects among supported types. It does not copy: - Subscription objects; - invoices and charge history; - plans and catalog configuration; - coupons; - events and logs. Stripe currently says copied Customer IDs remain the same while payment-method IDs change. Destination subscriptions still receive new IDs. See the full [Customer Data Copy matrix](/knowledge/stripe-customer-data-copy/) and Stripe's primary [account-copy documentation](https://support.stripe.com/questions/data-that-can-be-copied-between-stripe-accounts?locale=en-GB). ## What Stripe's Billing Migration Toolkit Adds Stripe's [Billing migration toolkit](https://docs.stripe.com/billing/subscriptions/import-subscriptions-toolkit) supports existing Stripe accounts as a source. It validates CSV templates and creates destination Subscription Schedules. The toolkit can represent common fields such as: - recurring Price and quantity; - multiple subscription items; - billing-cycle anchor; - trial end; - coupon and tax settings; - collection method; - cancellation state. It is a genuine native Stripe migration option. It does not, by itself, complete customer/payment data preparation, source-account deactivation, buyer/seller sign-off, application ID updates, or webhook-secret deployment. ## The Controlled Migration Sequence 1. Ask Stripe whether the existing account can transfer with the business. 2. If a separate destination is required, complete the approved customer/payment-data copy. 3. Reconcile destination Customers and valid default payment methods. 4. Prepare destination Products, Prices, Coupons, Taxes, and subscription rules. 5. Rehearse representative cases and run a dry run. 6. Create or schedule destination subscriptions. 7. Verify amounts, billing dates, trials, collection methods, and status. 8. Stop source collection at the agreed billing boundary. 9. Deploy destination credentials, object mappings, webhooks, portal links, and entitlements. 10. Reconcile exceptions and monitor the first renewal cohorts. The [technical migration guide](/knowledge/stripe-subscription-migration-guide/) explains each workstream. ## Can Customers Stay Passive? Often, yes during the cutover. Stripe says eligible customer/payment data can be copied in the background without informing the customer. Do not turn that into an absolute guarantee: - unsupported methods do not copy; - a copied Customer can lack a usable default; - an issuer can decline an off-session charge; - SCA can require authentication; - a new statement descriptor can still create support questions. Classify those cases before launch with the [migration-without-customer-action guide](/knowledge/migration-without-customer-action/). ## How MoveMRR Differs MoveMRR focuses on the complete Stripe-to-Stripe handover: - purpose-specific restricted-key validation; - sandbox seeding and rehearsal; - customer and catalog mapping; - no-write dry runs; - configurable billing-cycle, trial, metadata, and source-deactivation behaviour; - idempotent run records; - per-item results, reconciliation, and downloadable ID maps; - optional supported webhook-endpoint recreation. MoveMRR does not receive raw card numbers, override Stripe eligibility, decide legal treatment, or guarantee that every future bank authorization succeeds. ## What Can Still Go Wrong? ### Overlapping Billing Both accounts can invoice the same period if the destination begins too early or the source remains collectible too long. Define the billing boundary and inspect both invoice queues. See [how to prevent double billing](/knowledge/prevent-double-billing/). ### Billing-Date Drift `start_date`, `billing_cycle_anchor`, `trial_end`, and proration interact. Reconcile the next expected invoice, not only one copied field. See [`billing_cycle_anchor` during migration](/knowledge/billing-anchors-explained/). ### Missing Application Cutover The buyer's code might still query the source account or expect the old Subscription ID. Deploy the ID map, destination API keys, webhook signing secrets, portal configuration, and entitlement rules. See the [application handover runbook](/knowledge/application-handover-after-stripe-migration/). ### Unsupported Payment Methods Bacs PaymentMethods and legacy SEPA Sources are among Stripe's documented exclusions for account copy. Keep a customer-remediation path ready. ## How Long Does It Take? There is no reliable universal duration. It depends on Stripe account review, the payment-method population, catalog complexity, subscription states, dry-run findings, application deployment, and the chosen observation window. Stripe notes that its toolkit can take minutes to hours to validate and migrate a file, depending on size, and uses a 24-hour scheduled production buffer. That is only the destination creation stage, not the complete SaaS handover. ## Pricing MoveMRR uses one-time EUR pricing based on declared active subscriptions and estimated monthly recurring revenue. The [pricing calculator](/#pricing) shows the current list amount for Minimum, Advanced, and Done-For-You; Done-For-You above 25,000 subscriptions uses a capacity inquiry. ## Frequently Asked Questions ### Does Stripe have a native subscription migration tool? Yes. Stripe's Billing migration toolkit supports imports from existing Stripe accounts. It recreates subscriptions in the destination; it does not move the existing Subscription objects or complete the surrounding source and application cutover. ### Do destination subscriptions keep the same IDs? No. New destination Subscription objects have new Stripe IDs. Export and apply an old-to-new ID map. ### Does Customer Data Copy include subscriptions? No. Stripe explicitly excludes subscriptions, invoices, plans, coupons, events, and logs from Customer Data Copy. ### Will customers need to enter their card again? Many eligible cards and supported bank methods can be copied. Some customers can still need action because of unsupported methods, missing defaults, declines, or SCA. ### Is account ownership transfer easier? It can be, if Stripe confirms the existing account can remain with the acquired business. A legal-entity or country change requires Stripe review. ## Next Step Compare [Stripe's toolkit and MoveMRR](/compare/stripe-billing-migration-toolkit/) — or, if you are weighing a full account handover against recreating subscriptions, the [account transfer vs migration comparison](/compare/move-account/). Then create a MoveMRR project if the transaction needs a controlled two-account handover. --- # What Happens to Stripe Subscriptions When You Sell? Canonical: https://movemrr.com/blog/what-happens-to-stripe-subscriptions-when-you-sell-your-saas/ > They don't transfer automatically — subscriptions stay in the seller's Stripe account until migrated. What buyers expect and the 3 handover options. **The short answer:** Your Stripe subscriptions don't automatically transfer to the buyer. The subscription objects, the billing relationships, the renewal schedules — all of it stays in your Stripe account unless you actively migrate it. Stripe can copy eligible customers and saved payment methods between accounts, but subscriptions must be recreated in the buyer's account, and the source must stop collecting before the destination starts. The rest of this article covers what that means in practice when you sell your SaaS. ## Why This Matters When the buyer takes over, they typically need the subscriptions in their own Stripe account for several reasons: **Legal and Tax**: The revenue needs to flow to the correct legal entity. Keeping subscriptions in the seller's account creates a liability. **Operational Control**: The buyer needs to manage the subscriptions — handle upgrades, downgrades, cancellations, and payment failures. **Clean Separation**: After the sale, the seller shouldn't retain access to customer payment information or billing. ## What Stripe Offers Stripe's documented **Customer Data Copy** process helps with part of the problem: - Eligible Customer objects and supported fields can be copied - Supported saved payment methods may be copied for an eligible account pair - A mapping CSV links old customer IDs to new ones But here's the critical gap: **subscriptions are not copied**. After a successful copy, eligible destination customers and payment methods still have no copied Subscription objects. Review Stripe's current [account-copy matrix](https://support.stripe.com/questions/data-that-can-be-copied-between-stripe-accounts?locale=en-GB) for the exact account pair and payment-method limits. ## The Subscription Migration Challenge Each destination subscription must be recreated or imported in the buyer's account. Stripe now provides a Billing migration toolkit for CSV-based imports, including Stripe-to-Stripe use cases. The operational work still involves: 1. Reading the original subscription details 2. Creating a new subscription with matching configuration 3. Setting the correct billing anchor (so renewal dates match) 4. Canceling the old subscription For a handful of simple subscriptions, careful manual recreation may be feasible. Larger or more varied populations need repeatable validation and reconciliation. ### Common Mistakes **Double Billing**: Creating the new subscription before properly canceling the old one can result in customers being charged twice. **Shifted Billing Dates**: Without setting the billing anchor correctly, customers may be charged on different dates than expected. **Proration Issues**: New subscriptions may generate prorated charges if not configured correctly. **Incomplete Migration**: Missing subscriptions or failing to cancel old ones leaves a mess. ## How Professional Sales Handle This In a professional SaaS sale, subscription migration is typically part of the transition plan: **Pre-Close**: Seller and buyer confirm the account path with Stripe, start any required Customer Data Copy early, and prepare destination settings and mappings. **At Close**: The destination subscriptions are created or scheduled and the agreed source deactivation is completed at the billing boundary. **Post-Close**: Both parties reconcile results, deploy the application handover, and monitor the first renewal cohorts. The more subscriptions involved, the more important it is to have a reliable, auditable process. ## What to Include in the Purchase Agreement Smart buyers and sellers include subscription migration in the deal terms: - Who is responsible for requesting Customer Data Copy - Timeline for migration execution - What happens if migration fails - Confirmation requirements before final payment ## Tools for Subscription Migration **Manual**: For very small subscription counts, careful manual recreation may be feasible. **Custom Scripts**: Technical founders sometimes write one-off scripts for their specific situation. **Stripe Billing migration toolkit**: Stripe's official Dashboard workflow validates a CSV and creates destination Subscription Schedules. **Third-party migration services**: Agencies and tools such as [Good Migrations](/compare/good-migrations/) or [Subporter](/compare/subporter/) handle parts of the recreation work — the comparisons cover what each execution model includes. **MoveMRR**: A shared buyer/seller workflow for mappings, rehearsal, configurable source deactivation, reconciliation, and ID exports. Subscription value also feeds directly into the purchase price — see [SaaS valuation multiples](/blog/saas-valuation-multiples/) for how buyers price recurring revenue. ## Timeline Considerations Stripe review and data-copy timing depends on the accounts and migration. Plan accordingly: - Don't wait until the day of close to confirm the account and data-copy path - Have API keys ready in advance - Test with a subset if possible ## After the Migration Once subscriptions are in the buyer's account: - The application must use destination credentials, object IDs, and webhook signing secrets - First billing cohorts should be monitored against the reconciliation - Customer support should be prepared for any questions - Source subscriptions should match the agreed deactivation strategy - Documentation should be archived ## Summary Selling your SaaS involves more than handing over code and credentials. Your Stripe subscriptions represent ongoing customer relationships and revenue, and transferring them correctly is critical to a successful handover. Plan ahead, use the right tools, and document everything. ## Primary sources - [Stripe: transfer an account after a business sale or acquisition](https://support.stripe.com/questions/transfer-a-stripe-account-to-a-different-entity-due-to-a-business-sale-or-acquisition?locale=en-GB) - [Stripe: data that can be copied between accounts](https://support.stripe.com/questions/data-that-can-be-copied-between-stripe-accounts?locale=en-GB) - [Stripe Billing migration toolkit](https://docs.stripe.com/billing/subscriptions/import-subscriptions-toolkit) - [Stripe subscription webhooks](https://docs.stripe.com/billing/subscriptions/webhooks) --- _Planning a handover? Compare [account ownership and subscription migration](/knowledge/account-ownership-vs-subscription-migration/), follow the [technical migration guide](/knowledge/stripe-subscription-migration-guide/), or review the [application handover runbook](/knowledge/application-handover-after-stripe-migration/)._ --- # Why Are SaaS Founders Moving Away from Stripe? (2026) Canonical: https://movemrr.com/blog/why-saas-founders-are-moving-away-from-stripe/ > Fees, tax liability, freezes, and support drive real Stripe exits — but many departures are account moves after acquisitions, not platform switches. **The short answer:** Founders who leave Stripe usually cite one of four reasons — processing costs at scale, the sales-tax and VAT burden of being your own merchant of record, fear of account freezes, and support quality. All four are real, and for some businesses switching to a merchant of record is the correct call. But a large share of "leaving Stripe" moments are something else entirely: the founder is leaving a specific Stripe **account** — after an acquisition, a legal-entity change, or a company relocation — while the business stays on Stripe. This post covers both: an honest look at when switching platforms makes sense, and the account-level moves that get mixed into the same conversation. ## What Are the Real Reasons Founders Leave Stripe? Most "why I left Stripe" content reduces to four complaints, plus one scenario that is routinely misfiled with them: | Reason | What actually hurts | Where founders typically go | |---|---|---| | Fees at scale | Blended cost of processing + Billing + Tax + cross-border surcharges | Negotiated Stripe pricing, or direct processors like Adyen/Braintree | | Sales tax and VAT | Registration, filing, and liability across dozens of jurisdictions | A merchant of record (Paddle, Lemon Squeezy, Polar, FastSpring) | | Account stability | Frozen payouts, rolling reserves, opaque reviews | A different PSP — though the risk category follows the business model | | Support | Templated responses until you reach negotiated-contract scale | Smaller vendors selling hands-on support | | An acquisition, entity change, or relocation | Subscriptions must move to a different account | Usually: another Stripe account | The first four are platform decisions. The last one is a migration problem, and it is the one almost nobody writes about. ## Are Stripe's Fees Actually the Problem? Sometimes — but less often than the complaint volume suggests. Stripe's standard US card pricing starts at 2.9% + 30¢, before surcharges for international cards and currency conversion. Stripe Billing adds a percentage of subscription volume, and Stripe Tax bills on top where you are registered. For a global SaaS on list pricing, the blended take can land well above the headline rate. Two things temper this as a reason to leave: 1. **At the volume where fees genuinely matter, you can negotiate.** Stripe offers custom and interchange-plus-style pricing for larger accounts. Founders who skip that conversation and migrate away are often solving a negotiation problem with an engineering project. 2. **The popular destinations are more expensive.** Merchants of record typically charge around 5% plus per-transaction fees — they bundle tax compliance into the rate. Founders who leave purely over fees end up at direct processors, which means taking on more integration and compliance work, not less. If you are doing $500k a year through Stripe, a one-point fee improvement is worth about $5,000 annually. Price the migration, the rebuild, and the new failure modes against that number before deciding. ## Is the Sales-Tax and VAT Burden the Real Driver? More often than fees, yes. This is the strongest honest case for leaving Stripe, and it is exactly the case the merchant-of-record vendors pitch. On Stripe, you are the merchant of record. Since *South Dakota v. Wayfair* (2018), US states enforce economic-nexus thresholds; the EU and a growing list of other countries expect VAT registration from foreign sellers of digital services, in some cases from the first sale. [Stripe Tax](https://docs.stripe.com/tax) calculates and collects correctly, and can support registration and filing — but the legal liability for registering, filing, and remitting stays with your entity. A merchant of record resells your product: the MoR is the seller on the invoice, and the tax obligations are theirs. For a small team selling low-touch software to consumers and prosumers worldwide, handing that problem to Paddle, Lemon Squeezy, Polar, or FastSpring is a rational trade — some founders genuinely should make it. The trade has costs worth naming: a materially higher blended rate, payout timing controlled by the MoR, less control over checkout and invoicing, a customer relationship that legally runs through the reseller, and a harder path back out, because your subscriptions and saved payment methods then live inside the MoR's stack. We wrote a dedicated breakdown of both directions in [merchant-of-record migration](/compare/merchant-of-record-migration/). ## Do Account Freezes Push Founders Off Stripe? This is the most viral category. First-person "Stripe froze our payouts" essays reliably reach the Hacker News front page, and each one convinces a cohort of founders to diversify away. The honest framing: freezes and reserves are rare in absolute terms, catastrophic when they hit, and the opacity of the review process is the legitimate core of the complaint. It is also not a Stripe-specific risk. Any provider that settles card payments — including every merchant of record — carries underwriting obligations and can hold funds when dispute rates spike or the business profile stops matching reality. Switching providers relocates the risk; it does not delete it. What actually reduces it: an accurate business profile and statement descriptor, keeping dispute rates low, and telling your provider before a large volume spike instead of after. If the risk is existential for you, a second processor is a hedge — but that is an argument for redundancy, not necessarily for leaving. ## What About Support? At small scale, Stripe support is largely templated and asynchronous, and complex billing edge cases can take multiple rounds to escalate. Larger accounts get named contacts and faster paths. Support quality is a real difference between Stripe and smaller vendors — but in practice it is almost always the tiebreaker after one of the reasons above, not a reason that justifies a migration on its own. ## The Reason Nobody Writes About: Founders Leave Stripe Accounts, Not Stripe Here is what the listicles miss. A meaningful share of founders typing "moving away from Stripe" into a search box are not shopping for a platform at all. Their business changed shape, and the Stripe account no longer fits: - **The SaaS was acquired.** The buyer needs revenue flowing into their own legal entity and their own Stripe account. The seller's account — and everything in it — usually cannot simply be handed over. - **The legal entity changed.** An LLC-to-corporation conversion, a holding-company restructure, or a carve-out can require a new account even though nothing changed for customers. - **The company moved countries.** Stripe accounts are anchored to a legal entity in a specific country. Relocate the company, and you typically need a new account in the new country. - **A product is being separated or consolidated.** Spinning a product out of a shared account, or merging several accounts after years of acquisitions. In all of these cases, the platform stays and the account changes — and that distinction has teeth. Stripe can copy eligible customers and saved payment methods between accounts, but its [account-copy process](https://support.stripe.com/questions/data-that-can-be-copied-between-stripe-accounts?locale=en-GB) explicitly does not copy subscriptions. Every active subscription must be recreated in the destination account with the right price mapping and billing anchor, and the source subscription must be deactivated without double-charging anyone. We covered the acquisition case in detail in [what happens to Stripe subscriptions when you sell your SaaS](/blog/what-happens-to-stripe-subscriptions-when-you-sell-your-saas/). ## What Does First-Hand Migration Data Show? A disclosure first: MoveMRR migrates subscriptions between Stripe accounts, so our dataset consists of account-level moves by construction. It cannot tell you how many founders leave Stripe for Paddle. What it can tell you is why account-level moves happen and at what scale. As of July 2026, completed MoveMRR projects cover **77,500+ active subscriptions** (a conservative lower bound across projects approved for publication). Of those, **76,300 subscriptions came from three SaaS acquisitions by a single buyer**, with the largest single run containing 46,000 subscriptions. The rest includes cases like a founder who moved his company to another country and needed a new Stripe account for the new entity. Two observations from that dataset: 1. **Acquisitions dominate.** When subscriptions move between accounts at scale, the trigger is overwhelmingly a change of ownership, not dissatisfaction with Stripe. 2. **Nobody in the dataset left the platform.** Every one of those businesses kept billing on Stripe — under a new owner, a new entity, or in a new country. The methodology and full numbers are published in our [migration research](/research/state-of-stripe-account-migrations-2026/), with the acquisition case documented [here](/customers/three-acquisitions-76300-subscriptions/). ## Should You Actually Leave Stripe? Work through the reasons in order of what they cost you: - **Tax and VAT burden is consuming real operational time**, you sell low-touch and globally, and you accept the fee premium and reseller model → a merchant of record is a defensible move. Compare the mechanics before committing: [merchant-of-record migration](/compare/merchant-of-record-migration/). - **Fees at scale** → negotiate with Stripe first; evaluate direct processors second; treat an MoR as a tax decision, not a fee decision. - **Freeze anxiety** → fix the controllable inputs and consider a second processor as a hedge. A full migration buys you the same risk at a different vendor. - **Support** → rarely worth a migration on its own; weigh it as a tiebreaker. - **Your company is being sold, restructured, or relocated** → you are not leaving Stripe. You need a Stripe-to-Stripe migration: plan it as its own workstream with our [migration service overview](/stripe-subscription-migration/) and the step-by-step [technical migration guide](/knowledge/stripe-subscription-migration-guide/). ## How Do Subscriptions Move Between Stripe Accounts? For the account-move case, the mechanics in brief: confirm the account path with Stripe, run Customer Data Copy for eligible customers and payment methods, recreate each subscription in the destination with matching prices and billing-cycle anchors, deactivate the source subscriptions at an agreed boundary so no customer is billed twice, and reconcile the result record by record. Stripe's own [Billing migration toolkit](https://docs.stripe.com/billing/subscriptions/import-subscriptions-toolkit) handles CSV-based imports for teams comfortable owning the mapping, cutover, and reconciliation themselves. MoveMRR exists for the cases where buyer and seller need a shared, auditable workflow around the same operation. Either way, the work is a migration project with a rehearsal and a cutover — not a checkbox in the purchase agreement. ## Primary sources - [Stripe pricing](https://stripe.com/pricing) - [Stripe Tax documentation](https://docs.stripe.com/tax) - [Stripe: data that can be copied between accounts](https://support.stripe.com/questions/data-that-can-be-copied-between-stripe-accounts?locale=en-GB) - [Stripe Billing migration toolkit](https://docs.stripe.com/billing/subscriptions/import-subscriptions-toolkit) --- _Facing an account move rather than a platform switch? Start with [what happens to Stripe subscriptions when you sell your SaaS](/blog/what-happens-to-stripe-subscriptions-when-you-sell-your-saas/) or go straight to the [technical migration guide](/knowledge/stripe-subscription-migration-guide/)._ --- # Stripe Subscription Migration Tool — 77,000+ Subs Moved Canonical: https://movemrr.com/stripe-subscription-migration/ > Migrate active subscriptions between Stripe accounts: preserved billing dates, dry runs, source deactivation, audit trail. 77.5k+ subs and $535k MRR moved. Stripe Customer Data Copy can copy eligible customer and payment data, but it does not move existing subscription objects. Stripe’s Billing Migration Toolkit can import and recreate subscriptions in a destination account. MoveMRR adds catalog mapping, readiness checks, dry runs, controlled source deactivation, reconciliation, and an audit trail for teams that need a complete Stripe-to-Stripe handover. ## What “transfer” means inside Stripe A subscription is not moved as the same Stripe object. Eligible customer and payment data is copied through Stripe, while products, prices, coupons, and subscriptions are recreated or imported in the destination. This means identifiers change and the source and destination states must be reconciled deliberately. ## What MoveMRR controls around Stripe’s primitives MoveMRR builds a reviewable workflow around the two accounts. It helps teams recreate or map the billing catalog, upload Stripe’s customer mapping, preview planned actions, validate readiness, preserve renewal timing, create destination subscriptions, and deactivate source subscriptions only after the configured safety conditions pass. - Restricted keys for separate source and destination permissions. - Product, price, coupon, customer, and payment-method mapping coverage. - Dry runs and planned-action review before the live run. - Free, unlimited sandbox projects on Stripe test keys, with seeding that adds your live catalog, discounts, and tax rates to a sandbox and recreates your subscriptions on the customers copied there by Stripe. - Optional recreation of the source account’s Stripe webhook endpoints on the destination, with a coverage check before and after the run. - Idempotent execution, audit logs, rollback controls, and exported mappings. ## What the team must still own The buyer or operator remains responsible for Stripe approval, account eligibility, application deployment, database references, webhook routing (endpoint recreation is optional and copies the source URLs unchanged) and re-deploying webhook consumers with their new signing secrets, tax and accounting, unsupported payment methods, customer communications, and monitoring future renewals. MoveMRR makes those dependencies visible; it does not make them disappear. ## Ways to recreate Stripe subscriptions in another account | Approach | Best fit | Trade-off | |---|---|---| | Stripe Billing Migration Toolkit | Teams with migration-ready CSVs and an internally owned cutover | Official primitives; application handover and source sequencing remain team-owned | | MoveMRR self-service | Teams that want a guided Stripe-to-Stripe workflow | Requires the team to review mappings, exceptions, and application changes | | MoveMRR guided or done-for-you | High-stakes deals needing hands-on support | Higher cost in exchange for planning and execution support | | Custom script | Unique architectures with experienced billing engineers | Maximum flexibility and maximum ownership of retries, testing, and audit evidence | ## Frequently asked questions **Can Stripe subscriptions be transferred to another account?** They can be recreated or imported in the destination account, but the existing subscription objects are not moved unchanged. Customer mapping, catalog mapping, timing, source deactivation, and application updates still need coordination. **Does Stripe have its own subscription migration tool?** Yes. Stripe’s Billing Migration Toolkit supports CSV-based imports, including Stripe-to-Stripe migrations. MoveMRR is designed for teams that also need a guided two-account workflow, catalog automation, dry runs, source-side controls, reconciliation, and an audit trail. **Will customers have to enter payment details again?** Eligible payment data can be copied by Stripe without a new signup. Some methods and account pairs are excluded, and an issuer may still require authentication on a future payment. **Can renewal dates be preserved?** Future billing dates can be aligned when the source data and destination configuration support it. The dry run and readiness review should identify exceptions before live creation. --- # Stripe Billing Handover for SaaS Acquisitions Canonical: https://movemrr.com/solutions/saas-acquisitions/ > A controlled Stripe subscription handover for SaaS buyers and sellers, with mapping, rehearsal, cutover gates, source deactivation, and an auditable record. A SaaS acquisition billing handover is more than recreating Stripe subscriptions. The buyer and seller must decide whether account ownership can change, map customers and prices, rehearse the destination setup, coordinate application changes, prevent overlapping charges, and reconcile every result. MoveMRR gives both sides one controlled workflow for those steps. ## First decide whether the Stripe account or the subscriptions should move Some business sales can be handled through an ownership or legal-entity update with Stripe Support. Other transactions—especially asset sales, cross-border acquisitions, carve-outs, or a buyer using an existing account—require a destination account and a subscription migration. MoveMRR starts after the parties have confirmed the correct account structure. - Share sale or unchanged legal entity: ask Stripe whether an ownership update is sufficient. - Asset sale or new operating entity: plan a destination-account handover. - Different destination country: expect a new Stripe account and verify data-copy eligibility. ## Give buyer and seller explicit cutover responsibilities The seller controls the source account and the buyer controls the destination. A safe plan names who requests Customer Data Copy, who recreates the destination catalog, who updates stored Stripe IDs and webhooks, who freezes last-minute billing changes, and who signs off before source subscriptions are deactivated. - Inventory Stripe objects and application dependencies before close. - Rehearse with sandbox data and a dry run before touching live subscriptions. - Verify destination subscriptions before any source-side deactivation. - Export customer and subscription mappings for the buyer’s application. ## Treat the application handover as part of the billing handover New Stripe objects receive new IDs. The buyer may need to update database references, webhook endpoints, entitlement logic, Customer Portal links, dunning automation, reporting, and support runbooks. MoveMRR provides migration mappings and an audit trail; the buyer remains responsible for deploying and validating application changes. ## Account ownership change versus subscription migration | Situation | Likely path | Primary validation | |---|---|---| | Same entity and country | Ownership or representative update may be enough | Confirm with Stripe Support | | Asset sale to a new entity | New destination account and controlled migration | Contract, data-copy eligibility, application cutover | | Buyer in another country | New account is normally required | Country support, payment methods, tax and settlement | | Carve-out from a shared account | Scope and migrate only the acquired product | Object inventory and data separation | ## Frequently asked questions **Can a SaaS buyer simply take over the seller’s Stripe account?** Sometimes an ownership or entity update is possible, but it depends on the transaction, legal entity, country, and Stripe approval. Confirm this with Stripe before planning a migration. **Do customers need to re-enter their card details?** Eligible customer and payment data can be copied by Stripe without a new signup. Coverage varies by payment method and account pair, and a bank can still request authentication on a later payment. **When should the billing handover be planned?** Before close. The purchase agreement and technical runbook should name account ownership, data-copy responsibilities, cutover timing, application changes, validation, and fallback ownership. --- # Cross-Border Stripe Account Migration Canonical: https://movemrr.com/solutions/cross-border-stripe-migration/ > Move eligible Stripe customers and recurring subscriptions to an account in another country while preserving renewal timing and controlling cutover risk. A Stripe account’s country cannot simply be edited after activation. A cross-border company move or acquisition normally requires a new account in the destination country, an eligibility review for Stripe’s data-copy process, recreation or mapping of the billing catalog, and a controlled subscription cutover. Payment-method, tax, currency, settlement, and issuer rules must be checked before launch. ## Verify destination-account eligibility before building the runbook Confirm that the destination entity can open the required Stripe account, that the business model and settlement bank are supported, and that Stripe can copy the relevant customer and payment data between this exact account pair. Do not infer payment-method portability from card coverage. ## Rebuild billing around the destination account Products, prices, subscriptions, invoices, coupons, events, and logs are not transferred as unchanged objects by Customer Data Copy. They must be recreated, imported, or mapped in the destination. This creates new identifiers that the application and reporting stack must understand. - Map currency and price behavior instead of assuming one-to-one equivalence. - Review Stripe Tax registrations and product tax codes for the destination entity. - Check SEPA, ACH, wallets, local methods, and legacy Sources separately. - Reissue webhook secrets and update environment-specific account IDs. ## Separate technical continuity from legal and tax advice MoveMRR can automate and document the Stripe-to-Stripe subscription workflow, but it does not determine tax nexus, invoicing obligations, customer-notice requirements, or whether contracts can be assigned. Those decisions belong to the business and its advisers. ## Cross-border readiness checks | Area | Before migration | Acceptance evidence | |---|---|---| | Account | Destination entity, country, bank, capabilities approved | Live destination account ready | | Payment data | Stripe confirms account-pair and method eligibility | Copied-customer mapping file | | Billing | Catalog, tax, currency, anchors and discounts mapped | Dry-run coverage report | | Application | IDs, webhooks, portals and reporting updated | End-to-end test and owner sign-off | ## Frequently asked questions **Can I change the country on an existing Stripe account?** Stripe generally requires a new account for a different account country. Confirm the exact path with Stripe Support before creating migration dependencies. **Will every saved payment method be copied?** No. Eligibility depends on the payment-method type and the source/destination accounts. Obtain Stripe’s confirmation and review the mapping output before migration. **Can customers continue on the same renewal date?** Eligible subscriptions can be recreated with aligned future billing dates, subject to Stripe’s creation rules and a successful readiness review. --- # Stripe Migration for a Legal-Entity Change Canonical: https://movemrr.com/solutions/legal-entity-change/ > Decide whether to update account ownership or migrate subscriptions when a Stripe business changes legal entity, ownership, or operating structure. A legal-entity change does not automatically require subscription migration. If the operating business and country remain compatible, Stripe may support an ownership or entity update. If contracts, country, merchant of record, settlement, or account ownership must move to a new account, plan a controlled migration instead. Stripe Support should confirm the account path first. ## Start with the legal and operational facts Document who owns the customer contracts before and after the change, which entity issues invoices, which country and bank receive settlement, and whether the buyer needs isolation from the seller’s other products. These facts determine whether an account update or a new account is appropriate. ## Use migration when the destination must be a separate account A separate destination creates new Stripe object IDs and operational ownership. The migration plan must therefore cover data-copy eligibility, catalog mapping, subscription creation timing, source deactivation, application changes, accounting, and customer support. ## Do not use a migration tool as legal advice MoveMRR implements the technical workflow selected by the business. It does not decide contract assignment, tax registrations, privacy roles, customer notices, or regulatory obligations. ## Entity update or new-account migration | Question | Account update may fit | Migration may fit | |---|---|---| | Operating country | Unchanged | Different country or unsupported change | | Contracting entity | Continuity accepted by Stripe and advisers | New merchant or asset buyer | | Billing isolation | Whole account transfers together | Only one product or customer set moves | | Application impact | Existing object IDs remain | New customer, price and subscription IDs | ## Frequently asked questions **Does changing a company name require a subscription migration?** Not necessarily. A name or representative update may be handled within the existing account, but Stripe must confirm what is permitted for the exact legal change. **When is a new Stripe account usually needed?** Common triggers include a new account country, an asset buyer becoming merchant of record, a carve-out, or a requirement to separate billing ownership. **What changes in the application after migration?** Customer, price, product, subscription and possibly invoice identifiers change. Webhook secrets, portals, reporting, entitlement mappings, and support tooling may also need updates. --- # Separate or Consolidate Stripe Subscription Accounts Canonical: https://movemrr.com/solutions/account-separation-and-consolidation/ > Plan a Stripe carve-out, product spin-off, agency handover, or account consolidation without losing renewal timing or mixing customer scope. Stripe account separation and consolidation require a scope-first migration. Before copying customers or recreating subscriptions, identify which product, customer, price, discount, tax, and application records belong in the destination. Shared customers and shared catalog objects need explicit rules; otherwise a technically successful move can still create ownership, reporting, or support errors. ## Define the boundary before touching Stripe Create a manifest of the customers and subscriptions that move, the catalog objects they reference, and every shared dependency. A customer with multiple products or subscriptions may span both sides of the carve-out and cannot be classified safely by email address alone. ## Resolve shared objects explicitly Shared products, legacy prices, coupons, tax rules, promotion codes, webhook consumers, and metadata conventions need destination mappings. The source may continue operating after the carve-out, so deactivation rules must apply only to the transferred subscriptions. ## Reconcile commercial scope, not just API success Acceptance should compare the agreed manifest with destination subscriptions, future renewal dates, amounts, customer mappings, source cancellation state, and application entitlements. API success alone does not prove that the correct business was transferred. ## Scope controls for account restructuring | Risk | Control | Acceptance check | |---|---|---| | Shared customer | Classify by subscription/product scope | Non-transferred subscriptions remain untouched | | Shared catalog | Create destination-specific mappings | Every migrated item resolves to an approved price | | Dual account operation | Route webhooks and new sales explicitly | No event or signup is processed by the wrong account | | Partial deactivation | Gate by migrated subscription ID | Only accepted source subscriptions are deactivated | ## Frequently asked questions **Can one Stripe customer be split between two accounts?** The destination can receive an eligible copied customer, but each subscription still needs an explicit scope and recreation decision. The source-side records outside the carve-out must remain untouched. **Can multiple Stripe accounts be consolidated?** Subscriptions from multiple sources can be planned into one destination, but each account pair, catalog mapping, identifier namespace, and cutover window must be validated separately. **How are new signups handled during a carve-out?** Choose a defined freeze, routing switch, or delta-reconciliation process. Without one, subscriptions created after the manifest is captured can be missed or assigned to the wrong owner. --- # Stripe Subscription Handover for SaaS Buyers Canonical: https://movemrr.com/for/saas-buyers/ > Buyer-side acceptance criteria for receiving customers, subscriptions, renewal dates, Stripe mappings, and operational control after a SaaS acquisition. A SaaS buyer should treat Stripe billing as a closing workstream with explicit acceptance criteria. Before the seller deactivates anything, the buyer needs verified destination customers and subscriptions, complete old-to-new ID mappings, deployed webhook and database changes, exception ownership, reconciliation evidence, and a plan for the first renewal cycle. ## Put billing acceptance into the transaction checklist The deal should name which subscriptions and customers transfer, which Stripe account becomes authoritative, who owns customer-data-copy requests, how new signups are handled during cutover, and what evidence allows the seller to deactivate source subscriptions. ## Require operational control, not only matching counts A matching subscription count can hide wrong prices, dates, discounts, payment defaults, tax behavior, metadata, or application IDs. Buyer acceptance should sample the actual billing shapes and prove that destination events update entitlements and reporting correctly. - Validate renewal date, amount, currency, status, quantity, discounts, and tax behavior. - Update stored customer, price, product, and subscription identifiers. - Rotate webhook secrets and confirm idempotent event handling. - Monitor the first renewals and failed-payment paths in the destination. ## Keep a named exception owner after close Missing payment methods, legacy prices, near-renewal subscriptions, past-due accounts, and application mismatches need owners and deadlines. The purchase agreement should define whether the seller, buyer, or migration provider resolves each class. ## Buyer acceptance evidence | Control | Weak evidence | Strong evidence | |---|---|---| | Scope | A total subscription count | Signed manifest with source and destination IDs | | Billing continuity | Subscriptions exist | Dates, amounts, methods, discounts, and states reconcile | | Application | Code was deployed | Webhook-to-entitlement test succeeds in destination | | Source shutdown | Seller says it is done | Only accepted source subscriptions have the approved deactivation state | ## Frequently asked questions **What should a SaaS buyer receive after a Stripe migration?** At minimum: the signed scope, old-to-new object mappings, exception list, source and destination results, audit log, application change record, first-renewal monitoring plan, and ownership for unresolved items. **Should source subscriptions be canceled before buyer testing?** No. Destination subscriptions and application behavior should be validated before the configured source deactivation is allowed to proceed. **Can historical Stripe data be moved unchanged?** Customer Data Copy and subscription recreation do not turn the destination into an identical historical clone. Retention and reporting for source invoices, events, logs, disputes, and payouts require a separate plan. --- # Stripe Subscription Handover for SaaS Sellers Canonical: https://movemrr.com/for/saas-sellers/ > Prepare a clean Stripe billing handover with an agreed scope, customer-data-copy workflow, destination validation, source controls, and post-close evidence. A SaaS seller should prepare the Stripe handover before closing: clean the catalog, identify active and exceptional subscriptions, document application dependencies, confirm the destination-account path, request eligible customer-data copy, and agree when source subscriptions may be deactivated. This protects both the buyer’s continuity and the seller’s post-close obligations. ## Make the source account migration-ready before close Remove accidental catalog ambiguity, identify archived and legacy prices, document active discounts and special contracts, flag missing payment methods, and inventory subscriptions close to renewal. The cleaner the source inventory, the fewer decisions are forced into the cutover window. ## Agree exactly what the seller will do The runbook should distinguish customer-data-copy requests, source key creation, catalog clarification, migration approval, source deactivation, historical-data retention, and application assistance. Access should be scoped and time-bound rather than shared informally. ## Close with evidence the buyer can operate Provide object mappings, audit output, unresolved exceptions, source-state confirmation, and knowledge about non-obvious billing logic. Do not treat a successful API response as the end of the transition. ## Seller preparation checklist | Before close | During cutover | After acceptance | |---|---|---| | Inventory and clean source billing | Keep agreed configuration stable | Retain required historical access | | Confirm Stripe account path | Approve only reviewed actions | Revoke temporary access | | Document app and webhook dependencies | Support identifier mapping | Transfer runbooks and exception ownership | | Agree customer communication policy | Escalate payment-data gaps | Support the defined stabilization window | ## Frequently asked questions **Should the seller give the buyer the existing Stripe login?** Not by default. First confirm whether account ownership can properly transfer. For a new-account migration, use scoped access and a documented two-account workflow instead of sharing personal credentials. **When can the seller deactivate old subscriptions?** Only after the destination subscriptions and agreed acceptance checks pass, using the deactivation timing defined in the runbook. **What should remain available after close?** The parties should agree retention and access for historical invoices, disputes, refunds, tax reports, events, logs, support evidence, and the migration audit record. --- # Stripe Billing Handover for SaaS M&A Advisers Canonical: https://movemrr.com/for/ma-brokers-and-advisors/ > A repeatable billing-handover framework for SaaS brokers, M&A advisers, lawyers, diligence teams, and operators supporting buyers and sellers. M&A advisers can reduce closing and post-close risk by requiring a billing-handover schedule alongside the asset list. The schedule should identify the Stripe account path, transfer scope, payment-data-copy owner, technical dependencies, cutover approvals, acceptance evidence, unresolved exceptions, and post-close monitoring owner. ## Add billing topology to early diligence Ask which legal entity owns the Stripe account, whether other products share it, where the buyer entity is located, how subscriptions map to the sale perimeter, which payment methods are used, and what the application stores locally. These answers determine whether an ownership update, carve-out, or full migration is required. ## Turn technical dependencies into deal responsibilities The handover schedule should assign Stripe support requests, data-copy steps, catalog mapping, code deployment, webhook routing, source changes, customer notices, reconciliation, and stabilization support to named parties and dates. ## Use acceptance evidence instead of “migration completed” A credible completion packet includes agreed scope, old-to-new identifiers, dry-run approval, destination reconciliation, source-state proof, exception list, access revocation, and the first-renewal monitoring owner. ## Where billing handover belongs in the deal | Deal phase | Billing question | Required output | |---|---|---| | Diligence | Can the account transfer, and what is in scope? | Topology and dependency inventory | | Signing | Who performs and approves each step? | Responsibility and access matrix | | Pre-close | Is the destination ready? | Dry run, exceptions, and go/no-go criteria | | Post-close | Did the buyer receive operable billing? | Acceptance packet and monitoring plan | ## Frequently asked questions **When should Stripe migration enter SaaS due diligence?** As soon as the buyer knows the acquisition perimeter and operating entity. Account country, shared products, payment methods, renewal concentration, and application coupling can change timeline and closing dependencies. **What is the minimum billing-handover deliverable?** A topology decision, signed scope, responsibility matrix, dry-run and exception record, destination acceptance criteria, source-action approval, mappings, audit output, and stabilization owner. **Can MoveMRR support both parties?** Yes. The workflow separates source and destination responsibilities and can provide a common record, while account access and transaction authority remain with the appropriate party. --- # MoveMRR vs Stripe Billing Migration Toolkit Canonical: https://movemrr.com/compare/stripe-billing-migration-toolkit/ > Compare Stripe’s official CSV migration toolkit with MoveMRR’s guided Stripe-to-Stripe mapping, rehearsal, cutover, deactivation, and audit workflow. Stripe’s Billing Migration Toolkit is the official, no-code-capable way to import subscriptions from CSV, including from another Stripe account. It is a strong fit when your team can prepare valid data and own the surrounding cutover. MoveMRR is a separate product for teams that want catalog automation, customer mapping checks, dry runs, source-account controls, reconciliation, and guided or done-for-you execution. ## When Stripe’s toolkit is likely enough Use the official toolkit when your team can produce a correct migration CSV, already has destination customer and price IDs, can work with subscription schedules and the required future start window, and has clear owners for canceling the source system, updating the application, and monitoring renewals. ## When MoveMRR adds meaningful value MoveMRR is designed for a Stripe-to-Stripe account handover where the source catalog, customer mapping, destination catalog, planned actions, source deactivation, retries, and evidence need to be managed as one project. Guided and done-for-you tiers add hands-on support when the buyer and seller do not want to coordinate that alone. ## Do not choose based on “transfer button” language Neither approach moves an existing subscription object unchanged. Both result in destination objects and require accurate mapping. The important decision is whether your team wants to own the complete operational runbook around Stripe’s documented migration primitives. ## Stripe Toolkit and MoveMRR compared | Capability | Stripe Billing Migration Toolkit | MoveMRR | |---|---|---| | Provider | Stripe | Independent product; not affiliated with Stripe | | Primary input | Migration-compatible CSV | Connected source/destination workflow plus Stripe mapping data | | Catalog preparation | Team supplies destination IDs or ad-hoc data | Product and price mapping/automation in the guided workflow | | Testing | Sandbox migration supported | Readiness validation and a dry run before the live run | | Rehearsal cost | Stripe test mode is free; the rehearsal workflow around it is yours to build | Sandbox projects are free and unlimited; the fee covers the live migration only | | Rehearsal data | You populate the test account yourself | Sandbox seeding recreates live products, prices, coupons, promotion codes, tax rates, and active, trialing, and past-due subscriptions in your Stripe sandbox | | Stripe webhook endpoints | Out of scope; the toolkit imports subscriptions | Optional recreation on the destination, with a pre-run coverage check, an event-union update instead of duplicate endpoints, and a post-run diff | | Activation model | Subscription schedules with documented buffer | Configured destination creation and source-deactivation workflow | | Source account | Team owns cancellation and reconciliation | Source actions gated in the project workflow | | Application handover | Team-owned | Mappings and audit evidence supplied; deployment remains team-owned | | Support model | Stripe documentation/support | Self-service, guided, or done-for-you tiers | ## Frequently asked questions **Is Stripe’s Billing Migration Toolkit free?** Stripe documents the toolkit as a Dashboard migration capability. Check your current Stripe pricing and account availability; the surrounding engineering and operational work remains your responsibility. **Does MoveMRR replace Stripe Customer Data Copy?** No. Stripe performs eligible customer and payment-data copying. MoveMRR consumes the resulting mapping as part of the subscription handover workflow. **Which option is safer?** Safety depends on preparation, representative testing, exception handling, source sequencing, application readiness, and monitoring. Choose the workflow your team can execute and verify completely. --- # MoveMRR vs SubPorter Canonical: https://movemrr.com/compare/subporter/ > A balanced comparison of MoveMRR and SubPorter for moving live Stripe subscriptions between accounts during a sale, acquisition, or account change. SubPorter and MoveMRR both target Stripe-to-Stripe subscription handovers with renewal protection and source-side controls. SubPorter publicly positions itself as a narrow, flat-fee self-service workflow with a two-party room. MoveMRR offers volume-based self-service, guided, and done-for-you tiers, with demonstrated migrations ranging from small founder moves to a 46,000-subscription single run. ## Choose SubPorter when its narrow self-service model matches SubPorter describes a plan-copy-migrate workflow, a 48-hour renewal buffer, source read-only behavior until destination verification, two-party sign-off, and an audit packet. It may fit a team that wants a low flat price and is comfortable retaining ownership of application and database changes. ## Choose MoveMRR when support level or proven scale matters MoveMRR combines self-service software with optional walkthroughs and done-for-you execution. It supports catalog and customer mappings, simulation and live runs, source deactivation controls, retries, rollback protection, mappings, and audit logs, backed by published customer examples up to tens of thousands of subscriptions. ## Validate both products against your edge cases Marketing pages cannot prove compatibility for your exact account. Ask both vendors about subscription statuses, legacy prices, discounts, taxes, schedules, multi-item subscriptions, metered usage, payment methods, near-renewal behavior, account access, retries, and application handover. ## MoveMRR and SubPorter compared | Area | SubPorter | MoveMRR | |---|---|---| | Public positioning | Narrow self-service Stripe billing handoff | Self-service, guided, and done-for-you Stripe migration | | Public pricing | $199 flat for one project at review date | Volume-based EUR pricing by service tier | | Two-party workflow | Publicly describes source + destination sign-off | Separate source/destination setup with guided approvals and audit records | | Rehearsal cost | No free rehearsal tier described on its public pages at the July 2026 review | Free, unlimited sandbox projects and rehearsal runs on Stripe test keys before anything is paid | | Realistic test data | No sandbox data cloning described on its public pages at the July 2026 review | Sandbox seeding recreates the live catalog, discounts, tax rates, and subscription shapes in your Stripe sandbox | | Stripe webhook endpoints | Not described on its public pages at the July 2026 review | Optional recreation on the destination, with per-endpoint results and the exact list of endpoints whose signing secret must be re-deployed | | Vendor identification | At the August 2026 review the site published no legal notice, terms, or privacy policy, and named no company, address, or contact person | Named operating company with a published imprint, terms, and privacy policy, and a named founder | | Published proof | Illustrative workflow on public site | Named customer stories and aggregate completed-migration metrics | | Application changes | Kept under the customer team’s control | Mappings supplied; application deployment remains customer-owned unless separately scoped | | Best fit | Cost-sensitive self-service project fitting documented scope | Teams selecting support level, complex mapping, or demonstrated large-scale execution | ## Frequently asked questions **Is SubPorter cheaper than MoveMRR?** SubPorter publicly listed a $199 flat project fee at the review date. MoveMRR uses volume-based pricing with self-service, guided, and done-for-you tiers. Compare the current price for your volume and required support. **Does either tool update my SaaS database automatically?** Do not assume so. Both workflows create new destination identifiers. MoveMRR exports mappings and audit data, but the application deployment remains customer-owned unless explicitly scoped. **How should I choose?** Use a requirements matrix and representative sandbox test. Compare supported states, payment methods, exception handling, source controls, evidence, support, scale, and total ownership. **What should I check before giving any migration vendor access to my Stripe account?** A migration vendor receives restricted API keys to your live billing data, so treat it as you would any other data processor. Establish which legal entity you are contracting with, where it is registered, and who is reachable if a run fails halfway through your cutover. Confirm that terms of service and a privacy policy exist, because handing customer data to a processor without a documented basis is your own compliance exposure as much as the vendor’s. Ask which Stripe permissions are requested and how keys are stored, expired, and revoked. At the August 2026 review, subporter.com published no legal notice, terms of service, or privacy policy and named no company, address, or contact person, and we found no independent public reviews of it; verify the current state yourself before deciding. MoveMRR publishes an imprint, terms, and a privacy policy, names its founder, and documents its key handling and permission scopes on its security page. --- # MoveMRR vs Good Migrations Canonical: https://movemrr.com/compare/good-migrations/ > Compare MoveMRR’s product-led Stripe subscription workflow with Good Migrations’ founder-led migration planning and execution service. Good Migrations positions itself as a founder-led Stripe migration firm for high-risk account transitions, with assessment, custom runbooks, execution, and validation. MoveMRR is product-led software with self-service, guided, and done-for-you tiers. The decision is mainly whether you need bespoke cross-system consulting or a structured Stripe-to-Stripe workflow at a published volume-based price. ## Choose Good Migrations for broad, bespoke migration ownership Good Migrations publicly emphasizes assessments, custom runbooks, application and database dependencies, cutover support, and post-migration validation across Stripe and other billing architectures. That is a strong fit when senior consulting and a project-specific engagement are the primary requirement. ## Choose MoveMRR for a productized Stripe-to-Stripe workflow MoveMRR provides a repeatable web application for mapping, sandbox preparation, dry runs, live execution, source deactivation, retries, and audit output, with optional guided sessions or done-for-you support. It is focused on recurring subscriptions moving between Stripe accounts. ## Compare scope before comparing logos or aggregate volume A migration of millions of subscriptions and a founder asset sale can require different delivery models. Evaluate your billing platform, source/destination topology, custom application logic, regulatory needs, timeline, procurement, support channel, exception classes, and required evidence. ## MoveMRR and Good Migrations compared | Area | Good Migrations | MoveMRR | |---|---|---| | Delivery model | Founder-led assessment and execution service | Product-led self-service, guided, or done-for-you | | Public focus | High-risk account and billing-platform transitions | Stripe-to-Stripe active subscription handover | | Runbook | Custom engagement-specific plan | Structured product workflow plus configurable project behavior | | Application dependencies | Publicly included in assessment and planning | Mappings and guidance; custom work only when scoped | | Pricing | Assessment/contact-led | Published volume-based EUR pricing | | Rehearsal cost | Rehearsal happens inside a paid engagement | Free, unlimited sandbox projects on Stripe test keys before you buy anything | | Realistic test data | Prepared as consulting work within the engagement | Sandbox seeding recreates the live catalog and subscription shapes in your Stripe sandbox from a read-only live key that is never stored | | Stripe webhook endpoints | Covered by the engagement where scoped | Optional in-product recreation with a readiness check, per-endpoint results, and a post-run coverage diff | | Proof scale | 3.25M subscriptions and $425M+ ARR publicly claimed | 77.5k+ subscriptions and $535k+ MRR publicly reported | ## Frequently asked questions **Is Good Migrations a software product?** Its public site positions the company primarily as a founder-led planning and execution firm. Ask for the current delivery model and engagement scope directly. **Does MoveMRR offer done-for-you support?** Yes. MoveMRR has self-service, guided, and done-for-you volume-based tiers. Custom engineering remains subject to explicit scope. **Which is better for a complex enterprise migration?** A bespoke specialist engagement may fit broad billing-platform and application transformation. MoveMRR fits a defined Stripe-to-Stripe subscription workflow. Validate both against the exact architecture. --- # MoveMRR vs Move Account Canonical: https://movemrr.com/compare/move-account/ > Compare MoveMRR with Move Account for Stripe account migrations, especially cross-border moves, legal-entity changes, and recurring subscription handovers. Move Account publicly positions itself around moving Stripe accounts without losing customers, with an emphasis on cross-border migration. MoveMRR focuses on the controlled recreation of recurring subscriptions between Stripe accounts, including mappings, rehearsal, source deactivation, audit evidence, and multiple support tiers. Verify both against your exact countries, payment methods, catalog, and application dependencies. ## Start with the account pair, not the vendor list Before comparing tools, ask Stripe whether customer and payment data can be copied between the exact source and destination accounts. Confirm destination country capabilities, settlement, currencies, local payment methods, tax obligations, and whether a new account is required. ## Assess subscription and application depth Ask how each product handles products, prices, coupons, taxes, trials, past-due subscriptions, multiple items, schedules, metered usage, future anchors, source deactivation, retries, object mappings, webhooks, database identifiers, and post-cutover reconciliation. ## Use a representative sandbox before buying A polished cross-border promise cannot validate an account pair or legacy billing shape. Test a sample that includes the difficult records, then compare exception visibility, acceptance evidence, support, and total ownership. ## MoveMRR and Move Account evaluation matrix | Area | Move Account | MoveMRR | |---|---|---| | Public emphasis | Cross-border Stripe account migration | Stripe-to-Stripe subscription handover across exits and account changes | | Customer/payment data | Subject to Stripe account-pair eligibility | Subject to Stripe account-pair eligibility | | Subscription workflow | Confirm current product documentation | Mapping, rehearsal, live run, source controls, and audit output | | Support | Confirm current service options | Self-service, guided, and done-for-you tiers | | Rehearsal cost | Confirm whether a free rehearsal is offered | Free, unlimited sandbox projects and rehearsal runs on Stripe test keys | | Realistic test data | No sandbox data cloning described on its public pages at the July 2026 review | Sandbox seeding recreates the live catalog, tax rates, and subscription shapes in your Stripe sandbox | | Stripe webhook endpoints | Not described on its public pages at the July 2026 review | Optional recreation on the destination, with a readiness check before the run and a coverage diff after it | | Published MoveMRR evidence | Not applicable | own.page cross-country migration plus broader customer stories | | Application handover | Verify included scope | Mappings supplied; deployment remains team-owned unless scoped | ## Frequently asked questions **Can either tool change the country of my existing Stripe account?** No tool can simply edit Stripe’s account-country rules. A new destination account is normally required, and Stripe must confirm the supported data-copy path. **Which payment methods move cross-border?** Coverage depends on the method and account pair. Ask Stripe, review the copied-customer mapping, and test the destination before planning live subscription creation. **What should I compare beyond price?** Compare country and method eligibility, billing-shape support, mapping coverage, source controls, retries, application handover, audit evidence, support, and monitoring. --- # Best Merchant of Record to Migrate to from Stripe (2026) Canonical: https://movemrr.com/compare/merchant-of-record-migration/ > Compare Paddle, Polar, Lemon Squeezy, and Dodo Payments as Stripe migration destinations: what a merchant of record takes over, current fees, and which data actually moves. Paddle publishes the most complete assisted path off Stripe, including subscription imports and payment-method transfer into its PCI vault. Polar offers low paid-plan rates for developer-led products but documents no Stripe subscription import. Dodo Payments has the lowest headline rate, and its importer covers products and customers rather than active subscriptions. Lemon Squeezy is owned by Stripe and steering users toward Stripe Managed Payments. If the real problem is your Stripe account rather than Stripe itself, a Stripe-to-Stripe migration keeps saved payment methods without customer action. ## What a merchant of record actually takes over A merchant of record becomes the legal seller of your product. It runs the checkout, calculates and remits sales tax and VAT across jurisdictions, carries chargeback and payment-compliance liability, and answers billing disputes in its own name. That is genuinely valuable when global tax filings are the bottleneck, and it is priced accordingly: the 4–7% fee replaces Stripe processing plus your own tax tooling, so compare the total cost of compliance rather than the processing rate alone. ## The main destinations, priced as of August 2026 All of the destinations below publish per-transaction pricing, and several changed their rates within the last year, so verify each one directly before deciding. - Paddle: 5% + $0.50 per checkout transaction; custom pricing for products under $10, invoicing, and enterprise volumes. - Polar: 5% + $0.50 on the free plan; paid plans from $20 to $400 per month reduce that to 3.8%–3.4% plus $0.30–$0.40, international cards add 1.5%, and organizations created before May 2026 keep the earlier 4% + $0.40 rate. - Lemon Squeezy: 5% + $0.50 plus documented surcharges for international cards, PayPal, and subscription payments; owned by Stripe since 2024. - Dodo Payments: 4% + $0.40 on US domestic transactions, +1.5% international and +0.5% subscriptions, with per-refund and per-dispute fees. - Briefly: FastSpring is quote-based, with reviews commonly citing around 5.9% + $0.95 before volume discounts; Freemius starts at 4.7% of revenue (7% with the WordPress package), decreasing with volume. ## What actually moves out of Stripe—and what does not Customer records and subscription data can be exported and recreated, but saved cards move only through Stripe’s payment-data export, which requires the destination to be a PCI DSS Level 1 processor and always excludes Link credentials. Paddle documents this assisted transfer into its vault, delivered with an old-to-new ID mapping file, and Freemius advertises assisted migrations that keep existing Stripe renewals syncing during the transition. Polar’s self-serve importer covers Lemon Squeezy—not Stripe—and cannot move active subscriptions, and Dodo’s importer covers products, customers, and discounts without documenting subscriptions or saved cards. Where a vendor documents no card import, plan for customer re-consent or checkout re-entry and the churn that comes with it. ## Many founders searching this do not need to leave Stripe If the trigger is an acquisition, a legal-entity change, a country move, or trouble with one specific Stripe account, the platform is not the problem—the account is. A Stripe-to-Stripe migration copies eligible customers and saved payment methods between accounts through Stripe itself and recreates subscriptions with preserved renewal dates, without customers re-entering anything. That keeps Stripe’s processing rates and avoids re-consent risk entirely. Move to a merchant of record when global tax compliance is the pain you are actually paying to remove. ## Merchant-of-record destinations for a Stripe migration (reviewed August 2026) | Destination | Published pricing as of August 2026 | Documented migration path from Stripe | |---|---|---| | Paddle | 5% + $0.50 per checkout; custom below $10, for invoicing, and at enterprise volume | Assisted subscription import plus payment-method transfer into Paddle’s PCI vault, with an ID mapping file | | Polar | 5% + $0.50 free plan; $20–$400/mo plans from 3.8% + $0.40 down to 3.4% + $0.30 | Importer covers Lemon Squeezy only and no active subscriptions; ask Polar about assisted options | | Lemon Squeezy | 5% + $0.50 plus international, PayPal, and subscription surcharges | Owned by Stripe; users are being pointed toward Stripe Managed Payments—confirm onboarding first | | Dodo Payments | 4% + $0.40 US domestic; +1.5% international, +0.5% subscriptions | Importer covers products, customers, and discounts; subscriptions and saved cards are undocumented—check with the vendor | | FastSpring | Quote-based; reviews commonly cite about 5.9% + $0.95 before negotiation | Sales-led onboarding with assisted imports; confirm the exact scope in your contract | | Freemius | From 4.7% of revenue; 7% with the WordPress package; decreases with volume | Advertises assisted migration that keeps existing Stripe renewals syncing during the transition | | Stay on Stripe (MoveMRR) | Stripe processing rates unchanged; MoveMRR priced by migrated volume | Stripe copies eligible customers and cards between accounts; subscriptions—and optionally the Stripe webhook endpoints—are recreated on the destination, rehearsed first in a free, unlimited Stripe sandbox | ## Frequently asked questions **Which merchant of record is best for migrating off Stripe?** It depends on what must move. Paddle publishes the most complete assisted path, including payment-method transfer. Polar suits developer-led products that can rebuild subscriptions at checkout. Dodo Payments has the lowest headline rate but no documented subscription import. Freemius fits software businesses that want assisted migration with license keys. **Do saved cards transfer from Stripe to a merchant of record?** Only through Stripe’s payment-data export, which requires the receiving processor to be PCI DSS Level 1 compliant and always excludes Link credentials. Paddle documents this assisted route. Where a vendor does not document card import, customers must re-enter payment details or approve a new mandate. **Will my subscribers have to do anything after the switch?** With a vendor-assisted card transfer, most renewals continue without action, though issuers can still request authentication. Without one, every subscriber must re-enter payment details, and some will not. A Stripe-to-Stripe migration avoids customer action for eligible payment methods because Stripe copies them between accounts. **What if I need to leave my Stripe account, not Stripe?** Then a merchant of record solves the wrong problem. For acquisitions, legal-entity changes, and account restructuring, a Stripe-to-Stripe migration keeps saved payment methods and renewal dates while the business moves to a new account. That is the scenario MoveMRR is built for. **Can I rehearse the move before I commit to it?** With a merchant of record, the rehearsal depends on that provider’s sandbox and the import itself is vendor-run, so you are largely evaluating a promise. A Stripe-to-Stripe migration can be rehearsed by you: MoveMRR sandbox projects use Stripe test keys, are free and unlimited, and sandbox seeding recreates your live catalog, discounts, tax rates, and subscription shapes in a Stripe sandbox. You can run the full migration there as often as you want before paying for the live run. Webhook endpoints are the one thing seeding does not copy into the sandbox; create them there by hand if you want to rehearse that step too. **Is Lemon Squeezy still a sensible migration target in 2026?** Stripe acquired Lemon Squeezy in 2024 and is moving users toward Stripe Managed Payments, its own merchant-of-record product. Both currently operate, but confirm onboarding availability and the long-term product path before making it the destination of a migration. --- # Stripe Billing Cycle Anchors Canonical: https://movemrr.com/compatibility/billing-cycle-anchors/ > Preserve future Stripe renewal timing during an account migration without charging immediately or creating an overlapping source renewal. A destination subscription must use a valid future billing boundary. MoveMRR derives and validates the next applicable renewal from the source period and configured alignment behavior. Past anchors cannot simply be copied as creation values. Near-renewal subscriptions require extra time and a deliberate source-deactivation plan. ## Migration behavior: Stripe Billing Cycle Anchors Stripe’s billing cycle anchor determines future invoice timing. During migration, the relevant business fact is normally the next renewal boundary, not the original historical anchor. MoveMRR preserves alignment where the source interval and period data support a reliable future date and prevents past-due records from being charged immediately by an unsafe “start now” fallback. ## What the readiness review must verify Compatibility is established from the actual Stripe objects, not from a page title. The project should surface every missing mapping, unsupported field, ambiguous state, and destination prerequisite before the live run. - Source current period end and billing anchor are present and expressed in Unix seconds. - All recurring items use compatible intervals and interval counts. - The destination price mapping preserves the intended recurring cadence. - The cutover buffer leaves enough time before the next source renewal. ## The primary failure mode to control Using “now” or an incorrect future anchor can create an immediate invoice, shift the customer’s renewal date, or overlap a source charge. The approved dry-run output should show the destination date for every subscription. ## Stripe Billing Cycle Anchors: source-to-destination checks | Check | Required evidence | If it fails | |---|---|---| | Future boundary | Destination date matches approved source renewal | Exclude and review the subscription | | Recurring interval | Mapped price cadence matches source | Correct the price mapping | | Near renewal | Enough time remains for creation and verification | Move to a later controlled batch | | Source action | No source invoice can overlap destination timing | Change deactivation timing | ## Frequently asked questions **Can the original billing date be kept?** The next valid future renewal can usually be aligned when the source interval and period data are unambiguous and the destination price cadence matches. **Why not copy billing_cycle_anchor directly?** The stored anchor can be historical. Stripe needs a valid creation configuration and future billing behavior, so the next applicable boundary must be validated. **What if renewal is tomorrow?** Treat it as a near-renewal exception. Finish the source charge or move the subscription into a later batch rather than rushing an unverified cutover. --- # Trialing Stripe Subscriptions Canonical: https://movemrr.com/compatibility/trialing-subscriptions/ > Migrate Stripe subscriptions that are still in trial while preserving the intended remaining trial and avoiding an early invoice. Trialing subscriptions can be migrated when the destination setup has the required customer, payment, price, and trial behavior. The destination should normally preserve the remaining trial until a validated future trial end. Expired, missing, or incompatible dates are exceptions and must not silently become immediate charges. ## Migration behavior: Trialing Stripe Subscriptions MoveMRR calculates trial behavior from the source subscription and project configuration. The destination subscription receives the intended remaining trial and compatible end behavior. A dry run shows whether a payment method exists and what happens when the trial ends. ## What the readiness review must verify Compatibility is established from the actual Stripe objects, not from a page title. The project should surface every missing mapping, unsupported field, ambiguous state, and destination prerequisite before the live run. - Trial end is in the future and consistent with the intended customer promise. - Destination price and interval mappings are complete. - The customer has an eligible copied payment method when automatic charging is expected. - Trial end behavior for a missing payment method is intentionally configured. ## The primary failure mode to control A missing or invalid trial date can charge a customer earlier than promised or leave the destination subscription in an unintended state. Trial records should be reconciled by date and behavior, not only by count. ## Trialing Stripe Subscriptions: source-to-destination checks | Check | Required evidence | If it fails | |---|---|---| | Trial end | Future destination date matches approved remaining trial | Exclude and review | | Payment default | Eligible method mapped or known exception | Assign owner before trial expiry | | End behavior | Cancel, pause, or invoice behavior is intentional | Correct destination configuration | | Source state | No second subscription will activate at trial end | Change source deactivation plan | ## Frequently asked questions **Will customers lose their remaining trial?** The workflow can preserve the approved remaining future trial when the source date and destination configuration are valid. **Does a trial require a payment method?** Stripe can support trials without one, but the desired behavior at trial end must be configured and monitored. **Should trialing subscriptions be migrated in the same batch as active subscriptions?** They can be, but review them as a separate cohort because trial dates, payment coverage, and end behavior create different acceptance checks. --- # Past-Due Stripe Subscriptions Canonical: https://movemrr.com/compatibility/past-due-subscriptions/ > Move reviewed past-due Stripe subscriptions without creating an immediate duplicate collection attempt or hiding existing debt. Past-due subscriptions require an explicit inclusion decision. MoveMRR can include them in a reviewed run and preserves a future billing boundary rather than forcing an immediate destination charge. The destination recreation does not erase the source invoice history, collection state, or underlying payment problem. ## Migration behavior: Past-Due Stripe Subscriptions A past-due status reflects an unpaid source invoice and active collection logic. Recreating the subscription in a new account creates a new billing object; it does not transfer the historical invoice or dunning state. The migration plan must separate subscription continuity from recovery of the existing receivable. ## What the readiness review must verify Compatibility is established from the actual Stripe objects, not from a page title. The project should surface every missing mapping, unsupported field, ambiguous state, and destination prerequisite before the live run. - The project explicitly includes past-due subscriptions. - The unpaid source invoice and collection owner are documented. - Destination creation uses a future boundary rather than an immediate charge. - Dunning, access, and support behavior are defined in the buyer’s application. ## The primary failure mode to control Treating past-due subscriptions like normal active records can trigger an unexpected destination payment attempt while the source still pursues debt, or can grant access without a clear collection policy. ## Past-Due Stripe Subscriptions: source-to-destination checks | Check | Required evidence | If it fails | |---|---|---| | Source debt | Invoice and collection owner recorded | Keep debt handling outside the migration batch | | Destination date | Future boundary approved | Block immediate creation | | Payment method | Coverage known; failure path assigned | Manual review | | Entitlement | Buyer policy for unpaid accounts tested | Do not accept application handover | ## Frequently asked questions **Does migrating a past-due subscription collect the unpaid invoice?** No. The source receivable and invoice history remain separate. Destination subscription continuity and debt recovery need distinct plans. **Can past-due records be excluded?** Yes. They should be included only when the project configuration and deal policy explicitly call for it. **Will the destination charge immediately?** The reviewed path preserves a future billing boundary for included past-due records rather than intentionally starting an immediate charge. --- # Stripe Coupons and Promotion Codes Canonical: https://movemrr.com/compatibility/coupons-and-promotion-codes/ > Preserve intended Stripe subscription discounts by mapping or recreating coupons and reviewing duration, redemption, and promotion-code behavior. Coupons and promotion codes are account-scoped Stripe objects and are not moved unchanged by Customer Data Copy. Destination coupons must be recreated or mapped with equivalent percent or amount, currency, duration, and redemption semantics. Promotion-code history and customer-facing codes require separate review. ## Migration behavior: Stripe Coupons and Promotion Codes MoveMRR can recreate and map coupon dependencies used by subscriptions. The migration must preserve the discount that applies to the future subscription, while recognizing that destination object IDs and historical redemption records differ. ## What the readiness review must verify Compatibility is established from the actual Stripe objects, not from a page title. The project should surface every missing mapping, unsupported field, ambiguous state, and destination prerequisite before the live run. - Discount type, amount or percentage, currency, duration, and end date match. - Mapped coupon belongs to the destination account and is valid for the destination price. - Promotion codes and customer-facing redemption behavior are documented separately. - The dry run shows every subscription whose discount cannot be resolved. ## The primary failure mode to control A missing or semantically different coupon changes the customer’s price. Matching only a coupon name is unsafe because amount, currency, duration, and restrictions can differ. ## Stripe Coupons and Promotion Codes: source-to-destination checks | Check | Required evidence | If it fails | |---|---|---| | Coupon value | Percent or amount and currency match | Correct mapping before live run | | Duration | Once, repeating, or forever behavior matches | Manual commercial review | | Redemption history | Retention requirement documented | Preserve source reporting separately | | Promotion code | Future redemption path intentionally rebuilt or retired | Do not imply it transferred | ## Frequently asked questions **Do Stripe coupons transfer with customers?** No. Coupons are account-scoped catalog objects and need destination recreation or mapping. **Can a forever discount remain forever?** Yes when an equivalent valid destination coupon is mapped and the destination subscription is created with the intended discount. **Are promotion-code redemptions copied?** Do not assume so. Historical redemption data and future code behavior need separate retention and rebuild decisions. --- # Multi-Item Stripe Subscriptions Canonical: https://movemrr.com/compatibility/multi-item-subscriptions/ > Migrate Stripe subscriptions with multiple recurring items only when every item has a valid destination price and compatible billing cadence. MoveMRR supports multiple recurring items when all source items have destination mappings and compatible timing. If one item is unmapped, carries account-specific tax behavior, or uses an incompatible interval, the complete subscription should be held for review rather than partially recreated. ## Migration behavior: Multi-Item Stripe Subscriptions The destination subscription is built from the complete approved item set. Atomic handling prevents a subscription from being accepted with only some of its recurring products. Quantities, currencies, intervals, taxes, and price behavior are validated at item level. ## What the readiness review must verify Compatibility is established from the actual Stripe objects, not from a page title. The project should surface every missing mapping, unsupported field, ambiguous state, and destination prerequisite before the live run. - Every recurring item has an approved destination price mapping. - Quantities and currencies match the source. - Intervals and interval counts produce one valid destination billing model. - Item-level tax rates and metadata are reviewed. ## The primary failure mode to control Partially recreating a subscription silently changes what the customer receives and pays for. A single missing mapping must block or exclude the whole subscription according to the approved policy. ## Multi-Item Stripe Subscriptions: source-to-destination checks | Check | Required evidence | If it fails | |---|---|---| | Item coverage | All recurring items map | Hold the complete subscription | | Quantity | Destination quantity matches source | Correct planned action | | Intervals | Cadence is compatible | Manual design required | | Item tax | Destination tax behavior approved | Resolve tax mapping | ## Frequently asked questions **Can a subscription with several products be migrated?** Yes when every recurring item maps to a compatible destination price and the combined billing cadence is supported. **What happens if one item is unmapped?** The safe behavior is to hold or exclude the complete subscription rather than silently creating a partial commercial contract. **Can item quantities be preserved?** Quantities can be carried into the planned destination items and should be checked in the dry-run output. --- # Stripe Tax on Migrated Subscriptions Canonical: https://movemrr.com/compatibility/stripe-tax/ > Validate automatic tax, tax behavior, registrations, customer locations, and account-specific tax rates before recreating subscriptions. MoveMRR can preserve supported subscription-level automatic-tax behavior, but the destination account must have the correct Stripe Tax configuration, registrations, product tax codes, customer locations, and compatible price tax behavior. Account-specific manual tax-rate IDs require destination review or mapping. ## Migration behavior: Stripe Tax on Migrated Subscriptions A subscription can request automatic tax, but calculation depends on destination account settings and data. The migration plan therefore checks the source flag and warns about account-specific subscription or item tax rates that cannot safely be assumed equivalent. ## What the readiness review must verify Compatibility is established from the actual Stripe objects, not from a page title. The project should surface every missing mapping, unsupported field, ambiguous state, and destination prerequisite before the live run. - Destination Stripe Tax is configured for the new legal entity and registrations. - Products and prices have the intended tax codes and inclusive/exclusive behavior. - Customer addresses or locations meet calculation requirements. - Manual subscription-level and item-level tax-rate objects have approved handling. ## The primary failure mode to control A destination subscription can be created successfully while calculating a different tax amount later. Acceptance must include a tax calculation sample, not only object creation. ## Stripe Tax on Migrated Subscriptions: source-to-destination checks | Check | Required evidence | If it fails | |---|---|---| | Automatic Tax | Destination configuration and registrations verified | Block tax-enabled records | | Price behavior | Inclusive/exclusive behavior matches | Create a correct destination price | | Customer location | Required address evidence exists | Resolve before first invoice | | Manual rates | Destination equivalent or explicit replacement | Manual tax review | ## Frequently asked questions **Does Automatic Tax stay enabled?** Supported subscription behavior can be preserved, but it only works correctly when the destination account, products, prices, registrations, and customer locations are ready. **Do manual Stripe tax rates transfer?** No account-specific object should be assumed portable. Create or approve a destination equivalent and review the resulting calculation. **Does MoveMRR determine the buyer’s tax registrations?** No. The destination business and qualified advisers must determine registrations and liability. --- # Stripe Subscription Schedules Canonical: https://movemrr.com/compatibility/subscription-schedules/ > Review current and future schedule phases, prices, discounts, dates, and source release behavior before moving scheduled subscriptions. Subscriptions attached to schedules need phase-level review. MoveMRR can identify and recreate supported schedule behavior, then release or deactivate source-side schedule control as configured. Every future phase must have valid destination prices, dates, discounts, and behavior; unsupported phase data should stop automatic acceptance. ## Migration behavior: Stripe Subscription Schedules A Stripe Subscription Schedule can encode future catalog, quantity, discount, tax, and timing changes. The destination plan must preserve the approved phase sequence rather than flattening the subscription to its current state. Source schedule release and subscription deactivation must be ordered carefully. ## What the readiness review must verify Compatibility is established from the actual Stripe objects, not from a page title. The project should surface every missing mapping, unsupported field, ambiguous state, and destination prerequisite before the live run. - Every current and future phase is present in the inventory. - All phase prices, quantities, coupons, taxes, and dates have destination equivalents. - End behavior and phase transitions match the intended contract. - Source schedule release/deactivation cannot create a second active billing path. ## The primary failure mode to control Creating only the current subscription state discards contracted future changes. Releasing or canceling the source schedule in the wrong order can also leave the source subscription active or change its behavior. ## Stripe Subscription Schedules: source-to-destination checks | Check | Required evidence | If it fails | |---|---|---| | Phase coverage | All future phases mapped | Hold schedule for review | | Dates | Destination sequence matches approved timeline | Correct phase configuration | | End behavior | Release/cancel behavior is intentional | Manual decision | | Source control | No competing source schedule remains | Block completion | ## Frequently asked questions **Can subscriptions with future price changes be migrated?** They can be reviewed when those changes are represented in schedule phases and every destination dependency is mapped. **What if a schedule has an unsupported phase field?** The record should be held for manual review rather than silently flattening or dropping the field. **Does Stripe’s Toolkit use schedules?** Stripe documents that its Billing Migration Toolkit uses Subscription Schedules and holds scheduled subscriptions before they go live. --- # Metered and Usage-Based Stripe Billing Canonical: https://movemrr.com/compatibility/metered-billing/ > Plan the migration of usage-based subscriptions by separating subscription configuration from accumulated usage and billing-meter state. Usage-based subscriptions require manual review because creating the destination subscription does not automatically move accumulated usage, meter events, aggregation windows, or application-side reporting state. Map the recurring price and billing configuration, choose a precise usage cutover boundary, route new events to the destination, and reconcile any source usage that still needs invoicing. ## Migration behavior: Metered and Usage-Based Stripe Billing MoveMRR can inventory and map recurring subscription dependencies, but metered billing couples Stripe to an event pipeline and an accumulation window. The safe migration unit is therefore not only a subscription object: it includes the last accepted source event, first destination event, aggregation period, pending invoice items, and replay or deduplication behavior. ## What the readiness review must verify Compatibility is established from the actual Stripe objects, not from a page title. The project should surface every missing mapping, unsupported field, ambiguous state, and destination prerequisite before the live run. - Source and destination metered price or billing-meter semantics match. - A cutover timestamp and event-routing switch are defined. - Pending source usage and invoice-item intervals have an explicit settlement plan. - Event IDs and application retries cannot duplicate usage across accounts. ## The primary failure mode to control Routing the same usage to both accounts double-bills; routing it to neither loses revenue. Copying a subscription without transferring or settling accumulated usage creates a hidden reconciliation gap. ## Metered and Usage-Based Stripe Billing: source-to-destination checks | Check | Required evidence | If it fails | |---|---|---| | Meter definition | Aggregation and dimensions match | Redesign destination meter | | Cutover boundary | Last source and first destination event recorded | Do not start live routing | | Pending usage | Invoice or transfer policy approved | Keep source billing open | | Idempotency | Replay cannot duplicate events | Add event-level deduplication | ## Frequently asked questions **Does subscription migration move accumulated usage?** Do not assume it does. Usage events, aggregation state, and pending source invoices require a separate cutover and reconciliation plan. **Can the metered subscription itself be recreated?** The recurring configuration can be mapped when the destination pricing model is ready, but the usage pipeline must be validated separately. **How do I prevent duplicate usage charges?** Define an exact event boundary, switch routing atomically, retain event IDs, and reconcile the last source and first destination periods. --- # Stripe Webhook Endpoints Canonical: https://movemrr.com/compatibility/stripe-webhook-endpoints/ > Recreate the source account’s Stripe webhook endpoints on the destination during a migration, and plan for the new signing secret that every newly created endpoint receives. Webhook endpoints belong to a single Stripe account, so a destination account starts with none and neither Customer Data Copy nor a subscription import creates them. MoveMRR can recreate the source account’s enabled endpoints on the destination as an opt-in step of the live run, copying the URL, subscribed events, API version, description, and metadata. Stripe never releases an existing signing secret, so every newly created endpoint receives a fresh whsec_ that must be re-deployed to the consumers behind that URL before events are trusted again. ## Migration behavior: Stripe Webhook Endpoints When “Migrate Stripe webhook endpoints” is enabled on the project, the live run lists the endpoints on both accounts and recreates each enabled source endpoint the destination does not already cover, copying url, enabled_events, api_version, description, and metadata, and stamping a movemrr_source_webhook_id back-reference on the new object. Where the destination already has an endpoint at the same URL that covers only part of the source events, that endpoint’s event list is widened instead of creating a duplicate, so it keeps its existing signing secret and no event is delivered twice. Endpoints the seller had disabled are skipped rather than silently re-enabled on the buyer’s account, and matching is on the exact URL string—there is no domain rewriting, so an endpoint that should point at new infrastructure must be created there deliberately. ## What the readiness review must verify Compatibility is established from the actual Stripe objects, not from a page title. The project should surface every missing mapping, unsupported field, ambiguous state, and destination prerequisite before the live run. - Both Stripe keys carry the extra webhook permission: read on the source key, write on the destination key. - Every source endpoint URL is one the destination team actually controls and can deploy to. - The consumers behind each newly created endpoint can be given a new signing secret at cutover. - Existing destination endpoints are reviewed, because a same-URL endpoint has its event list widened rather than duplicated. ## The primary failure mode to control Signature verification failing after the cutover. Stripe issues a new whsec_ for every endpoint that is created, and a consumer still validating against the old secret rejects every delivery. The run’s Webhooks tab separates created, updated, skipped, and failed endpoints and names exactly which ones need the new secret, which is read from the destination Stripe dashboard—MoveMRR never receives or stores the secret value. ## Stripe Webhook Endpoints: source-to-destination checks | Check | Required evidence | If it fails | |---|---|---| | Key permissions | Webhook read on the source key and webhook write on the destination key | Key validation fails; regenerate the restricted key with the added scope | | Endpoint coverage | The pre-run check lists every enabled source URL as covered or missing | Enable the option or recreate the endpoints manually before cutover | | Signing secrets | Each created endpoint has an owner who will deploy its new whsec_ | Events are rejected by signature verification until the secret is deployed | | Post-run diff | The reconciliation report reports covered rather than partial or missing | Add the missing events on the destination endpoint and re-verify | ## Frequently asked questions **Can the webhook signing secret be migrated with the endpoint?** No, and no tool can do it. Stripe returns a signing secret exactly once, when an endpoint is created, and never discloses it again. Endpoints MoveMRR creates on the destination therefore have a new whsec_ that you read from the destination Stripe dashboard and deploy to your consumers. Endpoints that were merely widened keep the secret they already had. **What happens if the destination already has an endpoint at the same URL?** It is not duplicated. If the existing endpoint already covers all the source events, the source endpoint is skipped. If it covers only some of them, MoveMRR updates that endpoint with the union of both event lists, which preserves its signing secret and avoids delivering the same event twice. **Are disabled webhook endpoints recreated too?** No. An endpoint the seller had disabled is reported as skipped rather than recreated, because re-enabling it on the buyer’s account would resume deliveries the seller had deliberately stopped. Recreate it manually if the buyer wants it active. **Can I rehearse this before the live cutover?** Yes, in a sandbox project, which is free and unlimited. Note that sandbox seeding does not copy webhook endpoints into a sandbox, so create a couple of endpoints in the source sandbox by hand first; the run then exercises the same copy logic in Stripe test mode. --- # 76,300+ Subscriptions Across Three SaaS Acquisitions Canonical: https://movemrr.com/customers/three-acquisitions-76300-subscriptions/ > How an acquirer used MoveMRR to migrate more than 76,300 active subscriptions and $500k+ MRR across three acquired SaaS businesses. Dim Vladimirov used MoveMRR across three SaaS acquisitions to migrate more than 76,300 active subscriptions representing over $500,000 in monthly recurring revenue. The largest single run contained 46,000 subscriptions. The engagement combined MoveMRR’s workflow with hands-on support and custom features for the specific migration shapes. ## The starting situation The acquirer needed to receive live recurring billing from three businesses at a scale where a one-off script, incomplete testing, or manual review of every record would create substantial delivery and revenue risk. The project also required responsive support and features specific to the acquired billing setups. ## How the migration was controlled The teams used MoveMRR as the repeatable control plane for account setup, mappings, planned actions, execution, and audit evidence. Hands-on guidance and scoped product improvements were used where the source shapes required more than the standard path. Each business remained its own migration decision rather than being treated as one undifferentiated batch. ## The customer-reported outcome The three migrations completed with more than 76,300 active subscriptions moved and over $500k MRR represented. The customer specifically reported timely execution, transparent support, meaningful savings versus custom development and testing, and smooth handling of every migration. ## Migration evidence | Area | Before or risk | Documented control or reported outcome | |---|---|---| | Scale | Three acquired subscription businesses | 76.3k+ subscriptions completed | | Largest run | High-volume live billing change | 46k subscriptions in one run | | Commercial exposure | More than $500k MRR | Controlled project and audit evidence | | Delivery | Custom needs across several businesses | Hands-on support and scoped features | ## Frequently asked questions **Can MoveMRR handle tens of thousands of subscriptions?** This customer’s largest completed single run contained 46,000 subscriptions, with 76,300+ moved across three acquisitions. **Was this a self-service-only project?** No. The customer describes hands-on support and custom features for the specific needs of the migrations. **Does this prove every large migration is compatible?** No. Large projects still require account-specific inventory, representative rehearsal, exception review, capacity planning, and Stripe approval. --- # Baked.Design: 560+ Customers with Legacy Stripe Prices Canonical: https://movemrr.com/customers/baked-design/ > How Baked.Design migrated 560+ active customers, products, prices, coupons, and subscriptions despite archived legacy Stripe prices. Baked.Design used MoveMRR to migrate more than 560 active customers with products, prices, coupons, and subscriptions. Archived legacy prices could not all be recreated automatically, so the missing destination prices were created and mapped before the workflow continued. The live migration then recreated the approved subscriptions without overlapping billing. ## The starting situation The source account contained a large product and price catalog, including older archived Stripe prices, plus coupons and customers copied through Stripe. An automatic “copy everything” assumption would have left gaps because archived source prices do not automatically become usable destination prices. ## How the migration was controlled MoveMRR recreated the supported catalog, surfaced incomplete price coverage, and allowed the missing destination prices to be created and mapped deliberately. Stripe’s official customer mapping output was then uploaded, followed by a dry run and readiness validation. The live workflow created destination subscriptions before the configured source cancellation behavior. ## The customer-reported outcome More than 560 active customers and their approved subscription shapes were migrated. The customer reported that the process was structured, transparent, and easy to follow, with step-by-step guidance and no customer-visible billing disruption. ## Migration evidence | Area | Before or risk | Documented control or reported outcome | |---|---|---| | Catalog | Large product and price set | Destination catalog recreated and mapped | | Legacy prices | Archived records blocked automatic recreation | Missing prices created and mapped manually | | Discounts | Coupon dependencies | Coupons included in reviewed mapping | | Cutover | Double-billing exposure | Destination creation preceded source cancellation | ## Frequently asked questions **Can archived Stripe prices be migrated?** They may not be automatically recreatable. In this case, missing destination prices were created deliberately, mapped in MoveMRR, and reviewed before continuing. **Were coupons included?** Yes. The customer’s migration included products, prices, coupons, customer mapping, and active subscription recreation. **Did customers notice the account move?** The customer reported that customers did not notice a billing disruption during the completed migration. --- # The AMPscript Guide: 600+ Subscriptions in Under 30 Minutes Canonical: https://movemrr.com/customers/ampscript-guide/ > How The AMPscript Guide migrated more than 600 active Stripe subscriptions representing roughly $4k+ MRR in under 30 minutes. The AMPscript Guide used MoveMRR to migrate more than 600 active subscriptions representing roughly $4,000+ in MRR. The live run completed in under 30 minutes. The customer reported correct handling of legacy price IDs, billing cycles, customer and subscription ID changes, with zero downtime and zero double billing. ## The starting situation The account combined hundreds of active customers with legacy Stripe data and changed identifiers. Manual recreation would have required extensive engineering and created risk around renewal dates, application mappings, downtime, and duplicate billing. ## How the migration was controlled The project mapped source and destination prices and customers, reviewed planned subscription creation, preserved active billing alignment, and captured new customer and subscription identifiers. The live run used the approved migration configuration and audit workflow. ## The customer-reported outcome The live migration completed in less than 30 minutes. The customer reported zero downtime, zero double billing, correct billing-cycle behavior, and expected renewals after the move. ## Migration evidence | Area | Before or risk | Documented control or reported outcome | |---|---|---| | Subscriptions | 600+ live records | Completed live run | | MRR | Approximately $4k+ represented | Billing continuity reported | | Legacy data | Old price and object identifiers | Mapped to destination objects | | Execution | Manual path estimated in weeks | Completed in under 30 minutes | ## Frequently asked questions **How long did the live migration take?** The customer reported that the live run for more than 600 active subscriptions finished in under 30 minutes. **Were Stripe IDs changed?** Yes. Destination objects have new identifiers; the migration handled the customer and subscription ID changes and mappings required for the handover. **Was there double billing?** The customer reported zero double billing and expected renewal behavior for this completed migration. --- # own.page: Cross-Country Stripe Account Migration Canonical: https://movemrr.com/customers/own-page-cross-border/ > How own.page moved 30+ active Stripe subscribers and $230+ MRR to a new account during a company move to another country. own.page used MoveMRR during a company move to another country, migrating more than 30 active subscribers representing over $230 MRR. The founder reported completing the Stripe settings, products, customer, and subscription workflow in under an hour and that customers did not notice the change. ## The starting situation Changing company country required a different Stripe account and raised the risk that active customers would need to re-enter information or experience billing interruption. The founder needed a guided workflow rather than a bespoke migration project. ## How the migration was controlled The destination account and catalog were prepared, eligible customers were handled through Stripe’s official process, and active subscription recreation followed MoveMRR’s step-by-step workflow. The small volume still required the same mapping and cutover discipline as a larger move. ## The customer-reported outcome More than 30 subscribers and over $230 MRR were moved. The founder reported that the full process took under an hour and that customers did not notice the account transition. ## Migration evidence | Area | Before or risk | Documented control or reported outcome | |---|---|---| | Reason | Company moved to another country | New Stripe account prepared | | Customers | Risk of re-entry or disruption | Founder reported no customer-visible change | | Scope | Settings, products, customers, subscriptions | Guided step-by-step completion | | Time | Expected painful manual move | Reported under one hour | ## Frequently asked questions **Did customers re-enter their payment details?** The founder reported that customers did not notice the change. Eligibility for another account pair must still be confirmed through Stripe. **How many subscribers were moved?** The completed project covered more than 30 active subscribers and over $230 in monthly recurring revenue. **Can MoveMRR move any Stripe account to any country?** No. Stripe controls destination-country availability and whether customer and payment data can be copied between a specific account pair.