White-Label Payment Platform Migration: Zero-Downtime Guide

Migrating a payment platform without downtime depends on careful planning, not luck. Zero-downtime migration here means the existing integration keeps processing until each merchant switches, and if problems arise, traffic can be routed back to the previous platform. This process is influenced by three main points: how prepared your data is, whether stored cards and tokens can be moved, and how well you communicate with merchants before making any changes.

This guide is for PSPs and payment companies planning a payment gateway migration with active merchants, as well as for merchants switching payment providers. Here, you’ll find what gets moved, who is responsible for each part, and the checks that make sure you can reverse the migration if needed.

Should you migrate — or add a second provider?

Choose migration when the existing platform itself is slowing you down. This could mean you have an old system where every change affects everything, the original developers are gone, the documentation is outdated, or your current vendor is no longer keeping up with your needs. These are structural problems. Adding another integration on top just means you’ll have two systems to manage instead of one.

If your platform still works well, you can add a second provider to cover the narrower gap. This could be due to a missing payment method, because you do not serve a particular region, as a backup route in case your main acquirer fails, or because of more favorable pricing in a given market.

There’s a simple test to help you decide: If you need to create the same workarounds with a new integration, then the platform itself is the real issue. If the new integration fixes the problem easily, you don’t need a full migration.

Read the complete guide to white-label payment gateways to learn more about how they work.

What a payment platform migration involves

How much actually moves depends on what you’re doing. A simple provider switch and a full platform migration with a live merchant portfolio face different scopes and different timelines, and in the second case, most of the work sits on the vendor’s side rather than with the merchants.

Discovery comes first

Before coming up with a plan, the vendor gathers from the client their list of providers, their list of flows, and their list of data to be migrated. The plan is then created on the basis of this information, taking into account whether the flows are recurring or non-recurring, whether the data in question is plain data or third-party tokens, and what kind of encryption is required at each step.

Merchant records

Not every migration needs full KYC/KYB records moved. In some cases it is enough to bulk-create keys that merchants then use on the new platform. Which of the two applies is decided during discovery.

Stored cards and tokens

Whether stored cards and tokens can move depends on the token type. The details, including vault ownership and PCI DSS roles, are in “Migrating stored card data and tokens without breaking recurring payments” below.

Integrations

If the new vendor supports protocol emulation, merchants can switch without rebuilding their integration. Akurateco does this by substituting its own endpoint and translating the old protocol’s parameters into its own. The merchant changes an endpoint and keeps the same connection and tokens.

Simple provider switch vs. full platform with a merchant portfolio

The zero-downtime migration checklist

A migration is a planned operation: every step is agreed before anything moves, and nothing goes live until the step before it has been checked. Each phase in the payment gateway migration checklist below lists who does the work, what has to be in place before it starts, how you know it worked, and what happens if it doesn’t.

Phase 1 — Discovery

Owner: vendor, based on information the client provides

Validation: the list of providers, the list of flows, and the list of data to be migrated are complete

Rollback: nothing is live yet

Phase 2 — Migration plan and role split

Owner: vendor

Entry gate: discovery complete

Validation: the plan states what moves, in which steps, and with what encryption at each step

Rollback: nothing is live yet

The plan fixes the depth of the data migration and the split of roles, both of which follow from the flows found in discovery.

Phase 3 — Stored cards and token migration

Owner: depends on the flow; where tokens sit with the previous provider, their documented procedure defines the split

Entry gate: plan agreed; the MID data the tokens were created under confirmed as transferable where acquirer tokens are involved; the storage model decided

Validation: tokens mapped so the merchant can use them on the new platform; billing schedules configured where recurring charges need a set billing cycle

Rollback: errors in the transfer are investigated and fixed, and the migration is completed; the tokens and entities remain in the previous system unless the client has asked for them to be deleted

Tokens are transferred from the previous provider and mapped on the new platform.

Phase 4 — Integration

Owner: merchants, or vendor where protocol emulation applies

Entry gate: plan agreed; integration does not wait for token migration

Validation: general connectivity between the merchant’s system and the platform is tested first, then the merchant tests with tokens

Rollback: the existing integration stays live until cutover

Merchants either integrate with the new platform themselves, or keep their existing connection while the vendor emulates the old protocol.

Phase 5 — Merchant-by-merchant cutover

Owner: merchants, with vendor assist

Entry gate: both tests passed and confirmed by the merchant

Validation: the merchant’s live traffic processes correctly after the switch

Rollback: see Phase 6

Merchants go live one at a time, in full or with part of their traffic first.

Phase 6 — Post-launch monitoring

Owner: vendor

Entry gate: first merchant live

