Slice the payment rebuild by invoice type

Payment systems resist slicing. Everything touches money, money touches ledgers, and the first workshop always concludes the system is "too interconnected to migrate incrementally". The conclusion is wrong, and the seam that proves it wrong is usually sitting in finance's org chart already: invoice type.

Recurring subscriptions, one-off purchases, refunds, manual adjustments. Different rules, different volumes, different risk. Finance already treats them as different work; reconciliation already reports them in different columns. That is a seam. Route one type through the new rail, reconcile it against the old system's numbers for a full billing cycle, then take the next.

The pattern in the field: a payment rebuild case study we point clients at ran exactly this way, slicing the flow rather than replacing the estate in one weekend, with each slice earning the next one's approval. The write-up is worth ten minutes; the order of slices is the teachable part.

Rules that keep it safe:

1. Lowest-risk type first, not highest-volume. The first slice's job is to prove the reconciliation harness, not to impress.
2. Refunds and adjustments migrate last. They are where the weird lives, and by then the harness has caught a cycle's worth of weird.
3. Both rails post to one ledger throughout. Two ledgers is two systems of record, which is one more than a company can have.
4. Every slice gets a full cycle of parallel reconciliation before the old path closes. Month-end is the real test; nothing that has not survived one counts as migrated.

The "too interconnected" verdict usually means "we looked at the code". Look at the money instead. Finance drew your seams years ago, and unlike the code, their diagram is reconciled monthly.