What Law Firms Get Wrong About Document Management Integrations

The first thing you find is that nobody has a complete list of what connects to the document management system.

This is not a knock on the IT department. It's a consequence of how these environments grow. The DMS gets installed. Over the next eight years, someone connects it to the billing system, someone else adds email filing, a vendor product arrives with its own connector, a portal gets built that pulls documents for clients, and a reporting process starts reading from the same database on a schedule nobody wrote down. Each of those was a reasonable decision at the time. Collectively they form an integration surface that exists in no single place, and most of the people who built the individual pieces have moved on.

So when a firm says the DMS is working, what they generally mean is that nothing has visibly broken recently. Those are different claims, and the distance between them is where integration projects go wrong.

The problem is entity matching, not connectivity

The assumption that does the most damage during scoping is that connecting two systems is fundamentally an API problem. iManage has an API. The billing system has an API. Therefore the work is wiring them together and handling authentication.

The API is the easy part. The hard part is that the two systems have no reliable shared identifier for the things they both describe.

The billing system holds the canonical client and matter record — client 4471, matter 4471-0012, with a name, a responsible attorney and a status. The DMS holds workspaces. In principle each workspace corresponds to a matter. In practice, after a decade of operation: workspaces were created before the matter number was issued and named after the client instead. A matter that spanned two offices got two workspaces. A client that went through a name change appears one way in billing and another way in the DMS. A large client has a workspace per practice group rather than per matter, because that's how that group preferred to work in 2016 and nobody revisited it.

Now write the join. There is no key. You are matching on names that don't agree, numbers that are sometimes present and sometimes buried in a description field, and structures that vary by office. This is the actual engineering work in a DMS integration, and it is almost never what the estimate describes.

The estimate typically covers authentication, document retrieval and a user interface. It rarely covers the matching logic, and it very rarely covers what the matching logic should do when it isn't confident.

What breaks in production

The failure mode here is not the one most people brace for.

These integrations rarely fail loudly. What happens instead is that they succeed on the eighty-five percent of records that match cleanly and quietly do nothing on the rest. A user opens a client record, sees no documents, concludes there are none, and moves on. The integration reports no errors, because from its perspective nothing failed — it looked for a match, found none, returned an empty set. That is the specified behavior.

Six months later someone notices that a significant client's documents have never appeared in the interface. By then the integration has been trusted for half a year, and the worse problem is that nobody can say which other records were affected, because non-matches were never logged. Logging them wasn't in the spec.

The firms that handle this well made one decision differently, and it's a small one. They treated unmatched records as a first-class output of the system rather than an error condition. The integration produces a reconciliation report: these matched with high confidence, these matched ambiguously, these did not match at all. Someone owns that report. It gets shorter over time as the underlying data gets cleaned up.

That single decision accounts for most of the difference between an integration that stays trustworthy and one that silently degrades.

What a realistic approach involves

Start with the inventory. Before scoping anything new, establish what already touches the DMS — including the scheduled jobs and vendor connectors nobody thinks of as integrations. This takes longer than anyone wants and it changes the scope of everything downstream.

Then profile the data before committing to a timeline. Take two hundred matters from billing and match them to workspaces by hand. That match rate predicts the project better than any architectural discussion, and it costs a day.

Then build the matching logic with explicit confidence levels and an explicit path for low confidence. Showing a user "three possible matches" is a better outcome than silently picking one, and a much better outcome than silently picking none.

The integration is rarely the risk. The data underneath it is.