Teams rarely leave a recovery vendor because of one bad month. They leave after a slower accumulation: recovery reports that cannot be reconciled with the billing platform, retries that seem to fire on a schedule nobody can explain, and a pricing line that keeps rising with the very failures the tool was hired to reduce. By the time the switching conversation starts, the frustration is real — and the risk is that frustration, rather than evidence, chooses the replacement.

Start with the export, not the demos. Pull twelve months of failed-payment episodes from your billing platform: how many cases opened, how they ended, and how much was eventually collected by any route. That file is the only honest baseline. A new vendor's promises mean little against an unknown denominator, and the export also exposes the uncomfortable categories — cases closed by replacement charges, cases the customer resolved after one email, cases still technically open that everyone has forgotten.

Next, separate the jobs. Some tools are primarily retry engines. Some are primarily messaging. Some fold in cancel deflection and call that recovery. None of these is wrong, but a switching decision that treats them as interchangeable will re-buy the same gap under a new logo. Write down which failures dominate your pool — expired cards, insufficient funds timing, authentication-required declines — and judge candidates against that mix, not against a generic recovery rate quoted from someone else's customers.

Pricing deserves the same cold treatment. Percentage-of-recovery models look cheap in a quiet month and expensive in a rescued one; flat pricing is a known line that stays known. Run both models against your own exported pool at three recovery levels — pessimistic, plausible, and good — and look at what each vendor earns in the good case. The vendor you want is not necessarily the cheapest in the bad case. It is the one whose invoice you can still defend in the good one.

The comparison criteria, the questions to ask about decline-code handling and card-change sensing, and the way a flat $179 alternative stacks up are set out in what to weigh when you replace a percentage-priced recovery tool. Its most useful discipline is sequencing: baseline first, job definition second, vendor demos last — so the demos answer your questions instead of supplying them.

Migration itself is smaller than its reputation. The historical pool matters most: a new tool should be able to work the recent backlog, because a failed payment from three weeks ago is not ancient history, it is a subscriber mid-decision. Ask explicitly how far back the first campaign reaches, how cancellations recorded in the billing platform stop outreach, and how a customer who pays through a fresh checkout is counted — recovered by replacement is an honest label; silently claiming the retry did it is not.

Finally, judge the switch after ninety days on total recovered dollars against the exported baseline, not on a rate whose denominator quietly changed. That is the standard Swipe Again states in its own guarantee, and it is a fair standard to hold any replacement to — including the incumbent, whose strongest argument was never the contract. It was the count. Make every candidate, old and new, pass the same count.

One more discipline belongs in the switching file: record, before the new tool starts, exactly how success will be counted — which episodes enter the denominator, how long a case stays open, and how replacement payments are labelled. Vendors rarely disagree about effort; they disagree about arithmetic, usually afterwards. A counting agreement written in advance turns the ninety-day review into a reading of numbers everyone already accepted, rather than a fresh negotiation about what the numbers mean.