Case study

Ten years of case history, migrated.

The legal side of the firm: matters, court dates, orders, documents, billable time. It had to absorb a decade of records from two systems before it could replace either of them.

The problem

Two systems held case data and neither held all of it. A third-party automation layer sat on top running the court-day obligations — reminders, confirmations, client notices — through a chain of triggers configured years earlier that nobody currently at the firm had built.

That layer worked. The risk was that nobody could say precisely what it did, and it could not be changed safely.

What migration actually involved

Not a data transfer. A sequence of judgement calls: which of two conflicting records was true, what a status meant in a system that had been retired, whether a hearing marked struck had been struck silently or with notice to the client. Those distinctions carry consequences, so they were made by the firm rather than inferred.

One detail worth naming, because it is the kind of thing that quietly corrupts a migration: the source export stored dates as spreadsheet serials in local wall time. Converting them naively shifts every hearing by five or six hours, which silently moves some of them onto the wrong day.

The cutover

Both systems ran the court-day jobs in parallel, with a monitoring page showing what each had sent, until the two agreed. Only then was the old platform's automation turned off — one job at a time, not all five at once.

A cutover is not an event. It is a period during which you can still go back, and it ends when the numbers agree rather than when the calendar says so.