How to migrate brands without downtime — the zero-interruption portfolio cutover

Migrating a brand — or several brands — from one processor to another is the single riskiest operational move you can make in payments. Get it wrong and your subscribers cancel, your ad pixel breaks, your chargeback ratio spikes because your new processor sees you as a fresh merchant with no history. Get it right and customers never notice.

1. What actually moves in a migration

A full processor migration involves moving:

• Checkout integration — the front-end gateway, API keys, webhook endpoints.
• Saved cards (tokens) — possibly the hardest piece if tokens are not portable.
• Active subscriptions — each needs to re-bill on the new processor without lapse.
• Descriptor — statement text customers see changes; this is a source of chargebacks if mishandled.
• Apple Pay / Google Pay — wallet re-registration per domain.
• Analytics and reporting — shopify/Stripe/Adyen dashboards and any custom reporting.

2. The one thing to negotiate before you sign with the new processor

Token portability. Full stop. Ask the new processor whether they accept a PCI-compliant token migration from your current processor. If yes, you move tokens without customers re-entering cards. If no, you migrate by forcing re-authorization — which loses 15-40% of subscribers.

Stripe-to-Stripe migrations inside the same Stripe entity are trivial. Stripe-to-elsewhere or elsewhere-to-Stripe requires a formal token migration request and usually a compliance attestation from both sides.

See moving from Stripe Connect to a parent account.

3. The four-phase migration process

Phase 1: Parallel run (2-4 weeks)

• New processor approved, MIDs live, sandbox tested.
• Checkout integrates both processors. Route 5-10% of live traffic to the new one. Monitor decline rates, fraud rates, webhook reliability.
• Any issue surfaces at 5% volume where it is recoverable, not at 100% where it is catastrophic.

Phase 2: Token migration (1-2 weeks)

• Initiate formal token migration between processors. Both sides sign compliance docs.
• Tokens transfer in batches. Verify each batch by running $0 auth on migrated tokens — confirm each still charges successfully.
• Any token that fails the $0 auth, plan for re-authorization via customer email.

Phase 3: Subscription cutover (1 week)

• Identify the billing cycle for each subscriber. Migrate one cohort at a time — e.g., "all subscribers whose next bill is between day 8 and day 14 of the cutover window".
• For each cohort: pause the old processor's scheduled charge, schedule the next charge on the new processor using the migrated token.
• Validate after each cohort bills successfully before moving the next.

Phase 4: Full cutover (1 day)

• Flip checkout traffic 100% to the new processor.
• Update webhook endpoints.
• Re-register Apple Pay / Google Pay domains if the new processor is a different entity.
• Update descriptor on the new processor to match the old one as closely as possible. This is critical — descriptor changes mid-subscription are the top cause of post-migration chargebacks.
• Keep the old processor active for 30 days to handle refunds on pre-migration transactions (you can only refund on the original processor).

4. What to watch for during parallel run

• Decline rate delta. If the new processor declines 8% vs old 4%, your issuer-bank whitelisting has not transferred. Investigate.
• Fraud rate delta. A new processor starts with no risk history on your customer base. Radar/fraud tool needs tuning during the parallel period.
• Webhook reliability. Run the new processor's webhooks for a week before relying on them. Any missed events means missed orders.
• Payout timing. New processors often payout on different schedules. Validate cashflow.

5. The communication plan

Before cutover:

• Email all active subscribers: "we are updating our payment infrastructure. You may see a slightly different statement descriptor starting [date]. No action needed."
• Update your billing FAQ page with both the old and new descriptor listed.
• Train customer service: give them a one-pager on what to expect and how to answer "why does this charge look different?"

Descriptor-change-driven chargebacks can spike 2-3× in the week after cutover if you skip this step.

Working example: 6-brand CBD portfolio, Stripe to specialty acquirer, zero downtime

Operator needed to move 6 CBD brands off Stripe after category enforcement ramped up. Plan:

• Week 0: new acquirer approved, token portability agreement signed.
• Week 1-2: parallel run at 10% traffic on new processor. Surfaced 1 webhook bug (fixed) and 1 fraud rule misconfiguration (fixed).
• Week 3: token batch migration. 98.2% of tokens migrated cleanly; 1.8% required re-auth email (captured 76% of those within 14 days).
• Week 4: subscription cutover in 3 cohorts. Successful recurring charge rate 97% (vs 96% baseline — actually better than pre-migration).
• Week 5: full cutover. Descriptor transitioned with 48-hour notice email.

Result: lost <2% of recurring revenue during migration. Zero customer-facing downtime. Old processor retained for 30 days to handle pre-migration refunds. Full wind-down complete at day 45.

FAQ

Can I migrate without token portability? Yes, but expect 15-40% subscriber loss. Only do this if token migration is not possible (e.g., the old processor refuses to cooperate — sometimes happens post-freeze).

How long should parallel run be? Minimum 2 weeks at meaningful traffic (5-10%). More for high-risk verticals.

What about Apple Pay? Re-register every domain with the new processor. See routing Apple Pay across domains.

Do I need to update 1099-K records? Not in the middle of the year — each processor issues its own 1099-K for its share of the year. See 1099-K reconciliation.

CTA

Moving brands between processors is what multiflow does professionally. We run parallel, migrate tokens, and stage cohort cutovers while you keep shipping. Apply to multiflow or see pricing.