Media Archive Preservation Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does the scope get written as a catalogue instead of a prioritization engine?

Archive briefs almost always describe a catalogue. Records, fields, search, an interface for cataloguers. It is the most familiar shape, most archives already have a collections database, and the request is usually phrased as replacing or improving it.

The question the institution actually needs answered is different: for a given amount of money and time, which items should we do next, and what will we legally be able to do with them afterwards. A catalogue cannot answer that. Prioritization needs three structured inputs multiplied together, decay risk, content value and clearability, and most archives have a partial answer to the second and nothing structured for the first or third.

This is specific to moving image collections because the constraint is not storage cost. It is that the intersection of a playable carrier, a working deck and a person who can operate it is closing on a schedule nobody controls. Acetate keeps hydrolyzing whether or not it is high on your list, magnetic binders keep absorbing moisture, and the pool of engineers who can service certain machines keeps shrinking.

The fix is to specify the prioritization model first and treat the catalogue as an input to it. Ask a developer to whiteboard the data model before you sign: the intellectual work, the manifestation, the physical carrier and the digital instantiation as separate things, because one work can have six carriers of differing quality and three digital copies of differing provenance. A developer who draws assets and files has built a document store and will discover the difference on your programme.

What goes wrong when you migrate decades of catalogue records?

Retrospective data cleanup is the most underestimated line in this category, and it is underestimated because it looks like a data transfer. What is actually there is decades of inconsistent title, series and episode identification, created by different cataloguing conventions under different departmental owners, with several eras of local shorthand embedded in free text fields.

The failure modes are concrete. The same series appears under three titles, one of them a working title that only ever existed internally. Episode numbering restarts mid run because a season was renumbered for a repeat. Shelf locations reference a store that closed in the 1990s. Carrier type sits in a notes field as prose, so the phrase one inch means a tape format in some records and a physical measurement in others. Condition, where it exists at all, is a sentence written by a technician who has retired.

Import that and the prioritization queue inherits every ambiguity, so conservators will not stand behind it, and a ranking nobody will defend in a funding meeting is worth nothing.

The fix is to scope cleanup as its own phase with cataloguers and conservators assigned to it, and to resist the temptation to clean everything. Pick one collection and one carrier family, agree the controlled vocabulary for carrier types and condition fields with the people who will use them, and migrate that slice properly. Leave the rest readable in place. A prioritization engine that is correct for a quarter of the holdings is immediately useful. One that is approximate across all of them is not.

Why do repository and asset management integrations break after launch?

Most archives end up running three systems: a preservation repository underneath for storage, fixity and format management, a media asset management platform for access copies and editorial metadata, and the operational layer that covers condition, prioritization, vendor workflow and rights. The integrations between them fail on ownership of fields rather than on connectivity.

The pattern is predictable. Two systems both believe they hold the authoritative title. A cataloguer corrects a record in one, an editor corrects it differently in the other, and a synchronisation job dutifully propagates whichever ran last. Identifiers drift because one system mints its own on ingest and the other was given an external identifier during a migration nobody documented. Technical metadata extracted at ingest gets written to one system and never reaches the other, so the same file has a frame rate in one place and nothing in the other.

The fix is to write down, before any code, which system owns each field, and to make every other copy explicitly derived and read only. Give every item a single persistent identifier minted in one place and carried everywhere. Then instrument the synchronisation: log every field that changed, in which direction, and surface conflicts as a review queue rather than resolving them silently. Archives think in decades, and a synchronisation that quietly overwrites is a slow corruption of the record.

What happens when per item rights clearance is not covered?

Rights get left out of scope more often than any other requirement here, usually because they feel like a legal matter rather than a software one. The consequence is the failure named at the top of this page: digitized material that cannot be licensed, streamed or exhibited, discovered after the money is spent.

