Records Retention and Legal Hold Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does the hold register get scoped without the leaver interlock?

Because the visible problem is the spreadsheet. Counsel describes the pain as chasing acknowledgements and not knowing who is on which hold, so the requirement becomes a hold register with notices and reminders. That is genuinely useful and it is not where the preservation failures come from.

Preservation fails at the seams between legal and everything else. Human resources (HR) marks a leaver, identity management disables the account on a schedule, and a mailbox retention policy deletes it thirty days later. Storage administration decommissions a file share after a migration. An enterprise resource planning (ERP) system runs a purge job written by someone who left years ago. Each is a well behaved process doing exactly what it was designed to do, and none of them has heard of your hold list.

The fix is to bind custodians to identities from your directory rather than to typed names, and to subscribe to lifecycle events rather than reading a report. When a custodian is flagged as a leaver, the system blocks the deletion path and raises a preservation task before the account is touched. When someone joins a team or a role that a matter's scope references, they surface for counsel to add, which closes the opposite gap where new joiners were never preserved at all. Scope this in the first release. A hold register without the interlock is a better spreadsheet, and it leaves the failure mode that actually produces sanctions entirely intact.

What goes wrong when existing holds and custodian lists are migrated?

Every organisation doing this build already has live matters, and those matters cannot pause while the system is stood up. So migration happens under a duty to preserve, which changes what is acceptable.

The source is usually a workbook per matter with names typed by whoever issued the notice, and those names do not resolve cleanly. Some belong to people who have left, which is the population you most need to know about and the one a spreadsheet is least likely to have kept current. Some are ambiguous because two people share a name. Some scopes are described in prose, covering the Northgate project files without naming a repository, a path or a date range. And there is frequently no record of who acknowledged, so you inherit holds whose evidentiary position is unknown.

The fix is to migrate the hold as a new record with an explicit provenance marker rather than pretending the system has always held it. Resolve every custodian to a directory identity with a human deciding ambiguous cases, and produce an exception list of names that cannot be resolved, because that list is the actual risk report and it should go to counsel rather than into a backlog. Where acknowledgement history is missing, record it as unknown rather than as absent, and consider reissuing the notice through the new system so you have a clean evidentiary position going forward. Never let migrated assertions look identical to facts the system observed.

Why do repository connectors break after launch?

This is where builds in this category get real, and where they decay fastest. Preservation semantics differ in every system you touch. Microsoft 365 has native hold mechanisms that work well for mail, Teams and SharePoint with the right licensing. Google Workspace has its own model, and Slack retention and export behaviour depends heavily on plan. A file server has none of this and needs either a copy into a preservation store or a permission and job level block. Line of business systems have purge jobs with no interface at all.

They break for ordinary reasons. A licence tier changes and a preservation capability silently stops being available. A tenant policy is updated and overrides what the connector set. A file share is migrated and the paths in the hold scope no longer exist. An application is upgraded and its purge job is reinstated with default settings. The dangerous part is that none of these announce themselves, and a hold that is no longer in force looks exactly like a hold that is.

The fix is a connector contract with four operations for every repository: place a preservation, verify it is still in force, release it, and report what is covered. Verify is the one that matters and the one most often skipped. Run it on a schedule and alert on any preservation that cannot be confirmed. Where preservation cannot be applied technically, the system must show an explicit unsupported state with a recorded compensating control, never a green tick. A false green is worse than a known gap, because counsel will rely on it in a certification.

What happens when retention triggers and the disposition interlock are missing?

The quieter failure in this category is that nothing is ever deleted. It looks like caution and it is an accumulating liability: storage cost that grows every year, every byte discoverable in the next matter, and personal data kept with no remaining purpose, which is its own exposure under privacy obligations.

It happens because disposition requires trusting two facts at once. The retention period has elapsed, and no hold covers the record. If either is uncertain, keeping everything is the rational choice, and when hold data lives in a spreadsheet the second fact is never certain. So the interlock is the product, not a feature of it.

