> Data portability is a solved problem in this space - so there isn't a material risk of churn due to a migration like this.
Here's my anecdote of a different situation but with some similarities, where we couldn't get the data portability we wanted.
A few years ago I asked our Direct Debit provider if we could migrate customer subscriptions from our old business entity to our newly incorporated company version of the exact same business.
The old business entity was to be wound up as a complete transfer to the new one, the trading name was identical (transferred along with trademarks), and we were happy to keep the same DD provider.
The answer we got was no, each customer would have to enter their bank details and agree to the same terms again. From the customer's point of view, they probably wouldn't even notice it was a different business, because in a real sense it wasn't.
We decided this would lead to significant churn in customer subscriptions, and we couldn't afford it. It would be cheaper to maintain and administer the old business entity, for no business purpose whatsoever, just the sole purpose of continuing to receive the DD subscriptions, and pay them immediately in full to the new business entity.
We wanted to move ~300 credit card details from SagePay to Stripe. SagePay had a minimum admin fee of 2000GBP in order to do this, and no amount of negotiation could shift it.
If anyone's had a better deal from SagePay - let me know.
This is fantastic thank you; I thought our customer card data was effectively held hostage in Stripe so the only way to move customers to a new system was to wait until their credit cards expired and were updated.
We're planning to migrate away from Stripe after this latest in a line of price increases.
Data portability is a solved problem in this space - so there isn't a material risk of churn due to a migration like this.
We recently went through the process and it was very easy.
[1] - https://stripe.com/docs/security/data-migrations/exports