Migrating a collections firm to a new case management system

A collections migration is really four migrations: the money, the media, the client interfaces, and the change history. Accounts and balances are the straightforward part. What sets the schedule is whether the trust ledger reconciles at cutover, whether documents keep their chain of custody, and whether every client interface keeps producing the file it produced before.

What actually has to move?

Four things, and the account data is the least of them. The ledger has to arrive reconciled — trust balances, client-owed amounts, unremitted collections, cost advances and the fee splits that produced them. The media has to arrive with its provenance intact, because a document whose origin you cannot state is a document you cannot rely on in a filing. The client interfaces — placement, status, recall, remittance — have to keep producing the same files, for the same clients, on the same schedule, from the first day. And the change history has to survive, because an examiner's question is almost always about a date in the past rather than about the state of the file today.

Why is the trust ledger the hard part?

Because it is the one number nobody will accept as approximately right. A migration that lands consumer records perfectly and lands the trust account a dollar out is a failed migration, and it fails in the direction that gets reported. The workable sequence is to reconcile before the cutover rather than after it: run the old system's trust reports, reconcile them to the bank statements, freeze, load, then reconcile the new ledger back to those same statements. A vendor who treats trust as a field-mapping problem rather than an accounting problem has not done this before.

What happens to twenty years of documents?

They move; the question is what moves with them. Otto content-hashes each document as it is ingested, so the file in the system after the migration is demonstrably the file that was in the system before it — a different and stronger claim than we copied the folder. What a hash cannot do is invent provenance the old system never recorded. If the imaging store holds documents with no source, no date and no link to an account, they arrive in exactly that condition. Find that out during a sample load, not during an exam.

What about the client interfaces — placements, status files, remittance?

This is where collections migrations actually fail, and it is worth being blunt about our own position. Otto models placement, status, recall and remittance as per-client interfaces rather than as one generic import, which is the right shape for the problem. Breadth is a separate question from shape: the number of client formats running in production here is smaller than the number a long-established incumbent maintains, and closing that gap is scoped work per client, not a setting.

Can you run both systems at once?

Yes, and for most firms that is the sane sequence. Otto Redact runs as a native Windows or macOS application on your own machines, watches local folders and reads your current system's exports, so a firm can work over its existing material before any cutover has happened. Parallel running also gives you the only migration test that means anything: the same account, in both systems, on the same day, compared by somebody who knows what the numbers should say.

What changes on day one, and what does not?

What changes is when a rule is applied. Otto's engine evaluates before the action rather than sampling after it: a case cannot advance out of pre-litigation while the client's required media is missing or no attorney review is on file, and a call is refused once the configured attempt count inside the rolling window is reached, or during the cooldown that follows a telephone conversation. Both are driven by per-client configuration rather than by code, and a refusal is recorded with the rule that caused it. On the voice path, a pre-dial clearance evaluates account holds, consent for an artificial or prerecorded voice, revocation, the client's own contact rules, whether validation has been sent, quiet hours in the consumer's time zone, and attempt frequency.

Which states are configured?

Four ship configured today — Florida, Georgia, Texas and New York — each carrying its own licensing posture, limitations periods, garnishment treatment, contact-window and call-recording rules, and whatever state overlay sits above the federal floor. That is a count, not a ceiling, and it is deliberately not the larger number that still appears on some of our marketing pages; those are wrong and are being corrected. Ask any vendor which states are configured rather than which states are claimed, and ask to see the configuration on screen.

How long does a migration take?

Longer than a vendor's first answer, and the published norms are the right place to start. A guide for legal case-management migrations puts the range at "2-6 months, not 2-6 weeks", advises firms to "Run parallel systems for 60-90 days. Do not flip the switch overnight", and says plainly that "No migration is lossless" — matters, contacts and documents typically export, while custom fields, reports and portal history often do not. None of that is disputed here. Our own plan is twelve weeks with sixty days of it parallel, and it is a commitment rather than an industry figure, so it is worth saying what makes the number achievable rather than asserting it: weeks one and two are inventory and export, with you exporting and us counting; weeks three to six map, import and reconcile every field against your old system's own totals, with anything that will not translate on your desk by week six; weeks seven to ten run both systems live, new placements landing in Otto first while the old system keeps the books; weeks eleven and twelve cut over queue by queue — placements, then payment plans, then litigation — after which the old system goes read-only rather than off. Two of those choices are what compress the calendar: nothing is ever down, because your current system stays the source of truth until the last queue moves, and the differences are surfaced early rather than at cutover. If your firm's client interfaces are numerous or your forms library is deep, expect the published range rather than ours, and ask us to say so before you sign rather than after.

What should you ask any vendor before you sign?

Five questions, and the answers tell you more than a feature grid. Which of my client interfaces run in production today, by name? Show me a trust reconciliation from a completed migration. What happens to my change history — after the move, can you reconstruct a file as of a date in the past? Which states are configured, and may I see the configuration? And if you say your system prevents violations rather than reporting them, show me the record a blocked action leaves behind. A vendor who answers all five in writing is describing the migration you will actually get.

What a migration cannot do for you

It cannot produce compliance. Otto's terms disclaim that outcome and this page holds the same line: changing systems changes which controls run and what evidence exists, and leaves every legal obligation exactly where it was. It cannot substitute for supervision, for attorney judgment, or for a compliance management program. A firm that treats the cutover as the end of that work has bought software rather than built a control.

In this section

• Migrating from Collection-MasterWhat moves when a firm leaves Vertican's Collection-Master, sourced to Vertican's own published materials — including the roadmap it publishes for the product.
• Migrating from Q-LawLeaving Q-LawE: the move from perpetual to subscription licensing, the change-tracking tables that can be truncated, and what gets rebuilt rather than moved.
• Migrating from CollectMaxLeaving CollectMax: where the data actually sits, why SmartData is usually the only SQL-readable copy of it, and which parts of the build get rebuilt rather than moved.

This is an informational reference, not legal advice, and using it creates no attorney-client relationship. Limitations periods turn on facts this page cannot know — which state's law governs, the contract type, when the claim accrued, and whether anything tolled or revived it. Confirm against the primary source and your own counsel before acting.