Migrating shared drives to a document management system without losing metadata or the audit trail

Why do shared-drive migrations lose information?

A shared drive stores meaning in places a document management system does not look by default. The folder path says which counterparty, department, year or matter a file belongs to. The file name carries a version or a status, such as "final", "signed" or "v3 clean". The modified date tells you when someone last touched it. Folder permissions decide who could see it. None of that is inside the file.

A drag-and-drop upload keeps the bytes and discards most of the context. Dates are reset to the upload time, the folder tree is flattened or rebuilt by hand, and the person who knew why a file sat in "Old - do not use" has moved on. The fix is to treat the migration as a data project with a written record of what moved, from where, in what state, rather than as a file copy.

Step 1: How do you inventory a shared drive before moving it?

Before anything moves, export a manifest: one row per file, generated by a script or the storage platform's reporting, not by hand. It becomes the single reference for every later step and for any question asked after cut-over.

• Full source path and file name, exactly as they stand
• Size, file type and extension, and whether a PDF has a text layer
• Created and last-modified timestamps, and the last-modified-by user where the platform records it
• Owner and the effective permissions on the file and its parent folders
• A cryptographic hash of the file contents (see step 2)
• A migration status column: in scope, duplicate, out of scope, legal hold, migrated, verified

Step 2: Why hash every file before it moves?

A hash is a short fingerprint calculated from a file's contents. Change one byte and the fingerprint changes. Calculating a hash such as SHA-256 for every file in the source manifest, then recalculating it after the file lands in the new system, proves that the migration did not alter the document. A matching pair is the cheapest integrity evidence you will ever produce.

It matters in India because of how electronic records are proved. Under section 63(4) of the Bharatiya Sakshya Adhiniyam, 2023, which replaced the Indian Evidence Act and came into force on 1 July 2024, a party relying on a computer output in a proceeding submits a certificate with the electronic record each time it is submitted for admission. The certificate is in the form set out in the Schedule to the Act, with Part A completed by the party and Part B by an expert. Both parts ask for the hash value of the record and the algorithm used, listing SHA1, SHA256 and MD5 or another legally acceptable standard, with the hash report enclosed.

A migration does not produce that certificate; it is signed when a record is actually tendered. What the migration can do is make the certificate easy to sign truthfully later: a manifest that shows the hash at the source, the hash in the new system, the date of transfer and the system that held the file throughout. Section 57 of the same Act adds that an electronic record produced from proper custody is primary evidence unless it is disputed, so a documented chain of custody is worth keeping.

Step 3: How should duplicates be handled?

Deduplicate on the hash, not on the file name. Two files with identical hashes are byte-for-byte the same and only one needs to be stored, provided the system records every place the file appeared, since the folder it sat in may carry meaning. Two files with the same name and different hashes are different documents, often a draft and a signed copy, and both must survive.

Near-duplicates are the harder case: a Word file and its PDF, or a scan and a re-scan of the same signed page. Do not merge these automatically. Link them as related records or versions and let a reviewer decide which one is the record. Files under a litigation hold, or relevant to a dispute or regulatory inquiry, should be flagged in the manifest and moved untouched, without dedupe or conversion.

Step 4: How do you turn folders into metadata?

Most shared drives follow a pattern, even a messy one: Department / Counterparty / Year / Document type, or Matter number / Correspondence. Write a mapping table that converts each path segment into a metadata field in the new system, and test it on a sample of a few hundred files before running it across the drive.

Keep the original path as a stored field on every record even after mapping. It costs nothing, it lets anyone find a document the way they remember it, and it answers the inevitable "where did this used to be?" question. File-name tokens such as dates, "executed" or a version number can be parsed into fields the same way, with anything ambiguous sent to a review queue rather than guessed.

• Source folder segment → field (for example "Vendors/2019" → counterparty type: vendor; year: 2019)
• File-name tokens → status, version or document date
• Original created and modified timestamps → preserved as separate fields if the new system resets its own
• Unmapped or contradictory paths → review queue, never a default value

Step 5: Should scanned documents be OCR'd during migration?

Yes, but as an addition, not a replacement. OCR creates a text layer so a scanned agreement can be searched and its fields extracted. If the OCR process rewrites the PDF, the new file will have a different hash from the original. Keep the original scan, with its source hash, as the record and treat the OCR output as a derived rendition linked to it.

This also fits section 7 of the Information Technology Act, 2000. Where a law requires documents to be retained for a period, electronic retention satisfies it only if the information stays accessible for later reference, the record is kept in the format in which it was generated, sent or received, or in a format that can be shown to represent it accurately, and details identifying its origin, destination and date and time of dispatch or receipt are available. Keeping the original bytes and the source metadata is the simplest way to meet all three.

Check OCR quality on a sample before trusting search across the archive, particularly for poor scans, handwriting and documents in Indic scripts.

Step 6: How do you map permissions without opening everything up?

Shared-drive permissions tend to accumulate: individual grants added for one request and never removed, "Everyone" groups on old folders, and access held by people who have left. Copying them across faithfully imports the problem. Copying none of them and granting broad access to make the migration easier is worse.

Map from roles instead. Export the effective permissions in step 1, group them into the roles and departments the new system uses, and review the exceptions with the business owner of each area. Records containing personal data deserve particular care, since section 8(5) of the Digital Personal Data Protection Act, 2023 requires a Data Fiduciary to protect personal data through reasonable security safeguards. Run the new access model in parallel for a short period and compare who can see what before switching off the old drive.

What does a safe cut-over look like?

Migrate in waves, one department or repository at a time, rather than in a single weekend. For each wave, freeze changes on the source folders, run a final delta migration of anything modified since the bulk copy, and reconcile.

• Reconciliation report: file count and total size at source against the new system, per folder
• Hash comparison for every migrated file, with mismatches investigated, not overwritten
• Spot checks by the people who use the files: can they find the ten documents they reach for most?
• Source drive set to read-only, not deleted, for an agreed period after sign-off
• Manifest, mapping table, exception log and sign-off archived together as the migration record

Where does a document management system fit?

Most of this work is preparation, and it is the same whichever system you choose. When evaluating a destination, test whether it can import in bulk while keeping original timestamps and paths, record a hash per version, hold metadata fields you define, OCR scans without discarding the original, and keep an audit trail of every view, download and change from the first day. IntelloVault, for example, offers bulk migration of shared drives, OCR of scanned archives, automatic classification and metadata extraction, role-based access, version history, retention rules and audit trails. Whatever you use, run a pilot wave on a real folder before committing the whole drive.

Companies keeping books of account electronically should also check the conditions in rule 3 of the Companies (Accounts) Rules, 2014, which since a 2022 amendment require those records to be accessible in India at all times and backed up daily on servers physically located in India, before choosing where migrated finance records will live.