The structure of the problem is that clearance is several independent questions that must all return yes. Music cues cleared for original broadcast only. Performer and contributor consents written before digital distribution existed. Third party footage licensed for a term that expired decades ago. Underlying literary rights. Each has its own evidence, its own territory and its own expiry.

The fix is to make clearance a structured status per item with the evidence attached: the cue sheet, the contract page, the consent form, the territory, the usage type and an expiry that triggers a review. Then weight the digitization queue by clearability, so scarce vendor capacity stops going to material you will never be permitted to distribute. Document extraction earns its place here specifically: cue sheets, contracts and consent forms exist as scanned paper in wildly inconsistent layouts, and a model can pull parties, term, territory and usage type into fields for a researcher to confirm. It does not replace the researcher. It stops the researcher retyping, and it makes ten thousand cue sheets a tractable project rather than an abandoned one.

Should you build custom or configure what you already own?

Some institutions should not build, and the boundary is clear. If your holdings are mostly born digital, in the low thousands of objects, and your obligation is safe custody with a defensible audit trail, Preservica or Arkivum will serve you better than anything commissioned. They are aligned to the reference model for open archival information systems, they are strong on fixity checking, format identification, migration of digital objects and audit trails, and they solve that problem properly. The same applies if you have no funded digitization programme, because operational software for a programme that does not exist is an expensive way to describe an intention.

The pragmatic answer for larger archives is usually not replacement either. Keep the repository for storage, fixity and format management, keep the asset management platform for access copies, and build only the operational layer neither one covers: vault and carrier condition, equipment and vendor scheduling, chain of custody, prioritization and rights. A proposal to replace all of it is quoting a project rather than solving a problem.

Build the operational layer when two or more apply. You hold tens of thousands of physical items across mixed carriers with genuine decay risk. You have multi year funding and must defend the sequencing of that spend to a board or public funder. You use external digitization vendors and cannot reconstruct chain of custody for a batch from last year. Rights uncertainty is blocking monetization of material you already paid to digitize. Or you run more than one vault and items move between them.

How do hidden costs get into the quote?

Carrier variety is the first. Each carrier type needs its own condition schema and its own vocabulary, because acetate film needs an acidity reading, shrinkage measurement and splice condition, while magnetic tape needs binder condition, a note on whether baking was performed and at what temperature, and an assessment of edge damage and pack quality. A quote priced for two carrier families and delivered against nine is a different project.

The second is the data cleanup already described, which is almost always assumed to be background work.

The third is rights document extraction volume. Five hundred scanned cue sheets and ten thousand are not the same engagement, and the difference is not linear because larger corpora contain more layout variants.

The fourth is integration depth with your asset management platform, where the hard part is not the connection but agreeing which system owns which field, and that agreement takes meetings with people who disagree.

What separates a build that works from one that fails here?

Condition capture that a conservator will actually use in the vault decides it. That means format specific fields rather than a free text notes box, tablet entry with barcode scanning at the shelf, and a schema agreed by the people filling it in. A build that stores condition as prose cannot rank anything, and ranking is the entire point.

The second determinant is chain of custody generated by the archive rather than the vendor. The batch manifest is yours, items are scanned out and scanned in, and the vendor posts transfer results, quality control notes, deck used, operator and any interventions through a portal or interface so those facts attach to the item permanently. When a file is questioned in eight years, provenance is the difference between a preservation master and a copy of unknown origin.

Third is the storage plan. Every copy needs a record of where it lives, on what medium, written when, verified when and when it must be migrated. If you use tape, each drive generation reads back only a limited number of previous generations, so every tape written today has a migration horizon whether or not it is budgeted. The one page a board actually wants shows how many items exist as preservation masters, how many copies of each, where they are, when they were last verified and what migration costs over the next five years. Almost no archive can produce that page today without a week of work, and producing it is a reasonable definition of success.

Finally, settle ownership before kickoff: the repository, the cloud accounts and the right to hire anyone else. Archives think in decades, and a system that outlives its original vendor relationship is the only kind worth building here.