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. TODO: verify and publish the current list of production client interface formats before this page ships.

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. TODO: verify which call paths run that clearance today and say so plainly here.

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. TODO: state the commitment for configuring a jurisdiction outside those four, once that has been decided.

How long does a migration take?

TODO: publish a real number here from a completed migration, or publish nothing. Our own marketing pages have quoted about two weeks and the reference layer is not going to repeat that without a finished migration behind it. What can be said is what determines the answer: the number of live client interfaces, the state of the trust reconciliation, whether the imaging store carries usable provenance, and how many people the firm can spare to run both systems side by side.

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 programme. A firm that treats the cutover as the end of that work has bought software rather than built a control.

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.