The trigger side is where retention builds actually overrun. A period that starts at record creation is easy. A period that starts at contract termination, employee separation, product end of life or final payment requires that event to be pulled from an operational system, and that integration is the real work in a retention project. Teams scope the schedule engine, model record classes and jurisdictions carefully, then discover that half their retention rules cannot fire because nothing tells the system when the trigger event happened.

The fix is to evaluate every disposition candidate against active holds at record level rather than system level, route a review list with the reasoning attached, capture approval from the record owner and legal, execute through the repository connector, and write an immutable certificate of destruction naming what was disposed, under which schedule entry, approved by whom and when. That certificate is what you produce when a regulator asks why a record no longer exists, and it is the difference between routine disposition and spoliation.

Should you build custom or configure what you already own?

If you run a handful of matters a year, your data lives almost entirely in Microsoft 365, and your licensing includes the native hold features, use them with a documented process and a diligent paralegal. That is proportionate and honest, and a build would be an expensive way to formalise something that already works. If you already run Relativity for review, its hold module is a sensible adjacent purchase rather than a project. Exterro is strong on the litigation side. Zasio Versatile is genuinely good at retention schedules and the research behind them, and buying a maintained schedule is often better value than building one.

Build when two or more of these are true. Your business records live in line of business systems that no packaged tool connects to, which is the usual situation in manufacturing, energy and financial services. You operate across jurisdictions with genuinely different retention schedules and entity structures. Your leaver process has already destroyed data under hold, or you cannot prove it has not. Counsel has told you your preservation cannot be demonstrated. Or you are carrying storage and discovery cost because disposition has never once run and nobody will authorise the first deletion.

A hybrid is often right: buy the retention schedule content, build the interlock and the connectors.

How do hidden costs get into the quote?

A focused first release covering matters and holds, custodians bound to directory identity with leaver interception, notices with acknowledgement and escalation, scope definition and a full audit trail runs $80,000 to $160,000 over 12 to 18 weeks in our delivery experience. A full platform adding the retention schedule engine with triggers and jurisdictions, preservation and disposition connectors, the disposition review workflow with certificates, physical records and reporting runs $200,000 to $450,000 over 7 to 12 months. The overruns come from a predictable list.

• Repository count, and specifically the awkward ones. Collaboration platforms are the easy half. The line of business systems where your actual business records live are each their own investigation before they are an integration.
• Licensing. A technically simple preservation can be commercially expensive if it requires a tier upgrade across a large user population, and that cost belongs in the business case rather than appearing after design.
• Retention schedule research. Each jurisdiction adds record classes and citations that need legal input rather than engineering, and organisations without an approved schedule are buying a legal project alongside a software one.
• Trigger event integrations, which are the part of retention most often discovered late and which reopen the data model when they are.

What separates a build that works from one that fails here?

Ask a prospective developer what happens when a custodian leaves the company. If the answer does not involve intercepting the leaver process before the account is deleted, they have not built this before and your first real test will fail.

Ask how they will represent a repository where preservation cannot be technically enforced. The correct answer is an explicit unsupported state with a recorded compensating control. Anyone comfortable showing a green tick by default should be disqualified on that answer alone, because counsel will certify against it.

Ask which preservation connectors they have written by name, and what they did about the systems with no interface. Microsoft 365, Google Workspace, Slack, a legacy file server and an archive job inside an enterprise resource planning system are five different problems with five different answers.

Keep the scope boundary explicit. This is a governance layer, not an ediscovery platform. Collection, processing, review and production are a separate discipline with mature products, and scope creep in that direction is the main way these projects overrun. Build holds and the leaver interlock first, then retention and disposition once the hold data is trusted, because nobody will authorise a deletion against data they doubt.

Settle code ownership in writing before kickoff. You should own the repository, the infrastructure accounts and the right to hire anyone else to continue. At Digital Heroes the client owns the code from the first commit. The audit trail this system produces will be relied on in litigation and regulatory examinations for years, and the ability to move it, inspect it and maintain it independently is part of the control rather than a commercial preference.