Broadcast Media Asset Management Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does the project become a MAM replacement instead of a metadata layer?

Because the frustration is with the media asset management system, so the instinct is to replace it. The archive team cannot record the fields they need, search returns the wrong things, and every schema change is a professional services engagement. Replacing the whole thing feels like taking back control.

What replacing it actually commits you to is the plumbing: object storage lifecycle handling, proxy generation at scale, a transcode farm, search indexing over millions of records, editorial integration with the systems your craft editors already use, and restore behaviour from tape and deep archive. That is years of engineering that Dalet, Avid MediaCentral, Vizrt Viz One and Tedial do every day, and rebuilding it to arrive at parity is the clearest way to spend a large budget and end up behind where you started.

The scope that pays is narrower and harder to see. Keep the vendor system doing storage, proxies, transcoding, indexing and editorial integration, which it does well. Build the layer that holds what is genuinely yours: your house schema, your version relationships, your rights position and your partner delivery profiles. Those describe how your organisation makes money, and no vendor will model them correctly because they encode how you think, not how broadcasting works in general.

Stated plainly, the decision is not whether to replace the MAM. It is to stop treating the MAM as the system of record for meaning. Getting that framing right in the first workshop is worth more than any feature in the specification.

What goes wrong when you migrate twenty years of legacy catalogue records?

Migration is not a data transfer, it is archaeology, and it is where these projects succeed or fail regardless of how good the new system is.

The specific problems repeat across every archive we have seen. Identifiers were reused, so the same number means two different programmes depending on which decade you are in. Free text fields hold information that belongs in structured fields, because there was no structured field at the time and a cataloguer improvised. The same programme exists three times because three departments catalogued it independently and none knew about the others. A migration in an earlier decade already dropped the fields nobody could map, so the record you are migrating is itself lossy. And provenance, meaning who catalogued what and when, is valuable evidence that a naive migration discards first because it looks like housekeeping.

The failure mode is a new archive with the same disease, plus the false confidence that comes from having just done a migration.

What works: plan migration as its own workstream with its own budget and its own timeline, not as a phase of the build. Migrate in waves by collection, starting with the material that has commercial demand, and keep the legacy system readable for a defined period rather than switching it off. Use machine assistance to propose mappings from free text into structured fields and to propose duplicate merges, then require a human decision on every proposal with an audit record of who decided. A field whose origin cannot be explained is a field nobody will trust in five years.

Why do storage tiers, transcode farms and editorial integrations break after launch?

Because naive designs assume storage answers immediately, and a large share of your archive does not.

The deep archive restore is the classic break. A producer searches, finds twelve clips, and requests them. Four are on instant storage and arrive. Eight trigger retrievals from a tape library or a deep object storage tier, which take hours and cost money. If the interface does not model that, the producer assumes the system is broken, requests them again, and now you have duplicate retrievals nobody is tracking. Most organisations have no visibility of what restoring actually costs, so it accumulates quietly on a bill that goes to a different department.

Transcode integration breaks on failure handling rather than on success. A job fails halfway, the asset exists in a partial state, and a delivery pipeline picks it up because the record says a rendition exists.

Editorial integration breaks on identity and permissions. An editor's project references an asset, the asset is superseded or its rights change, and nothing propagates back into the edit suite.

The fixes: model restore as a queued request with a visible cost estimate, a realistic expected time and batching so one project does not fire fifty separate retrievals. Treat renditions as valid only when a job completes and validates, never on job start. And make rights and version status something the editorial integration surfaces rather than something a separate system holds. Ask any prospective developer how they handle deep archive restores specifically, because it is the question that separates people who have done this from people who have read about it.

What happens when rights never reach the person making the usage decision?

The person most likely to breach a licence is not a lawyer. It is an editor at four in the afternoon cutting a trail to a deadline. They do not know that the archive interview was cleared for the original transmission only, that the music bed carries a limited licence, or that the contributor withdrew consent last year. They have no way of knowing, because rights information lives in a contracts system or a folder and the search interface shows them a clip.

This is not a failure of the MAM vendors. Rights modelling is genuinely hard and specific to each organisation, and it involves contract data those systems were never given. The consequence still lands with the broadcaster: usage outside a licence, a takedown, a payment, and a rights holder who prices the next deal accordingly.

What a build should do is attach rights to the asset and its versions and enforce them where the decision is made. Search results carry usage status. Adding restricted material to a project raises the restriction and names who to ask rather than silently permitting it. Contributor consent and music cue information sit alongside the technical metadata rather than in a separate universe.

The design decision that matters most is small and easy to get wrong. Where the rights position is unknown, the system must say unknown and route to a named owner. It must never default to permitted, and it must never leave the field blank in a way that reads as clear. Ask a developer how they handle unknown rights status; if the answer is anything other than an explicit unknown state, they have not understood the risk.

Should you build custom or configure the MAM you already own?

If you are a production company or a single channel broadcaster with a few hundred terabytes, conventional delivery requirements and a manageable version count, configure what you have. Dalet, Viz One, Avid MediaCentral and Tedial all support custom metadata, and their configuration will stretch considerably further than most teams push it before declaring it insufficient. Building to obtain what you can configure is the most common waste in this category.

Test that properly before deciding. Take your hardest real case, a compliance edit that was later re edited with a different audio configuration for two territories, and ask your incumbent vendor to model it in a demonstration. If they can, your build case has just disappeared for the price of a meeting.

Build a layer when two or more of these are true. Your house schema exceeds what the MAM will model and the overflow lives in spreadsheets. Version relationships are encoded in file names and you have had a delivery rejected because of it. Rights information does not reach the people making usage decisions. You deliver to more than about five partners with distinct specifications. Or you are migrating from a legacy system and need provenance preserved rather than flattened.

How do hidden costs get into a broadcast archive quote?

Five items account for most of the variance, and the largest is not engineering.

• Migration volume and legacy data condition. The single biggest variable in the whole project, and the one most often priced as an import.
• Storage tier behaviour. Every tier with a retrieval delay or a retrieval charge needs queuing, cost visibility and expectation handling. A tape library and a deep cloud tier are two separate problems, not one.
• Partner delivery profiles. Each specification is versioned content with its own validation rules, and they change without asking you.
• Machine generated metadata at scale. Transcription and shot detection across a large archive carries a compute cost that should be modelled per hour of content before anyone commits, and it is usually quoted as a feature rather than as a running bill.
• Rights data capture. Getting licence terms out of contracts and into structured fields is human work, not integration work.

Ask for migration and machine metadata to be quoted separately with a per hour or per collection basis, so you can phase them by commercial demand rather than paying for the whole archive at once.

What separates an archive build that works from one that fails?

Four things.

First, the version model drawn on a whiteboard before anything is signed. Master, derived version, audio configuration, subtitle asset and territory validity as distinct relationships, with an answer to what happens when a compliance edit is later re edited. A developer who draws assets with tags has built a document management system and will discover broadcast at your expense.

Second, unknown treated as a value. Unknown rights, unknown provenance and unknown version lineage must be visible states that route to an owner, not blanks that read as clear.

Third, delivery validated before it leaves. Each partner specification becomes a versioned profile covering required version type, technical parameters, metadata mapping, naming, packaging, checksum manifest and route, with validation run in house. A rejection then becomes an exception you caught rather than an email three days later with a fee attached, and holiday cover stops being a risk.

Fourth, a tested export before go live. You are building the record for material that will outlive several generations of software, so a documented, exercised metadata export is the difference between an asset and a future migration problem. Own the repository and the infrastructure accounts, and prove the export works while you still have the team who built it.