Every team that outgrows a shared drive believes the problem is theirs. Better naming, a cleaner tree, one more all-hands about where things go. It never works, and it is not a discipline failure.

Short answer: cloud storage models a hierarchy. Asset work is not hierarchical. An asset belongs to a campaign, a product, a market, a channel and a legal status at once, and a folder can only express one of those. The moment your second dimension appears you start duplicating, and every downstream failure follows from that. Systems built as asset stores rather than file stores attach those dimensions as fields on the asset instead, which is why one copy stays one copy.

The failure sequence

It always runs in the same order.

One: duplication. The autumn campaign shot also belongs to the shoe category and also belongs to the German market. Three folders, three copies, or one copy and two shortcuts nobody maintains. Six months later nobody can tell which of the four visually identical files is the master.

Two: approval collapse. A file has no state. There is no field on it that says legal cleared this on 12 March and the licence runs out in November. So the state lives in a filename suffix (_FINAL_v3_approved), in a spreadsheet, or nowhere. All three degrade, and the third is the default.

Three: retrieval. Search in a drive matches filenames and, on a good day, text inside documents. It does not match what a photo shows. You cannot ask for the product shots on a white background, in landscape, cleared for paid social, that are not already used on the homepage. That is one query in a DAM and an afternoon of scrolling in a drive.

Four: derivation. Somebody needs a 1:1 crop for Instagram. They make one, save it next to the original, and now you have five aspect ratios of the same photo, all stored, all diverging, none of them regenerable when the master is retouched.

Why can't better folder discipline fix this?

Because the constraint is structural, not behavioural.

A folder path is a single string. It encodes exactly one classification, chosen at save time, by whoever was saving. Assets have several classifications that are all equally valid and several that change after the file is created. Approval state changes. Licence expiry arrives. A product gets discontinued. A path cannot change retroactively across every copy, and nobody goes back to rename anything.

Metadata does not have this problem. A field can hold many values, can be edited without moving anything, and can be queried across every dimension at once. This is why metadata is the whole product and why the folder tree in a good DAM is a convenience view rather than the storage model. Cloudinary, for example, keeps folders, collections and sharing as organisational surfaces layered over an asset store that does not depend on them.

You can prove the limit to yourself in five minutes. Take any asset in your drive and try to answer four questions from the file alone: who shot it, what licence covers it, which version is current, and where it is currently published. If you cannot, the folder is not the system of record. Something else is, and that something is probably a person.

What actually survives the move

Two things people underestimate.

Embedded metadata is portable. IPTC fields and XMP live inside the file, not in the platform. If your photographers have been filling in creator, description and rights properly, that data comes with you and gives a new system something to index on day one. You can check what is already there with ExifTool before you assume the worst.

Folder paths are metadata in disguise. Twenty years of 2019/Q3/shoes/berlin-shoot/retouched/ is a badly encoded set of fields. Year, quarter, category, shoot, state. That maps cleanly, and it is the single highest-value thing you can do first when migrating off shared drives.

The honest counter-argument

A shared drive is genuinely the right answer more often than DAM vendors admit.

If your whole media library is a few hundred files, produced by one or two people, used in one place, with no licensed third-party material and no external distribution, a drive plus a naming convention is cheaper, faster and understood by everyone already. Buying a platform for that is buying a process nobody asked for, and the library will be abandoned within a quarter.

The threshold is not file count. It is when the answer to "can I use this" stops being obvious to the person holding the file. That is usually the moment a second team, an agency or a legal review enters the picture. There is a fuller test in do you need a DAM yet, and the cost comparison, including what the drive is quietly costing you in re-shoots and rework, is in what a DAM costs.

The practical read

Storage is not the thing you are buying. You can get object storage for close to nothing and the price keeps falling. What you are buying is the ability to ask a question about an asset and get an answer without a human in the loop.

Every failure in the sequence above is the same failure wearing a different hat: the file does not know anything about itself, so a person has to know it instead, and people leave. If you want the underlying model rather than the symptom list, start with what digital asset management actually is.