The 30-day cutover plan: moving a 12-brand portfolio to one parent account

Most portfolio operators picture the cutover as a single dramatic weekend: flip the DNS, pray the webhooks fire, wake up Monday on a new stack. That is not how any successful 12-brand migration has ever run. The migrations that land on time and under budget run as a 30-day rolling release: one brand proves the stack, two or three per week follow, and by day 30 the last brand is quietly moved after the system has already logged three weeks of production traffic. This is the runbook we hand operators when they ask what the month actually looks like.

1. The pre-flight week (days -7 to 0)

Before day one, you need three artifacts locked: a brand inventory, a webhook map, and an acquirer underwriting packet. The brand inventory lists all 12 legal entities, their DBAs, their MCC codes, their monthly volume, chargeback ratio, and current processor. The webhook map lists every downstream system that consumes a Stripe event today — accounting, CRM, fulfillment, ad platforms, CDP. The underwriting packet is the standard acquirer bundle: formation docs, EIN, bank, voided check, ID, processing statements for 6 months, website URLs, return policy screenshots.

The single most common pre-flight mistake: underestimating the webhook map. Operators think it is three systems; it is usually seven or nine. If you do not map them before cutover, one will break silently on day 2 and you will spend the rest of the week chasing it.

2. Week 1: underwriting and pilot brand selection

Day 1 through 5: submit the underwriting packet to the acquirer. Most direct merchant accounts underwrite in 3–5 business days for clean MCCs, 7–10 for borderline verticals. During that window, pick the pilot brand.

The pilot brand should be: mid-volume (not the biggest, not the smallest), clean chargeback history, no active subscription billing if possible, and a product the team knows well so anomalies jump out. Do not pilot with the flagship. If something goes wrong on the pilot you want to be debugging a $40k/month brand, not a $400k/month brand. See onboarding 20 brands on one merchant account for the sub-brand descriptor structure you will be provisioning against.

Day 6 and 7: acquirer approves, MID is issued, sub-brand descriptor is provisioned for the pilot. Checkout is wired in a staging environment. No production traffic yet.

3. Week 2: pilot brand production cutover

Day 8: pilot brand goes live on the new stack during a low-traffic window (for most DTC, that is Tuesday morning Pacific). DNS stays pointed at the existing site; only the checkout gateway changes. The old Stripe account stays active and able to process — this is a soft cutover where both back-ends can receive traffic, but 100% of new checkouts route to the new stack.

Day 9 through 12: watch everything. Authorization rate, decline rate, 3DS challenge rate, Apple Pay conversion, webhook delivery to all downstream systems, payout timing, refund flow, dispute flow. The acceptance bar is simple: auth rate within 0.5% of baseline, zero webhook failures, zero customer complaints flagged as payment-related.

Day 13 and 14: if the pilot holds for 14 days clean, you have your production signal. If it does not, you fix the single issue that surfaced and restart the 14-day clock. Most teams hit 14 days clean on the first try; roughly a quarter have to fix one webhook issue and restart.

4. Week 3: the batch of three

Day 15: pick three brands to migrate in week 3. The selection rule: no two brands in the same vertical, no brand with active dunning cycles in the next 14 days, no brand launching a promotion during the week. You want boring migrations.

Day 15 and 16: provision sub-brand descriptors for all three. Wire checkouts. Stage webhook routing.

Day 17: brand 2 goes live. Day 18: brand 3. Day 19: brand 4. Stagger by 24 hours so if one breaks you are not debugging three simultaneously. By Friday of week 3, four brands are live on the new stack and the oldest pilot has 14 days of production history.

The card vault migration for each brand is the gating item. If a brand has tens of thousands of saved cards on Stripe, you need a PAN migration request filed with Stripe support 10–14 days before the cutover. Miss that lead time and the brand waits an extra cycle.

5. Week 4: the rest, in two batches

