Small deal, about $1.4k MRR across 90 active subscriptions, mostly monthly with a handful of annuals. The buyer's assumption is that the payment account comes with it and the subscriptions just keep running.
I do not think that is how it works but I do not know enough to say so with a straight face. What actually happens in one of these?
Do not hand over a payment account in your name. It is your tax identity - payouts, 1099s or the local equivalent, and liability for anything processed on it. If the buyer later runs something the network does not like, that history has your name attached and you will be the one having the conversation. Asset sale plus migration, every time, even when it is more work.
Price the migration risk into the deal explicitly. Cards that copy across keep working, but anyone who has to re-enter payment details will churn at a rate well above your normal - I would model 10 to 20 percent of anyone who needs a manual action to be gone.
The clean way to handle it is a holdback: some portion of the price released 60 days after cutover, tied to retained MRR. Buyers like it because it derisks them, and it stops you being blamed for the churn that migration always causes.
Holdbacks are standard and reasonable, but negotiate what counts as retained before you sign, not after. 'Retained MRR' is ambiguous enough to argue about - does a customer who downgrades count, does an annual that renews on day 61 count, who owns the churn caused by the buyer raising prices in week three. One paragraph of definitions saves a genuinely miserable email thread later.
Email every customer before the cutover, not after. A charge with an unfamiliar statement descriptor and no warning is a dispute generator, and disputes during a migration land on whichever account processed the charge, which is now the buyer's problem and immediately your reputation problem.
Write the migration runbook before diligence, not after. Buyers pay more for a deal they can already see landing, and the exercise will also tell you which parts of your own billing you never really understood.
@stipend_sam · 7mo ago · 3 replies
Your instinct is right. The account is tied to your legal entity, your identity verification and your tax details - either the buyer acquires the entity (which drags in every other liability you have), or you do an asset sale and migrate the data.
What migration actually means: there is a supported path for copying the sensitive card data between accounts - customers, cards, payment methods, bank accounts - and it preserves the customer ids, which is a bigger deal than it sounds because it means the buyer's database can keep referencing the same ids. What it does not copy is charges, invoices, subscriptions, products, prices, coupons or events. Subscriptions have to be recreated on the new account from your own records, and anything that is past due cannot be recreated cleanly because you cannot create a subscription whose billing date is in the past.
So the runbook is: copy the payment data, recreate products and prices, recreate subscriptions with the correct next billing dates, repoint webhooks, and reconcile line by line.
Reply
Report
@two_hills_up · 7mo ago
Schedule the cutover on the day of the month with the fewest renewals and freeze new signups for 24 hours around it. The copy is not the messy part. The messy part is the accounts that renew during the window and get billed twice or not at all, and every one of those is an email you have to write personally.
Reply
Report
@resole_ruth · 7mo ago
Budget lead time as well. It is not always an instant self-serve button, and both accounts have to be set up and agreeing to it. Start that conversation with the processor before you sign anything with a closing date in it, because a deal that has to close on the 30th and a migration that needs approvals is how people end up doing something stupid.
Reply
Report