Migrating to a new asset library without losing the metadata

The loss is rarely announced. Nobody gets an error. The new system opens, the thumbnails are all there, and it takes three weeks before somebody notices that a search which used to return six frames now returns none.

Inventory before anything else

The first task is not moving anything. It is finding out what you have.

Count the assets by format, by size band, and by age. Then — and this is the part that gets skipped — enumerate the metadata fields actually in use, with how many assets have each field populated. Not the fields the schema offers: the fields people filled in.

That count tells you what is worth carrying. A field populated on 3 per cent of assets is a field somebody tried once; a field populated on 90 per cent is load-bearing. Migration effort belongs on the second kind.

Export the inventory to a plain format — CSV or XML — and keep it outside both systems. It is the only independent record of what the old library contained, and it is what you will check the new one against.

Map the fields explicitly

Write a field-by-field mapping from source to target before touching the data: source field, target field, transformation if any, and what happens when the source is empty.

Three kinds of mismatch need decisions:

Fields with no target. Either extend the target schema or accept the loss deliberately and record it. What must not happen is silent discard.

Fields that merge. Two source fields landing in one target field will collide. Decide the join rule, and check a sample of the ugliest cases before committing.

Fields that split. A free-text field being decomposed into structured values will partially fail. Decide where the failures go — a holding field, not the bin.

Vocabulary needs the same treatment. If the old library used free keywords and the new one uses a controlled list, the mapping between them is a piece of editorial work, not a script. Automating it produces terms that look right and retrieve nothing.

Relationships are metadata too

The thing most often lost is not a field at all. It is the structure between assets.

Versions and their order. Derivatives and the master they came from. Cropped variants and the original frame. Groupings by assignment. Permissions attached to collections rather than files.

None of these survive a file-level copy. Each has to be identified in the source, expressed in a form the target understands, and verified afterwards. A migration that preserves every field and no relationships produces a library of orphans.

Migrate a sample, then check it properly

Pick a few hundred assets that between them exercise every hard case: the oldest files, the biggest files, assets with full metadata, assets with almost none, assets in the messiest part of the old vocabulary, assets with several versions, assets with restricted access.

Run the full migration on that sample. Then check the result against the inventory export, field by field, not by looking at thumbnails.

The checks that matter: is every asset present, is every populated source field populated in the target, do the controlled terms resolve, do the version chains still chain, and do the access restrictions still restrict. That last one is worth a dedicated pass — permissions that quietly widen during a migration are a genuine risk and nothing in the interface will flag it.

Run in parallel, cut over once

Keep the old library readable while the new one fills. Not writable — that is how the two diverge — but readable, so that anything missing can be looked up rather than reconstructed.

Freeze writes to the source before the final pass. Anything added during the migration window has to be handled separately, and the simplest way to have nothing to handle is to have nothing added.

After cutover, keep the old system available for longer than feels necessary. The gaps surface on a delay, because they surface when somebody searches for something specific, and most assets are not searched for in any given month.

The people, not only the data

The person who knows why the old schema is shaped the way it is frequently leaves during or just after a migration. That knowledge is not in any export.

Write it down while they are there: what each odd field was for, which conventions changed and when, which parts of the vocabulary are historical and which are current. An hour of interview is worth more than a week of forensics later.

Conclusion

Inventory what is actually populated, map every field explicitly including the ones you will drop, treat relationships and permissions as migratable data, prove it on a hard sample against an independent export, and keep the old library readable well past cutover. The files were never the risk. The descriptions were.