The decision has been made, now the hard part
Maybe your current provider is changing its terms, winding down a product, or cannot support a feature you need. Maybe a new partner offers something you cannot get today. The commercial side is signed. Now engineering has to move accounts, payment flows, perhaps cards, and all the customer data that goes with them, while customers keep using the app.
The first technical look is not encouraging. The old provider's field names are in your database tables. Its statuses are used in your app screens. Its reference format is assumed in the reconciliation spreadsheet. Its webhooks drive half your notifications.
Where the difficulty really is
Moving data is the visible task. The harder parts are the assumptions nobody wrote down.
- Your internal model is really the old provider's model with your names on it.
- The two providers do not have the same statuses, so a straight mapping loses meaning.
- Some customers have in-flight payments, scheduled payments or standing instructions at the moment of cutover.
- Account details or card numbers may change, which affects the customer and anyone who pays them.
- Reconciliation, reporting and support tools all read the old provider's data.
What a rough migration costs
A big-bang switch that goes wrong hits every customer at once: failed payments, wrong balances, cards that do not work. Support is overwhelmed. Your old and new partners both want to know what happened. Even a migration that mostly works leaves a long tail of odd cases that ops clean up for months.
The contractual and regulatory side of moving customers between providers is for your team, your partners and your advisers. Our part is the engineering and the operational tooling around it.
A staged move we plan and build
What we build lets both providers run at once, so customers can move in small groups and each step can be checked.
- We map every place the old provider touches: calls, webhooks, stored fields, reports, and support and ops tools.
- We introduce a provider-neutral layer in your product with your own statuses and references, and move the old provider behind it first, so nothing changes for customers yet.
- We build the new provider's adapter against the same layer and test it in the new provider's sandbox with your real flows.
- Each customer gets a provider flag, so the product knows which provider to use for them.
- Customers move in cohorts, starting with internal staff accounts, then small groups, with in-flight payments allowed to finish on the old provider.
- A reconciliation runs across both providers for every cohort, so balances and payments are checked before the next group moves.
- Ops and support tools read through the layer, so they work for both providers throughout.
| Stage | Who is on the new provider | What we check |
|---|---|---|
| Wrap the old provider | Nobody | Behaviour unchanged, all tests pass |
| Staff accounts | Your own team | Every flow end to end |
| First small cohort | A group you choose | Balances, payments, notifications, support tools |
| Larger cohorts | Growing groups | Reconciliation clean before each step |
| Wind down | Everyone | Old provider balances cleared and reconciled |
How the move feels from the inside
Customers move quietly in batches. Each batch has a clear go or wait decision based on the reconciliation. Support sees which provider a customer is on and gets tailored reply templates for the few changes customers notice, such as new account details.
When the last cohort is across, the provider-neutral layer stays. Adding a second partner later, or moving again, is a much smaller job.
Is this where you are?
- You are moving provider or seriously considering it.
- The current provider's names and statuses appear throughout your code.
- Nobody is sure how in-flight payments will be handled at cutover.
- Your ops and support tools read directly from the old provider.
- The plan so far is a single switch-over weekend.