Structured Data and Database Discovery: Defensible Approaches to ERP, CRM, and SQL Sources

Most eDiscovery protocols are built around documents: emails, files, chat logs, things with a fixed form that can be collected, deduplicated, and reviewed one item at a time. Structured data does not work that way. A record in an ERP, CRM, billing, or manufacturing database is a row of values spread across dozens of tables, assembled on demand by application logic that may change from release to release. When a dispute turns on transaction histories, inventory records, access logs, or financial ledgers, counsel who approach that data with a document-centric playbook often end up with productions that are technically complete and practically unusable, or worse, subject to a motion to compel a redo.

Why Structured Data Breaks the Standard ESI Playbook

A custodian-based collection model assumes a person owns a mailbox or a folder. Database systems are multi-tenant and shared; the same table can hold records for thousands of transactions, only a handful of which are relevant. Native export tools built for the business, not for litigation, frequently strip out audit trails, timestamps, or the relational keys that let a reviewer reconstruct what actually happened. And because the underlying schema is proprietary to the vendor or was customized in-house, opposing counsel cannot meaningfully evaluate a production without some explanation of how the data was modeled and queried in the first place.

None of this excuses noncompliance with the discovery rules. Structured data sources are electronically stored information, and requests for their production are governed by the same standard that applies to any other ESI: relevance and proportionality under Rule 26(b)(1), and the party's right under Rule 34 to specify the form of production. The difference is that meeting that standard for a database requires decisions about queries, filters, and export formats that have no analogue in document review, and those decisions need to be made early and documented.

Proportionality and Rule 26(f) Planning for Database Discovery

Database discovery disputes are disproportionately expensive to litigate after the fact, which makes the Rule 26(f) conference the highest-leverage moment in the case. Waiting until a motion to compel forces a party to defend query logic it never wrote down is a bad position to argue from.

Scoping the Data Model

Before any extraction happens, the parties should be able to answer basic questions: which tables hold the relevant fields, what date range and business units are in scope, whether the schema has changed during the relevant period, and whether derived or calculated fields need to be reproduced or can be recreated from raw inputs. A data dictionary or entity-relationship diagram, even a rough one, does more to narrow a database dispute than another round of boilerplate requests for production.

Extraction Formats and Native Review

Rule 34 gives the requesting party the right to specify a form of production, and the responding party the right to object and propose an alternative if the specified form is not how the information is ordinarily maintained or reasonably usable. For structured data, that usually means choosing between a delimited export, a set of relational tables with keys preserved, or a read-only reporting instance the requesting party's expert can query directly. A flattened spreadsheet export is rarely defensible on its own; it typically discards the relationships that give the data meaning and cannot be re-queried if a dispute arises later about completeness.

Preservation Obligations for Live Databases

Live transactional databases are not static repositories. They get overwritten, archived, purged on retention schedules, or migrated to new platforms as the business continues to run, often on cycles measured in weeks rather than years. A legal hold notice sent to a records custodian does nothing if the underlying database has no field-level hold mechanism and the vendor's default behavior is to age out old records automatically.

Rule 37(e) measures preservation failure against what a party should have done to preserve ESI it had a duty to preserve, and whether it took reasonable steps once that duty attached. For structured data, reasonable steps typically look less like a hold memo and more like a snapshot, a targeted export, or a database-level freeze coordinated with IT before a scheduled purge or migration runs. Counsel who wait for a formal document request before addressing an ERP retention schedule are frequently too late; by the time the request arrives, the relevant records may already be gone, and the question becomes whether that loss was avoidable.

Authentication Challenges for Query Results (FRE 901)

A spreadsheet pulled from a database is not self-authenticating, and a witness who merely received the export from IT cannot always testify to how it was generated. FRE 901 requires evidence sufficient to support a finding that the item is what the proponent claims it is, which for a query result means being able to explain the query logic, the source tables, any filters or joins applied, and why the output matches the underlying records rather than some artifact of how the report was built.

That explanation is easiest to give when the extraction preserves a documented chain from source system to production file, the same discipline that governs any other digital evidence moving from custodian to courtroom.

When to Engage a Neutral or Testifying Expert

Several fact patterns tend to signal that database discovery has outgrown what counsel and the client's IT staff can resolve without technical support:

• The parties disagree about which tables or fields are relevant and neither side can independently verify the other's proposed query
• The system in dispute uses a heavily customized or legacy schema with no current documentation
• Retention or purge cycles create a real risk that relevant records will age out before a protocol is finalized
• A production's completeness or accuracy is challenged and the underlying query cannot be reproduced or explained by a fact witness
• The database itself, rather than documents about it, is the central evidence in the case, such as in financial fraud, billing, or inventory disputes

In contested cases, courts have discretion to appoint a neutral to referee exactly these technical disagreements, which can resolve a database dispute far faster than dueling expert declarations filed on a compressed briefing schedule.

The Sedona Conference and EDRM both address structured data as a distinct category within the broader ESI lifecycle, and their guidance is a useful reference point for counsel drafting an ESI protocol that needs to address database sources specifically rather than by default treating them like file shares.

Bottom line: structured data discovery rewards early, specific planning and punishes improvisation. Counsel negotiating an ESI protocol involving an ERP, CRM, or custom database, or defending a production that is already under attack, should raise the technical questions before they become sanctions motions. The firm's contact page is the place to start that conversation for a matter-specific assessment.