Why Shared Drives Stop Working

Shared drives work well for a long time and then stop, and the transition is gradual enough that the cause is usually misattributed to the people using it.

It is not a discipline problem. The failures are structural, and each one gets worse with scale.

There is no way to express which version is authoritative#

A folder can hold contract.docx, contract-v2.docx, contract-final.docx and contract-final-signed.docx. Nothing in the filesystem indicates which one governs.

Naming conventions attempt to encode authority in the filename, which works until two people create a v3 on the same afternoon. The filesystem has no concept of a current version, so authority has to live in someone's memory — and it does, until they leave.

You cannot evidence who read a document#

A shared drive records that a file was accessed, if auditing is even enabled. It does not record that a named person read a specific revision of a specific document and acknowledged it.

For most content that does not matter. For a safety procedure, a policy, a controlled work instruction or anything with a training requirement, it is the whole point — and it is the question an auditor or an investigation asks first.

Retention cannot be applied#

A retention rule needs to know what a document is. A filesystem knows a path, a size and three timestamps.

Which means retention on a shared drive is either not applied, or applied by path — and paths get reorganised. In practice, nothing is ever deleted, because nobody is willing to be the person who deleted something they could not identify. The drive becomes an indefinite archive by default rather than by decision.

The permission model degrades monotonically#

Folder permissions start clean. Then someone needs access to one subfolder, so inheritance breaks. Then a contractor needs one folder, so a group is created. Then a reorganisation happens and the groups no longer describe anyone.

After a few years the effective access set is not documented and not reconstructable by inspection. This matters concretely at the moment somebody asks who can see the HR folder, or when an access review is required, and the honest answer is that nobody knows.

Crucially, this degradation is one-directional. Exceptions accumulate; they do not get cleaned up.

Search finds filenames#

Filesystem search matches names and, with indexing, some content. It does not match on document type, status, owner, effective date, contract counterparty or retention class — because those attributes do not exist.

So finding the current version of the master services agreement with a particular supplier means knowing where somebody put it. Which is why the fastest search on most shared drives is asking a colleague.

Nothing prevents a copy#

The standard response to "I cannot find it" is to save a copy somewhere findable. Now two exist, they diverge, and both look authoritative.

The shared drive offers no alternative to copying, because there is no way to reference a document in place that survives the document being moved. A hyperlink to a network path breaks the moment anyone reorganises a folder, so the durable option is to duplicate — and duplication is the mechanism by which every other failure above compounds.

What actually replaces it#

Not a tidier folder tree. Four things the filesystem cannot provide.

Document identity, so a document has a number and a current version that is unambiguous regardless of where it sits. Metadata, so retention, permission and search operate on what a document is rather than where it is. An audit trail, so read, change and approval are evidenced against named people and specific revisions. And permissions derived from role and document type rather than from folder position, so the model can be explained without archaeology.

Where to start#

Not with a full migration. Take the document set with a genuine governance requirement — contracts, policies, quality procedures, personnel files — and move that one first.

It is the set where the shared drive's limitations cost the most, which makes it the set where the replacement demonstrates its value fastest. The rest can follow once the model is proven, and some of it never needs to move at all.

Whatever you move, set the source read-only rather than leaving it writable alongside the new system. Two writable homes for the same document produce two divergent versions within weeks, and the resulting confusion gets attributed to the new system rather than to the decision to run both.