Records Retention and Legal Hold Software: Can You Prove You Preserved It?

Why holds and retention are the same system, and why splitting them fails

Opposing counsel asks when the hold was issued, to whom, what it covered and whether anything was deleted after the duty to preserve attached. In house counsel opens a spreadsheet. It has fourteen names. Two of them left the company nineteen months ago and their mailboxes were deleted under the standard leaver process, because the leaver process has no idea what a legal hold is. One custodian never acknowledged, and there is no record of a reminder being sent. The shared drive folder named in the hold was migrated to a new platform last year and the original path no longer exists. Nobody can say whether the ERP (Enterprise Resource Planning) records covered by the hold were purged by a scheduled archive job.

That is a spoliation exposure, and the frustrating part is that it was created entirely by administrative gaps rather than by anyone hiding anything. Preservation failures rarely look like misconduct. They look like a leaver process, a migration and a scheduled job.

The reverse failure is quieter and equally expensive. Nothing gets deleted. Ever. Because disposition requires knowing that a record class has hit its retention period and that no hold covers it, and since nobody trusts the hold data, the safe move is always to keep everything. So the company holds twenty years of email at increasing cost, every byte of it discoverable in the next matter, and the privacy team quietly notes that keeping personal data with no purpose is its own exposure.

The market here is real. Exterro and Relativity Legal Hold are strong on the litigation side. Zasio Versatile is genuinely good at retention schedules and the research behind them. OpenText Records Management and Iron Mountain Policy Center come from the records management tradition. The reason enterprises still build is that the hard part is not the hold interface, it is reaching into your specific estate of mail, file shares, collaboration tools, line of business systems and physical records, each of which has different preservation and deletion semantics, and enforcing an interlock between the retention schedule and the hold list that actually works.

Problem one: the custodian list is a snapshot of a moving population

People join, leave, transfer, change managers and change systems. A hold issued eighteen months ago against a named list is stale the week after it is issued. Two failures follow. Departing custodians lose their data to a routine leaver process that never checked the hold register. New people who join the relevant team are never added, so their data was never preserved, and that gap surfaces at the worst moment.

What a custom build does: bind custodians to identities from your directory, not to typed names, and subscribe to lifecycle events. When a custodian is flagged as a leaver, the system blocks the mailbox and account deletion path and raises a task to preserve before the account is touched. When someone joins a team or a role that a matter's scope references, they are surfaced for counsel to add. The hold list becomes a live population with a documented history of who was on it when, which is the record you actually need to produce.

Problem two: acknowledgement is evidence, and email is not a system

Sending a hold notice is easy. Proving that a specific person received it, read it, understood the scope and was reminded periodically is the part that gets tested. So is proving that you escalated non responders to their manager, and that you re issued when the scope changed.

What a custom build does: treat each notice as a versioned document, each issuance as a delivery record with timestamps, each acknowledgement as a signed attestation captured with identity, and each reminder as a scheduled event with escalation rules you define. Questionnaires attach to the notice where counsel wants custodian interviews on the record, and answers are stored as evidence rather than as email text. Release is handled with the same rigour as issuance, because releasing a hold that should have stayed in place is the failure nobody writes procedures for.

Problem three: preservation in place is different in every repository

This is where builds get real. Microsoft 365 has native hold mechanisms and they work well for mail, Teams and SharePoint if you have the right licensing. Google Workspace has its own model. Slack retention and export behaviour depends heavily on plan. A file server has none of this and requires either a copy to a preservation store or a permission and job level block. Your ERP and line of business systems have archive and purge jobs written by someone who left in 2019. Physical records in a warehouse have a box level inventory and a destruction schedule run by a vendor.

Off the shelf hold tools connect to the big collaboration platforms well and stop there. The line of business systems, which is where the actual business records live in a manufacturing or financial services company, are yours to solve.

