A client processing continuous transactions asked us to switch payment providers with zero scheduled downtime. Not "minimal" — zero, because their business does not have an off-peak window worth mentioning.
Why the obvious approach did not work
The obvious plan — cut over on a chosen date, monitor closely, roll back if needed — assumes a moment exists where traffic is low enough to risk. For this client no such moment existed, and a rollback after real money had moved through the new provider was its own separate risk.
Running both providers in parallel
Instead of a cutover, we ran both providers simultaneously behind an internal routing layer, starting at a tiny percentage of traffic and increasing gradually over three weeks. Every transaction through the new path was reconciled against what the old path would have produced, on a subset where that comparison was possible.
- Idempotency keys on every transaction so a retry, on either provider, during the transition could never double-charge.
- A kill switch that routed all traffic back to the old provider instantly, tested for real — not just reviewed — before the migration began.
- Reconciliation reports run daily, comparing settlement totals across both providers against the client's own ledger, with any discrepancy investigated the same day it appeared.
The part that took longest
Not the integration itself — the provider's API was well documented and behaved as advertised. The slow part was building confidence, through the gradual percentage increase and daily reconciliation, that low-frequency edge cases — a specific card type, a specific currency, a refund issued against a transaction from before the migration — all worked identically on both sides before we trusted the new provider with full volume.
Zero downtime does not mean the migration happens instantly. It means the migration is slow enough that nobody outside the team notices it happening at all.
What we would not do differently
Some pressure existed to move faster once the first week showed no problems. We held the gradual ramp to its planned schedule anyway, because the failures we were watching for were specifically the low-frequency ones that a fast ramp would not have had time to surface.
Where it landed
The full migration took five weeks from first traffic on the new provider to fully switching off the old one, with no reported customer-facing incident and no unplanned downtime. The client's only comment afterwards was that they had not noticed anything happen, which was exactly the goal.