Every migration promise is about accounts and balances. The trouble is always somewhere else: tokens, notes, images and reports. Here is where each one actually lives.
Every migration pitch leads with the same reassurance: your accounts, balances and history come across. That part is true, and it is the easy part. Accounts and balances are rows in a table. The things that hurt on cutover day are the things that were never rows in a table to begin with.
There are four of them. Plan for each one before you sign anything, with any vendor, ours included.
Consumers on payment plans gave your agency a card or a bank account once, and they expect never to be asked again. Those details are not in your collection system. They are in a token vault at your payment processor, and your system holds a reference to them. Some platforms keep that reference in a separate database tied to the processor; some run every payment through a third-party gateway. Either way, the tokens are the processor's.
What that means: the tokens move only if the processor re-points its vault to the new platform. That is normal, routine work for a processor, and it is the single most important line in a migration plan. Ask your new vendor to name the step. Ask your processor what it costs and how long it takes. A plan that says "payment tokens come too" without mentioning the processor is a plan written by someone who hasn't done it.
Notes are where the truth of an account lives: what the consumer said, what the collector promised, why the balance was adjusted. They are also the least portable data in the industry. One enterprise platform's standard export truncates notes at 256 characters. One legacy platform stores free-text notes and field-change audit lines in the same file under inconsistent prefixes. One small-agency platform's own customer described it under oath as too old to produce that data on its own.
What that means: notes need to be read from the database directly, not from the vendor's export tool, and someone needs to count them. Before cutover, sample fifty accounts and compare note by note. Your compliance team will thank you the first time an examiner asks for the history of an account that migrated.
When a consumer disputes what you sent them, you need the letter, not the letter template. When they say a collector threatened them, you need the recording. Neither is in your collection system. Letters live with your print vendor; recordings live with your dialer. Your system has a note that says a letter went out.
What that means: these don't migrate because they were never in the system you're leaving. Before you give notice to anyone, export them from those vendors for your full retention period, and check that the export is readable without the vendor's software. Your new platform builds the audit trail forward from day one; the past is your job to keep.
Twenty years on one platform produces a library of custom reports, scheduled jobs, stored procedures and scripts that nobody fully remembers. They are written against the old schema in the old tool. They do not migrate, and no vendor can honestly say otherwise.
What that means: inventory them and sort them into three piles. Reports you actually run every month get rebuilt in the new system before cutover. Reports you run at year end get rebuilt by year end. Reports nobody has opened since 2019 get archived. Most agencies find the third pile is the largest, which is its own lesson.
A migration plan worth signing lists all four of these by name and says, for each one, moves, depends, or stays. "Depends" is a fine answer as long as it says on what. "Zero data loss" is not an answer. It is a slogan.
The things that hurt on cutover day were never rows in a table to begin with.
Our migration guides at resolvah.com/migrate carry that manifest for each major platform, including where its notes get truncated and which processor its payments run through.
This is how we think — and how Resolvah works. See it for yourself.
Thirty minutes, a real operator, and the actual product. No script.