How to Migrate Legal Software Without Losing the Meaning of Your Data

Moving a law firm is not a spreadsheet exercise. It is a reconstruction of relationships.

A contact belongs to matters. A matter has clients, opposing parties, responsible lawyers, deadlines, documents, notes, invoices, payments, trust activity, and custom information. A document may be meaningless without its date, category, author, matter, and version history. A payment that arrives without its invoice allocation can change an account balance even when the dollar amount is correct.

That is why a migration can report the right number of rows and still leave the firm with the wrong practice.

Begin with the questions the firm must answer on Monday morning

Before mapping files, list the work the new system must support immediately:

• Which deadlines are approaching?
• Who represents each client and who is adverse?
• What work is open, waiting, or overdue?
• Which documents are final and which are drafts?
• What has been billed, collected, held in trust, or left unapplied?
• What did the firm promise the client?
• Which conflicts, waivers, approvals, and audit records must remain visible?

These questions identify the relationships that matter more than a raw record count.

Preserve the original exports unchanged

Create a read-only migration evidence folder before transforming anything. Keep:

• every original export file;
• export dates and the account used;
• vendor instructions followed;
• report parameters and date ranges;
• screenshots of settings that do not export;
• document archives exactly as received; and
• checksums when practical for large archives.

The source export is the evidence against which later conversion decisions can be tested. Never overwrite it with a cleaned version.

The official Clio migration overview and MyCase export instructions are useful reminders that different categories of information may require separate reports, exports, or document downloads. Read the instructions for the firm’s actual plan and account configuration before setting a cutover date.

Build an inventory before building a mapping

For every source dataset, record:

Dataset	Record count	Key identifier	Important relationships	Attachments	Known limitations
Contacts		Source contact ID	Matters, organizations, addresses		Duplicate names, shared emails
Matters		Source matter ID	Clients, staff, parties, billing	Documents	Closed and archived status
Tasks and events		Source activity ID	Matter, assignee, due date		Recurrence and reminders
Billing		Invoice or transaction ID	Matter, client, payment allocation	PDFs	Trust and operating separation
Documents		File ID or stable path	Matter, folder, version	File bytes	Missing metadata or duplicate names
Custom fields		Field definition ID	Entity type and value		Pick-list meaning and retired fields

Do not begin by forcing every source column into the nearest destination field. First understand what each field meant in daily work.

Treat identifiers as part of the data

Names are poor join keys. Two clients can share a name. One organization can appear under several abbreviations. A matter title can change.

Preserve stable source identifiers even if the destination generates new ones. Maintain a crosswalk:

source system + source entity + source ID -> destination entity + destination ID

That crosswalk allows the migration to reconnect notes, documents, invoices, tasks, and people without guessing from display text. It also makes later corrections repeatable.

Use AI as a mapping assistant, not as the migration authority

AI can help with irregular exports. It can propose that “Atty Resp.” means responsible attorney, normalize date formats, identify likely duplicates, classify document names, and suggest how source custom fields correspond to destination fields.

The useful output is not a silently transformed file. It is a reviewable proposal containing:

• the source value;
• the proposed destination;
• the reason for the mapping;
• a confidence level;
• any competing interpretation; and
• the rule that will be applied to similar records.

Consequential ambiguity should stop for review. Examples include an uncertain client identity, a trust transaction, an unresolved invoice allocation, a conflict waiver, a deadline, or a custom field whose meaning changes across practice areas.

The system should never “make the import complete” by inventing a missing value.

Run a representative test import

Choose a small but difficult sample, not only the cleanest matters. Include:

• an active matter with upcoming deadlines;
• a closed matter with a large document history;
• a matter with several parties and name variants;
• hourly, flat-fee, and retainer billing examples;
• payments, credits, trust activity, and unapplied funds;
• custom fields and uncommon field values;
• recurring tasks or events; and
• a matter with errors or incomplete source data.

Ask the people who perform the work to inspect the imported matters. The migration team may see a populated field. A paralegal may see that it is in the wrong place to drive the next task.

Reconcile more than counts

After the test and final import, compare:

1. record counts by entity and status;
2. source IDs represented in the destination;
3. documents by matter, byte count, and checksum where practical;
4. open tasks and calendar events by date and assignee;
5. invoice, payment, credit, and trust totals;
6. relationship counts, such as parties per matter;
7. custom-field definitions and populated values; and
8. an exception report listing every skipped, altered, or ambiguous item.

A count difference is not automatically an error. Deleted duplicates may be intentionally omitted. What matters is that every difference is explained.

Plan a short controlled cutover

The firm needs a rule for changes made after the source export. Common approaches include a brief read-only period, a final delta export, or a controlled list of changes that will be re-entered and verified.

Assign specific people to check:

• tomorrow’s and next week’s deadlines;
• active client and opposing-party relationships;
• trust and accounts-receivable balances;
• recently changed documents; and
• messages or notes created near the cutover.

Do not cancel access to the old system until the firm has completed its reconciliation, retained required records, and confirmed that the contract allows the remaining access it needs.

Our interest in this question

Data portability is central to the product relationship we want for Usus. A local-first system should make it easier to retain ordinary access to the firm’s information, but local storage alone does not solve migration. Relationships, custom fields, financial history, and documents still need a documented import and export process.

We plan to build an AI-assisted migration workflow that preserves source exports, proposes mappings, exposes uncertainty, produces exception reports, and reconciles the result. It is not implemented yet, so we will not describe migration as automatic or effortless.

The standard we want is more modest and more useful: a firm should be able to see what moved, what changed, what did not move, and why.

Questions to ask any migration provider

• Which source records and files are supported?
• Which relationships are preserved?
• How are custom fields and retired values handled?
• How are trust transactions and payment allocations reconciled?
• Will we receive the mapping rules and source-to-destination crosswalk?
• Can we review a test import before final cutover?
• What exception report will we receive?
• How are record and document counts reconciled?
• What must be re-created manually?
• Can the process be repeated after a correction without duplicating data?

The goal is not a migration with no exceptions. It is a migration in which exceptions cannot hide.