Ask a software leader whether their current payments setup is working and you will often get a long pause. The fees are hard to read. The merchant experience lives on someone else’s screens. The revenue never quite reflects the volume running through the product. And yet the same leader will tell you that switching is not on this year’s roadmap.
The reason is rarely the economics. It is fear. Fear that merchants will have to reapply, that stored cards will stop working, that recurring billing will break overnight, and that the support queue will fill with calls the team is not staffed to answer. So the migration everyone agrees should happen keeps sliding to next year.
Those risks are real, but they are manageable. This guide walks through what actually moves in a processor migration, where the genuine risk sits, and how to run a phased plan that keeps merchants processing the whole way through.
The short answer
Plan the migration around your merchants, not your processor. Secure your card data before you commit to anything, move merchants in waves rather than all at once, run old and new rails in parallel until each wave is stable, and make sure your software company, not either processor, is the voice merchants hear from. Done this way, most merchants notice little beyond a better experience.
Why software companies put off migration
Five worries come up in almost every conversation:
- Re-papering merchants. New merchant agreements and, in some cases, fresh underwriting can feel like asking every customer to apply all over again.
- Card data portability. If stored cards cannot move, every recurring customer has to re-enter payment details, and some never will.
- Engineering bandwidth. Payment integrations have a reputation for long, unpredictable builds that pull developers off the core roadmap.
- Revenue disruption. Any gap in processing, even a short one, hits merchant cash flow and the platform’s own payments revenue at the same time.
- Contract terms. Notice periods, early termination fees, and data export clauses in the existing agreement can shape the timeline more than any technical step.
Each one is a planning problem, not a reason to stay put. The rest of this guide takes them in order.
What actually moves in a processor migration
Migration is not one event. It is several workstreams that happen to share a cutover.
Component | What moves | Where the risk sits |
Merchant accounts | Boarding records, agreements, underwriting files | Re-signing friction and approval timing |
Stored card credentials | Card data and the tokens that reference it | Recurring payments failing after cutover |
Recurring schedules | Billing plans, dates, amounts, retry logic | Missed or duplicate charges |
Hardware | Terminals and card readers | Devices that need reprogramming or replacement |
Reporting and reconciliation | Deposit records, fee reports, historical data | Gaps in history that finance teams rely on |
Payouts | Settlement accounts and funding timing | Merchants noticing a change in deposit timing |
Treating each row as its own workstream, with its own owner, is what keeps a migration from turning into one large, risky event.
The card data question
For any platform with recurring billing or stored cards, this is the part that decides whether revenue survives the move.
Most processors store card numbers in their own secure vault and give your software a token to reference each card. That token generally works with the processor that issued it and nowhere else. So when you switch, the tokens in your database do not travel on their own. What needs to move is the underlying card data, from the old processor’s vault to the new one, where fresh tokens are issued and mapped back to your customer records.
Card data transfers between processors are an established practice. They typically run as an encrypted file exchange between PCI-compliant providers, under the controls the PCI Data Security Standard sets for handling cardholder data. The harder questions tend to be contractual: whether your current agreement obliges the processor to release the data, how long the export takes, and who pays for it.
A few steps protect you here:
- Read the data export clause first. Know what your current processor must provide, in what format, and on what timeline, before you announce anything.
- Request a test export early. A sample file surfaces format and mapping issues long before they would otherwise appear.
- Plan for network tokens. If you use network tokens, confirm how they will be provisioned under the new processor so card updates keep flowing.
- Keep your own PCI scope small. Card data should move processor to processor, never through your own systems. Our guide to PCI scope for software platforms explains why that matters.
Get this right and recurring customers never know a migration happened. Get it wrong and it shows up as failed payments and silent churn within weeks.
A phased migration plan
A big-bang cutover puts every merchant at risk on the same day. A phased plan spreads that risk and lets each wave teach the next.
Phase 1: Prepare
Map every merchant, payment method, and integration point, including each recurring billing schedule. Review contract terms and the card data export process. Agree on success measures for each wave, such as approval rates, settlement accuracy, and support ticket volume.
Phase 2: Pilot
Choose a small group of merchants who process steadily, have a good relationship with your team, and represent your typical setup. Move them first and watch closely. If approval rates dip, the decline codes will usually tell you why. Fix what you learn before anyone else moves.
Phase 3: Run in parallel
Keep the old processor live while the new one handles the pilot. Reconcile deposits, fees, and recurring charges side by side until the numbers match.
Phase 4: Migrate in waves
Move the rest of the base in groups by vertical, region, volume, or product version, whichever keeps each wave consistent. Hold your highest-volume and most complex merchants until the process is proven.
Phase 5: Cut over and decommission
Once the final wave is stable, switch off the old integration, confirm the last settlements have cleared, and archive the historical reporting your finance team and merchants will still need.
Keeping merchants on side
The biggest migration risk is not technical. It is a merchant who hears about the change from the wrong person, at the wrong time, with the wrong message.
- Your software company leads the communication. Merchants chose your product, not a processor. They should hear about the change from you, in your voice, through the product and channels they already use.
- Lead with the benefit, then the logistics. Start with what improves for them, then explain what, if anything, they need to do.
- Minimize what merchants have to do. Every form, signature, or re-entered detail is a reason to delay. Pre-fill what you can and keep action items short.
- Give support teams a script. Front-line staff should know the timeline, the answers to the most common questions, and when to escalate.
- Flag deposit changes in advance. If funding timing or statement descriptors change, say so ahead of time. Unexpected changes to deposits generate more anxious calls than anything else.
This is also where a real partnership, rather than a vendor relationship, earns its keep. A partner that works through merchant communication with you, instead of leaving you to handle it alone, makes this part far easier.
What a good migration partner should take off your plate
The right partner turns migration from a project your team carries into one your team oversees. Look for:
- Clear documentation and developer tooling, so the integration does not depend on weeks of back and forth.
- Hands-on implementation support with named contacts, not a ticket queue.
- A structured process with a clear timeline, so there are no late surprises.
- Ownership of the card data transfer with your current processor.
- Underwriting and onboarding handled behind the scenes, so merchants see as little paperwork as possible.
Here is what that can look like in practice. When Total Service, a field service ERP for elevator and HVAC contractors, moved its payments from a third-party processor to a partner inside the Constellation ecosystem, a single developer completed the integration with under two hours of hands-on implementation time. The team rated the migration experience 10 out of 10.
With a PayFac as a Service model, the partner also carries the ongoing underwriting, compliance, and risk work after cutover, so the migration is the last heavy lift rather than the first of many.
Questions to ask before you migrate
- What does our current contract say about notice periods, termination fees, and card data export?
- How many merchants rely on stored cards or recurring billing, and how will that data move?
- Which merchants make the best pilot group, and what does success look like for them?
- Who owns merchant communication, and what will merchants actually need to do?
- How much engineering time will the integration really take, and what support comes with it?
If the answers are clear, you are ready to plan. If they are not, those are the first conversations to have, both with your current provider and with any partner you are considering. Our buyer’s guide to payment gateway selection covers the evaluation side in more depth.
Frequently asked questions
How long does it take to switch payment processors?
It depends on merchant count, payment methods, and contract terms. Integration work can move quickly with good documentation and support, while card data transfer and merchant onboarding usually set the overall pace. A phased plan typically runs over several weeks to a few months.
Will my merchants’ stored cards still work after a migration?
They can, as long as the underlying card data is transferred securely from the old processor to the new one and re-tokenized. Tokens issued by one processor generally do not work with another, so the transfer needs to be planned well before cutover.
Do merchants need to reapply when a software platform changes processors?
Merchants often sign new agreements, and some may go through updated underwriting. A good partner keeps this light by pre-filling information and handling review behind the scenes.
Can we migrate merchants gradually instead of all at once?
Yes, and it is usually the safer approach. Running both processors in parallel and moving merchants in waves limits risk and lets each wave improve the next.
Who should tell merchants about a processor change?
The software company. Merchants have a relationship with your product, so the message should come from you, lead with the benefit, and keep any required action simple.
Start the conversation
If your operating company is part of Constellation Software or Jonas and a processor migration keeps sliding down the roadmap, the CSIPay team at Constellation Payments is happy to talk it through. No pitch required, just a practical look at what you run today, what would need to move, and what a phased plan could look like. Reach us at [email protected] or through our contact page.