What a custom build does: define a connector contract per repository with four operations, namely place a preservation, verify it is in force, release it, and report on what is covered. Then implement per system honestly, including the unglamorous case where the only available mechanism is suspending a scheduled purge job and logging that suspension. Where preservation cannot be applied technically, the system should say so explicitly and record the compensating control rather than showing a green tick that means nothing. A false green is worse than a known gap, because counsel will rely on it.

Problem four: the retention schedule is a legal research artefact, not a config file

A retention schedule maps record classes to periods with a citation, and the citation matters because the period differs by jurisdiction, by record type and sometimes by the entity that created the record. Employment records, tax records, safety records, clinical records, trading communications and product records all follow different rules, and multinational groups carry several versions of each.

What a custom build does: model record class, jurisdiction, citation, retention period, trigger event and disposition action as data with version history. The trigger matters more than people expect. A period that starts at record creation is easy. A period that starts at contract termination, at employee separation, at product end of life or at final payment requires the trigger event to be pulled from an operational system, which is the actual integration work in retention projects.

Problem five: disposition never happens without an interlock people trust

Nobody deletes anything until they trust two facts simultaneously: the retention period has elapsed, and no hold covers the record. If either fact is uncertain, the rational choice is to keep it. So the interlock is the product.

What a custom build does: evaluate every disposition candidate against active holds at the record level, not the system level, produce a disposition list for review with the reasoning attached, capture approval from the record owner and legal, execute deletion through the repository connector, and write an immutable certificate of destruction listing 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 having it is the difference between routine disposition and spoliation.

What this costs and how long it takes

Across the regulated enterprise work Digital Heroes has delivered, this is the honest shape. A focused first release, meaning matters and holds, custodian binding to directory identity with lifecycle interception, notices with acknowledgement and escalation, scope definition and full audit trail, runs $80,000 to $160,000 and ships in 12 to 18 weeks. That alone closes the most dangerous gap, which is the leaver whose mailbox disappears.

A full platform adding the retention schedule engine with triggers and jurisdictions, repository connectors for preservation and disposition, the disposition review workflow with certificates, physical records handling, and reporting for outside counsel and regulators runs $200,000 to $450,000 phased over 7 to 12 months.

What pushes cost up here specifically: the number of repositories, since each connector is real work and the awkward ones are always the line of business systems rather than the collaboration platforms. Licensing constraints in Microsoft 365 and Google Workspace, which sometimes make a technically simple preservation commercially expensive. Multinational retention schedules, because each jurisdiction adds record classes and citations that need legal input rather than engineering. Physical records, if warehouse boxes are in scope. And migrations happening in parallel, which is a genuine risk: preserving data that is being moved between platforms during the build requires coordination nobody enjoys.

What keeps cost down: start with holds and the leaver interlock, which is where the exposure concentrates, and phase retention and disposition afterwards once the hold data is trusted.

Build versus buy, and when buying is the right call

Buy, and do not call us, if you run a handful of matters a year, your data lives almost entirely in Microsoft 365, and you have the licensing that includes native holds. Native features plus a documented process plus a diligent paralegal is proportionate and honest. Similarly, if you already run Relativity for review, its hold module is a sensible adjacent purchase rather than a build.

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

A note on scope discipline: this is not an ediscovery platform. Collection, processing and review are a different problem with mature products, and building your own is a bad idea. Build the governance layer, integrate with review tools, and stay out of that lane.

How to choose a developer for legal hold and retention systems

Ask them 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, never a green tick by default. Anyone comfortable showing false assurance to counsel should be disqualified on that answer alone.

Ask which repositories they have written preservation connectors against by name, and what they did about the ones with no API. Microsoft 365, Google Workspace, Slack, a legacy file server and an ERP archive job are five different problems.

Ask who owns the code and get it in writing before kickoff. You should own the repository, the infrastructure accounts and the right to hire anyone else to continue the work. At Digital Heroes the client owns the code from the first commit. The audit trail this system produces will be relied on in litigation for years, and it must live somewhere you control absolutely.