All notes

    What it actually costs to migrate ten years of case history.

    Every proposal underestimates this, including ours once. The cost is not in moving the records. It is in deciding what they meant.

    A migration proposal usually reads like an engineering task: extract, transform, load, verify. The extract and the load are the easy parts. The transform is where the money goes, because transforming means deciding, and only the firm can decide.

    The decisions nobody budgets for

    • Two systems hold the same matter with different statuses. Which was true, and as of when?
    • A status exists in the old system that has no equivalent in the new one. Does it map to something, or does it need a new concept?
    • A hearing is marked struck. Was the client told? The records do not say, and the answer changes what the new system should do next.
    • A matter has two client records because somebody created a duplicate in 2021. Which one carries the history, and what happens to the other?
    • Records predate a process change. Do they get backfilled to the current model, or flagged as historic?

    None of these are technical questions. All of them require someone who was there, and each one has consequences that surface months later.

    Budget the firm's time, not just the engineer's. A migration where nobody senior is available to answer questions will produce a clean, fast, confidently wrong dataset.

    Two traps that corrupt quietly

    The first is time zones. Spreadsheet exports commonly store dates as serial numbers in local wall time. Convert them as if they were UTC and every record shifts by five or six hours — which silently moves some of them onto the wrong day. For appointments and court dates, the wrong day is a missed obligation, and it will not look like a bug. It will look like the firm being unreliable.

    The second is idempotency. A migration is never run once. It is run, checked, corrected and run again, often several times. Every import needs a stable external identifier so a second run updates rather than duplicates. Building that in on the first pass costs an hour. Discovering you need it after the third run costs a day of cleanup and a loss of confidence in the data.

    What to ask a vendor

    • How many decisions do you expect us to make, and roughly when?
    • Is the import idempotent? Show me what happens on a second run.
    • How are dates converted, and what time zone is the source in?
    • What is the plan for records you cannot map — silent default, or a queue a human works?
    • How long do both systems run in parallel, and what has to be true before the old one is switched off?

    A proposal that cannot answer the last one is not a migration plan. It is a hope.

    Want to know whether this applies to your firm?

    Thirty minutes, an honest read on where your friction actually is, and a recommendation. If we are not the right fit, we will tell you.

    Book an Operational Strategy Call