Migrating between PSPs without a big-bang cutover

Every PSP migration begins with an optimistic plan and a deadline, and a striking number of them end with an unplanned incident review. The pattern is consistent enough to name: teams treat a PSP migration as a discrete cutover event — a weekend deploy where traffic switches from the old provider to the new one all at once — rather than as the extended, carefully sequenced programme it actually needs to be.

Why big-bang cutovers fail predictably

A big-bang cutover concentrates every possible failure mode into a single moment: if the new PSP's authorisation rates differ meaningfully from the old one, if a webhook signature format was misunderstood, if a hosted field integration has a subtle bug that only manifests under real traffic patterns — all of it surfaces simultaneously, under maximum pressure, usually outside business hours when the team is least resourced to respond quickly. Rolling back a big-bang cutover is also frequently harder than the cutover itself, because credentials, webhooks and data may have already been partially migrated.

Dual-running as the safer default

Dual-running — operating both the old and new PSP simultaneously, with explicit routing logic deciding which transactions go where — turns a single high-risk event into a series of small, reversible steps. Percentage-based traffic shifting lets you start with a small fraction of traffic on the new provider, observe real authorisation rates and error patterns, and increase the percentage only once you have confidence, rather than betting the entire migration on pre-launch testing alone.

Cohort-based migration

Rather than shifting traffic purely by random percentage, migrating specific, well-understood merchant or transaction cohorts first — a single low-risk merchant, a single card type, a single corridor — gives you a controlled, comparable data set to validate authorisation parity before expanding to higher-risk or higher-volume cohorts.

Credential and webhook isolation

Keeping credentials and webhook endpoints strictly isolated per provider throughout the migration — rather than trying to unify them prematurely — makes rollback genuinely simple: routing traffic back to the old provider should be a configuration change, not a re-integration effort. Premature unification of credentials or webhook handling across providers, done in the name of tidiness, is a common way migrations become harder to reverse than they need to be.

Communicating with merchants early

If a migration changes anything merchants or their customers can perceive — a different hosted fields provider, a different redirect domain for 3DS challenges, different webhook payload formats — communicate this well in advance, with clear technical guidance for any integration changes required on their side. Merchants who discover a PSP change only when their integration breaks unannounced lose trust quickly, regardless of how smoothly the underlying migration technically went.

Measuring authorisation parity before scaling traffic

Before increasing the percentage of traffic routed to a new provider, measure authorisation rate parity segmented the same way you would monitor any payment system — by BIN country, card type and corridor — rather than relying on an aggregate rate that can hide a meaningful regression in a specific segment. A migration that looks successful in aggregate can still be quietly damaging a specific customer segment that has not yet been reviewed closely enough.

A migration programme checklist

• Plan dual-running with percentage-based traffic shifting rather than a single cutover event.
• Migrate well-understood, low-risk cohorts first to validate parity before expanding scope.
• Keep credentials and webhooks strictly isolated per provider to preserve simple rollback.
• Communicate merchant-visible changes well in advance, with concrete integration guidance.
• Measure authorisation parity segmented by BIN country, card type and corridor before scaling traffic.
• Run the migration with a defined hypercare window, not as a single deploy-and-move-on event.

Running migrations as programmes, not deploys

Pay Engineers runs PSP migrations as structured programmes with explicit hypercare windows — periods of heightened monitoring and rapid response capacity immediately following each traffic-shift step — rather than as weekend deploys that hand off to standard on-call rotation the moment the change ships. That structural difference is what separates low-drama migrations from ones that end up as incident post-mortems.

The safest PSP migration is the one where, at every single step, you could roll back in minutes without anyone outside the team noticing.

Deciding when a migration is actually complete

Teams sometimes declare a migration finished the moment one hundred percent of new traffic is routed to the new provider, then immediately decommission the old integration to reduce maintenance burden. This is usually premature. Keep the old provider's integration, credentials and webhook handling intact and dormant for a defined tail period after reaching full traffic, specifically so rollback remains genuinely available if a delayed issue surfaces — a monthly billing cycle that only runs once, for instance, or a rare edge case that simply had not occurred yet in the traffic observed so far.

Only decommission the old integration once that tail period has passed without incident, and even then, retain the historical data and credentials in a recoverable, documented state for as long as your record-keeping obligations require, rather than deleting everything the moment the dashboard shows green.

Key takeaways

• Big-bang cutovers concentrate every migration risk into one high-pressure, hard-to-reverse moment.
• Dual-running with percentage-based traffic shifting turns migration into small, reversible steps.
• Cohort-based migration validates parity on a controlled data set before wider rollout.
• Strict credential and webhook isolation per provider keeps rollback simple throughout.
• Measure segmented authorisation parity, and run migrations as programmes with defined hypercare.