Validation: migrated streams running without problems

Rollback: stream with a problem that can’t be fixed in place is switched off, and its traffic routed back to the other platform; the vendor fixes it before switching it on again

Live streams are watched as they come up. Minor issues are fixed in place with the stream left running. If the problem is larger, the traffic goes back to the other platform until it is resolved.

Migrating stored card data and tokens without breaking recurring payments

Recurring payments run on stored tokens, so whether they survive a migration comes down to what kind of token is behind them and what has to move alongside it.

What can be migrated, and what it depends on

Acquirer tokens can only be migrated if the MID data moves with them. The token is encrypted with the acquirer’s keys and tied to a specific MID, and for recurring payments it also references the initial recurring transaction. What has to move is the whole batch of data around the token, including the MID data the tokens were created under.

Customer tokens can also be migrated. The previous provider hands over the payer identifier along with the payer’s data and the card number. Providers such as Stripe and Adyen transfer this in bulk using PGP keys, and with Stripe the procedure is documented on their side: their database is queried, PGP keys handle the encryption, and customer IDs are retrieved. The vendor then maps the result so the merchant can use it for subsequent payments (see “Token mapping and billing cycles” below).

Network tokens can be moved, but moving them is not enough on its own. Each needs an updated cryptogram. The cryptogram is single-use, and only the token requestor that generated the token can issue a new one for it. So two things have to be in place: the tokens themselves, and an integration with that token requestor.

A token is only as portable as the route behind it

Moving the token records is half the job. The destination platform also needs the connectors and payment methods those tokens were created against. Otherwise, a migrated recurring book arrives intact and unchargeable. For a business built on recurring revenue, that gap shows up directly in turnover.

This is why connector coverage belongs in discovery rather than in cutover. Building from scratch only applies to methods that have not been integrated before, and with 700+ connectors already live at Akurateco, that list is usually short. Anything genuinely new carries its own lead time, so a gap found late becomes a delay rather than a fix.

Token mapping and billing cycles

Mapping is where a migrated token becomes usable, and there are two options. Either the acquirer tokens are stored as tokens the merchant can submit directly, or the vendor creates its own tokens on its side and links them to the acquirer tokens. In the second case, the merchant sends the vendor’s token, the vendor retrieves the acquirer token from its database, and the payment is processed.

Where recurring charges need a set billing cycle, a billing schedule is configured so the migrated card tokens run on the correct cycle. At Akurateco, this is done with Schedule IDs.

Vault ownership and PCI roles

The card data belongs to the client, not to the platform whose card vault holds it. That means it can also move the other way: handed back to the client via PGP or another encrypted method, on request.

Whichever direction it moves, the transfer is verified against PCI DSS. The obligations themselves sit with the merchant, so when a PSP migrates its portfolio, PCI scope follows the merchants rather than staying with the platform they left.

Parallel running and rollback

Merchants migrate one at a time. Each has their own questions, and each needs to test their own setup first, so out of five merchants, one moves while the rest stay where they are. A merchant may also move part of their traffic first rather than all of it.

How long post-launch monitoring runs depends on how fast the switch happens. A single merchant can be done in a few days. A merchant with several payment methods and several providers is switched on in streams, with each stream monitored in parallel as it goes live.

Rollback is per stream, not per migration. What happens when a problem appears on a live stream depends on its size. Something minor is fixed in place, with the stream left running. If the fix is larger, that stream is switched off, and its traffic goes to the other platform until it is resolved. Everything else keeps running, so a problem with one method or one provider does not reverse the migration.

How long does a payment platform migration take?

Timelines depend on who has to do the integration work. The figures below come from Akurateco’s migrations.

A full platform migration with a merchant portfolio: around a month.

Where the vendor emulates the existing protocol and moves the data itself, merchants can start switching within a couple of weeks because they keep their existing integration. For around 50 merchants who are already prepared, with token migration and protocol emulation in place, the migration runs roughly a month.

A simple provider switch: around a quarter.

Where merchants integrate with the new platform themselves, the timeline is set by their developers and their testing rather than by the platform. For 50 to 100 merchants, expect about a quarter.

What speeds it up:

• Merchant responsiveness. Merchants set the pace in any scenario where they have work to do. It’s important to state the timeline right away, rather than when the switch is due.
• Data availability. Hand over everything discovery needs before the plan is drafted. Gaps found later push the plan back.
• Integration availability. Check which of your payment methods the new platform already supports. Every method that has to be built from scratch adds its own lead time. At Akurateco, new connector development takes 10–20 business days.

Akurateco’s migration for Complete Payment Systems (CPS), described below, took longer. It shows what a decade of accumulated transactions on an undocumented legacy monolith does to the timelines above.

