Stripe Subscription Migration Checklist for SaaS Acquisitions
Use this Stripe subscription migration checklist before a SaaS acquisition handover to protect MRR, avoid churn, and reduce engineering risk.
Stripe subscription migration should be planned before the acquisition handover date, not after contracts are signed. The migration affects live revenue, customer trust, support load, and engineering capacity. A structured checklist makes the migration observable before anyone touches production billing data.
Account and access readiness
Confirm which Stripe account currently owns the subscriptions and which account will collect future renewals. The seller should provide scoped access that is sufficient for reading customers, payment methods, subscriptions, products, prices, discounts, and invoices. The buyer should provide scoped access for creating customers, attaching payment methods, and creating subscriptions.
Avoid using unrestricted secret keys for a migration project. Restricted API keys reduce blast radius and make it easier to reason about what the migration engine can and cannot do.
Customer mapping
Create a source-to-destination customer mapping file before subscription creation begins. The mapping should be deterministic and reviewable. If the buyer already has customers in their Stripe account, avoid matching by email alone. Emails can change, collide, or represent billing aliases rather than the actual account owner.
For each customer, track the source customer ID, destination customer ID, payment method match status, and review status. This gives the team a clear list of subscriptions that can move automatically and subscriptions that require human attention.
Subscription shape
Inventory every active subscription and trialing subscription. Capture products, prices, quantities, billing cycle anchors, trial ends, collection method, cancelation behavior, coupons, tax behavior, and current period boundaries. The buyer-side subscription should preserve the economic agreement the customer already has.
Coupon handling deserves special care. If a customer has three months left on a six-month discount, resetting the full coupon duration can leak revenue, while dropping the discount can create a support issue.
Execution controls
Use a dry run before live execution. The dry run should produce counts for eligible subscriptions, blocked subscriptions, unmatched payment methods, unsupported pricing cases, and estimated revenue at risk.
During execution, use idempotent mutation keys, rate-limit-aware workers, and clear retry behavior. The migration should never create duplicate buyer-side subscriptions because a request timed out, a worker restarted, or a webhook sequence arrived out of order.
Post-migration audit
After execution, compare source and destination subscription states. Every migrated subscription should have a destination subscription ID, a buyer-scoped payment method, a cancellation plan for the seller subscription, and an audit timestamp.
RevBridge packages these checks into a repeatable migration flow so acquisition teams can protect MRR without asking engineers to write one-off Stripe scripts.