How to Migrate Legal Documents from Shared Drives

Definitions

Practical workflow

1. Set scope, owners, and decision authority

   Define the shared drives, folders, offices, matters, document types, date boundaries, client populations, connected systems, and target workspaces in scope. Name the migration lead, matter or business owners, records owner, security owner, and acceptance approvers. Record who may approve exclusions, ROT decisions, access changes, retention treatment, and rollback.

2. Discover every source and access path

   Inventory mapped and unmapped shared drives, personal folders, departmental shares, archive shares, synced local folders, collaboration links, email attachments, backup exports, and integrations that may contain the same documents. Capture source path, repository owner, storage platform, access groups, file count, byte count, extensions, last-modified distribution, link targets, and extraction limitations. Treat an undocumented source as an open discovery exception.

3. Freeze the baseline and preserve provenance

   Create a dated manifest for every in-scope file with a stable source identifier, full path, file name, size, modification time, source owner, permissions, version indicators, and extraction status. Calculate a collision-resistant content hash using an approved algorithm and record the hash method and tool version. Preserve the manifest and source export as migration evidence before cleanup or transformation changes the population.

4. Assign matter, business, and records ownership

   For each folder and file set, identify the client or internal entity, matter or project, responsible lawyer or business owner, office, practice area, jurisdiction, confidentiality level, and records owner. Separate folder stewardship from substantive approval when appropriate. Route unknown, conflicting, closed-matter, and cross-matter ownership to a named queue instead of guessing from a filename.

5. Classify ROT with an approved decision rule

   Identify exact duplicates, near duplicates, obsolete drafts, temporary working files, generated copies, empty folders, stale exports, personal material, and trivial content. Check legal holds, retention schedules, client instructions, regulatory duties, active matters, appeals, investigations, and audit needs before exclusion or disposition. Keep the source item, evidence, decision, approver, date, and destination or disposition reason visible in the exception register.

6. Define the target metadata dictionary

   Map source fields and folder signals to canonical target values for matter, client, legal entity, document type, owner, status, effective or filing date, jurisdiction, confidentiality, privilege or work-product indicator where approved, retention class, source repository, source path, migration batch, and review state. Define requiredness, controlled values, null meanings, transformations, provenance, validation, and an exception path for every field.

7. Design permissions and ethical-wall behavior

   Build an access matrix for matter teams, offices, practice groups, records staff, administrators, client contacts, integrations, and restricted matters. Map source groups to target roles and test inherited, direct, external, temporary, and denied access. Remove broad folder assumptions, document the owner for every exception, and verify that search, previews, notifications, exports, downloads, and administrative views do not disclose restricted content.

8. Preserve versions and document relationships

   Determine how drafts, redlines, comments, executed copies, amendments, exhibits, schedules, and superseded files are represented in the target. Use stable source identifiers and version order rather than names such as final-final. Record current-version state, parent-child links, author and timestamps where available, source path, and any conversion or rendering event. Keep unresolved relationships in an exception queue.

9. Prepare a dry-run package and migration batches

   Create a versioned mapping, exclusion list, permission matrix, target taxonomy, runbook, validation plan, support plan, and rollback decision tree. Divide the population into small representative batches by matter, office, repository, or risk. Include simple files, long version chains, restricted matters, scanned documents, unusual formats, large files, duplicates, and records with incomplete metadata in the pilot.

10. Run the pilot and reconcile results

    Load a representative pilot without changing the source. Compare source, extracted, transformed, loaded, rejected, excluded, and target counts. Reconcile file sizes and hashes where byte identity is expected, then explain legitimate transformations such as format conversion or normalization. Sample metadata, permissions, version order, links, search, previews, downloads, and audit events. Record every variance with evidence, severity, owner, and disposition.

11. Validate full batches before release

    Repeat the manifest and reconciliation process for each approved batch. Confirm that all included files have a target identifier, target location, owner, metadata status, access result, version state, and validation outcome. Review hash mismatches, missing files, duplicate decisions, permission differences, corrupt or unreadable files, inaccessible sources, and late source changes before moving the batch to cutover.