Day 22 through 25: migrate brands 5 through 8. Same pattern — stagger by 24 hours, watch webhook delivery, confirm auth rate.

Day 26 through 29: migrate brands 9 through 12. By day 29 every brand is on the new stack.

Day 30: the old Stripe accounts are put into read-only mode. Historical reporting stays accessible. No new charges route there. Refunds for pre-cutover orders still process from the old account for 120 days — this is the standard refund window and the reason you do not close the old accounts on day 30.

6. The webhook normalization layer

The hidden 15% of engineering time mentioned in the TL;DR goes here. The downstream systems consuming your payment events — NetSuite, Klaviyo, Shopify, your fulfillment 3PL, your affiliate platform, your ad pixel server — all expect a particular webhook shape. Stripe sends one shape. Your new acquirer sends a different shape. If you let each downstream system consume the raw acquirer webhook, every one of them needs a code change on cutover day.

The pattern that works: a normalization layer sits between the acquirer and the downstream systems. It receives the acquirer's native event, transforms it to the Stripe-compatible shape your systems already know, and forwards. Your downstream systems see no change. Migration risk collapses from twelve concurrent integration rewrites to one well-tested adapter. See webhook reliability across sub-brands for the retry and dead-letter patterns that keep this layer reliable.

7. The reconciliation parallel-run

Finance runs both books for the first 30 days post-cutover. Every day, the finance team reconciles the new acquirer's payout against the bank deposit, and the old Stripe accounts' residual refund activity against the same bank. This is 60–90 minutes/day during the parallel-run — painful but non-negotiable. The payoff: you catch any descriptor-mapping bug in week 2 instead of at month-end close when it is ten times harder to diagnose. Our multi-brand reconciliation playbook has the spreadsheet template.

8. The chargeback handoff

Chargebacks filed against pre-cutover transactions go to the old Stripe account. Chargebacks filed against post-cutover transactions go to the new acquirer. This split persists for roughly 120 days (the card network chargeback window). During that window, your chargeback analyst works two queues. Beyond 120 days, the old queue quiets and you are on one system.

One trap: if a customer calls their bank on day 75 and disputes an order that shipped on day 10 (pre-cutover), the chargeback lands on the old Stripe account. Ops has to remember to check both queues for 4 months. Set a calendar reminder at day 45 post-cutover and again at day 90. Our chargeback dispute playbook has the representation templates that work equally well across both back-ends.

9. The rollback plan you hope you never use

A rollback plan is a 30-minute write-up that sits in the ops runbook and is never referenced. It reads: if auth rate drops more than 2% for more than 6 consecutive hours on a migrated brand, or if a single webhook integration is failing silently for more than 24 hours, route that brand's checkout back to the old Stripe account within 60 minutes. The old accounts stay warm for the full 30 days for exactly this purpose.

In the dozen cutovers we have run at this size, rollback has been invoked twice — both times on a single brand, both times resolved within 72 hours, both times forward-migrated successfully on the second attempt. The rollback plan is cheap insurance; build it, do not use it, keep it anyway.

10. Costs and the month-30 outcome

Hard dollar costs of the cutover: multiflow setup fee (pricing) + ~60 hours of engineering for the normalization layer + ~40 hours of finance time across the parallel-run + ~20 hours of ops time for the brand-by-brand wiring. At loaded rates, call it $25–35k all-in for a 12-brand cutover.

Outcome at day 30: one acquirer relationship, one monthly statement, one set of KYC documents, twelve sub-brand descriptors, one normalized webhook bus, and reconciliation that takes 45 minutes a week across the whole portfolio instead of six hours. The effective rate drops typically 0.6–1.1% — on $1.2M/month of volume across 12 brands, that is $85k–$160k/year recovered. Payback on the cutover is under 90 days in every case we have measured.

Start with the 12-question intake and we will return a dated calendar for your specific portfolio within 48 hours. Or see how the stack actually routes before you commit.