Common migration blockers and how to handle them

Most migrations run into the same short list of obstacles: large data volumes, business-specific anti-fraud rules, the merchant’s fear that something will go wrong, and re-onboarding. Each one is solvable, provided there is a plan for it.

Large data volumes

A platform that has run for years holds more than transaction history, including data such as white and black lists. Moving that volume by hand can take weeks. If discovery shows the data is too large to transfer manually, plan bulk transfer tooling before the migration starts rather than finding out midway.

Business-specific anti-fraud rules

Rules written for one business rarely map onto another platform’s logic without changes. The workable approach is to review them one by one and decide what to keep as is, what to reshape, and what to drop, then manually set up and monitor the rules whose logic changed.

The merchant’s fear that something will go wrong

The blocker is rarely downtime itself. It’s the merchant’s sense of risk: they are being asked to move something that currently works, and they want to know what happens if it doesn’t. This is handled by talking through every concern, writing instructions, and describing exactly how the switch will run. Once it does, the vendor monitors that everything processes correctly and stays available to assist.

Merchant re-onboarding

Re-onboarding does not mean repeating KYC/KYB: it is the same merchant and the same business. Technically, this is straightforward, and it sits on the vendor’s side. Where merchants are still concerned about the work involved, the old platform’s protocol can be emulated. The merchant keeps the same protocol and the same tokens, and the switch is seamless from their end.

How CPS migrated: a short case

The problem: Complete Payment Systems (CPS) had its own payment platform, built more than ten years earlier, but the technologies running the monolithic system were somewhat outdated. When the company parted ways with its key developers, it turned out that there was no proper documentation, and attempts to hire a new team ended in failure, as candidates refused to work with old technologies and no documentation in place.

The main challenges: CPS’s business model was based on recurring payments, so it wanted to transfer all its existing tokens to the new platform; some of its anti-fraud rules were also very specific.

The solution: CPS decided to do business with Akurateco, which integrated new connectors to receive the migrated data and added new payment methods to recover soft-declined transactions. After careful consideration, CPS agreed to drop some of the anti-fraud rules, reshape others, and keep most of them as is, while Akurateco’s payment team manually set up and monitored the rules whose logic changed.

The result: Data migration started in August 2021 and was completed in October 2021. By then, the platform was fully set up to meet CPS’s needs, with full access to recurring billing, routing, cascading, and the payment calendar.

Read the full Complete Payment Systems case study.

Conclusion

Whether a payment platform migration runs smoothly is largely decided before anything moves: by how complete the data handed over at discovery is, whether stored cards and tokens can move together with the connectors they were created against, and how early merchants know the timeline. Zero downtime comes from how the switch itself runs: the existing integration stays live until cutover, merchants move one at a time, and a problem on a live stream is switched back to the previous platform without reversing the whole migration. The timeline depends on who does the integration work: when merchants integrate themselves, their developers set the pace, and when the vendor emulates the old protocol, merchants can start switching sooner.

Should you have questions about your own migration, book a free demo, and Akurateco’s representatives will get in touch and show you around the system.

Payment Platform Migration FAQs

Can you switch payment providers without downtime?

Yes, if the switch is staged. The existing integration stays live until each merchant cuts over. Merchants move one at a time, and if a live stream runs into a problem that needs more than a quick fix, only that stream is switched back to the previous platform while the vendor resolves it. The rest of the migration keeps running.

Can stored cards and tokens be migrated?

Yes, depending on the token type. Acquirer tokens need the MID data they were created under, customer tokens are handed over by the previous provider, and network tokens also need an integration with the token requestor that issues their cryptograms. In every case, the new platform must already support the payment methods those tokens were created against.

How long does it take to migrate a payment gateway?

It depends on who does the integration work. In Akurateco’s migrations, a full payment gateway migration with around 50 prepared merchants, with token migration and protocol emulation in place, takes roughly a month. A simple provider switch, where 50 to 100 merchants integrate with the new platform themselves, takes about a quarter.

Do merchants need to re-onboard after a migration?

No. It’s the same merchant and the same business, so the documentation side is already done. KYC and KYB with the acquirer are not the vendor’s call in any case. At most, the acquirer may ask to see the new platform’s PCI DSS certification to verify that it can act as an intermediary.

What happens if a migration fails midway?

It depends on what failed. If the token transfer itself runs into errors, the cause is investigated and fixed, and the migration is completed. If the merchant has already moved to the new platform and something goes wrong there, their tokens and entities are still held in the previous system unless the client explicitly asked for them to be deleted, so the merchant can roll back to it.