12. Execute a staged cutover with delta control

    Communicate the batch window, user actions, support route, and source behavior. Make the source read-only or use an approved change ledger, then capture and apply the final delta before enabling target use. Perform smoke tests for representative users and restricted matters, monitor errors and access, and stop the batch when a defined go or no-go threshold is missed. Keep an immutable record of the cutover sequence and timestamps.

13. Use explicit rollback criteria and boundary

    Before each batch, define what triggers a stop or rollback, such as missing high-value files, unexplained hash variance, incorrect restricted access, broken version relationships, unacceptable metadata loss, corrupted files, or failed acceptance scenarios. State the recovery point, target quarantine or removal procedure, source availability, late-change handling, communications, and who can authorize rollback. Do not assume every post-cutover user action can be reversed.

14. Accept, monitor, and retire the source deliberately

    Obtain named acceptance from the document owners, records or legal operations owner, security owner where relevant, and technology lead. Acceptance should reference reconciled counts, hash and exception reports, permission tests, version samples, unresolved risks, rollback expiry, and support ownership. Keep the source read-only for the approved observation period, monitor late discoveries and access issues, then retire or dispose of it only under the applicable policy and documented approval.

Comparison

Limitations and exceptions

• A file inventory is only as complete as the sources and access paths that were discoverable. Local copies, offline folders, personal storage, backups, email, and unregistered collaboration links may remain outside the declared scope.
• A content hash can show that two byte streams match or differ under the selected algorithm and process. It cannot establish that the file is the correct legal record, that metadata is accurate, or that a missing related document was discovered.
• ROT classification is not a safe proxy for legal irrelevance. Obsolete drafts, duplicates, and temporary files can carry evidence, client instructions, audit context, or preservation significance.
• Permission migration depends on identity, group, matter, office, external-user, integration, and target-platform behavior. A mapped role or configuration export does not prove that real users receive or are denied the intended access.
• Format conversion, OCR, preview generation, decryption, compression, or normalization may intentionally change file bytes. Record the transformation and validate readability and meaning rather than treating every hash mismatch as a failure.
• Rollback may not undo downloads, edits, notifications, links, downstream integrations, or business decisions made after a batch is released. Define the recovery boundary and communication plan before cutover.
• NARA records-management requirements and NIST standards are authoritative references for the scopes they govern; they do not prescribe one private-firm taxonomy, retention schedule, migration tool, or acceptance threshold.
• This guide is an operational planning aid, not legal advice, a records-management certification, a security certification, or a guarantee that a particular migration satisfies a client, court, regulator, insurer, or jurisdiction.

Primary sources

Methodology

This guide uses an organization-designed migration method. The cited NARA materials provide federal records-management references for lifecycle, metadata, transfer, relationships, and preservation context; NIST provides reference points for hash use, access control, auditability, contingency, system integrity, and assessment. None of those sources prescribes the exact taxonomy, ROT rule, batch size, hash reconciliation threshold, rollback boundary, or acceptance criteria for a private legal organization. Start with a versioned scope statement and source inventory, then freeze a manifest containing stable identifiers, paths, owners, permissions, versions, file sizes, timestamps, formats, and hashes. Build a decision register for ownership, duplicate and ROT treatment, exclusions, retention, legal holds, client instructions, and unreadable or restricted content. Define canonical metadata and permission mappings before loading. Preserve version relationships and source provenance, and distinguish byte-level equality from semantic or legal correctness. Run a representative dry run, reconcile full counts and material segments at every stage, investigate hash and metadata variances, test access and search with real role scenarios, and retain evidence for each exception. Cut over by controlled batch with a source-freeze or delta procedure, smoke tests, monitoring, stop criteria, and an explicit recovery boundary. Acceptance should name approvers, evidence, residual risk, open exceptions, support ownership, and source-retirement conditions. Have qualified legal, records, security, and business owners adapt the method to applicable law, client obligations, retention policy, and matter facts.

FAQs

Related CaseDocker capabilities

Related guides and resources

• Law firm document management software fit guide
• Legal document naming conventions
• Legal document version control policy
• Legal document OCR and search requirements