Reference Glossary
Data portability
The ability to export a DAM's assets and their full metadata, in a usable structured format, so an organization can move to another system without losing data or context.
Why it matters in a DAM
A DAM without genuine data portability turns years of accumulated tagging, rights terms, and usage history into de facto vendor property, even when nothing in the contract says so. GDPR also creates a narrower, legally distinct portability right for personal data attached to assets — model or photographer contact details, for instance — that DAM buyers evaluating "can we get our catalog out" often overlook because it's a compliance obligation, not a migration convenience.
A worked example
Common mistake
Teams verify that raw files can be downloaded but never test exporting the metadata schema itself — custom fields, controlled vocabularies, and rights annotations often have no clean export path and end up rebuilt by hand during a migration.
Data portability in a DAM sense usually means two things bundled together: the practical ability to get every asset and its associated metadata out of a system in a format another system can ingest, and — where personal data is involved — a specific legal right under regulations like GDPR. The practical question is the one most DAM buyers care about day to day: if the vendor relationship ends, does a full export reconstruct the library elsewhere, or does it produce a folder of files stripped of the tagging, rights terms, and version history that made the library useful in the first place.
GDPR Article 20 gives individuals the right to receive personal data they provided to a controller in a structured, commonly used, machine-readable format, and to have it transmitted directly to another controller where technically feasible. In a DAM context this is narrower than general data portability — it applies to personal data (a model’s name, a contributor’s contact details) rather than the whole asset catalog — but it means organizations handling model releases or contributor records inside their DAM need an actual mechanism to fulfill a portability request, not just a general export button.
The practical test for portability is running an export and trying to reconstruct the library’s structure and metadata elsewhere, before signing rather than after. Vendors vary widely in what “export” actually includes: some preserve the full metadata schema and folder hierarchy, others export raw files with only basic technical metadata, leaving keyword taxonomies, custom fields, and rights data to be manually rebuilt.
Frequently asked
What does good data portability from a DAM actually look like?
A full asset export plus metadata as CSV/XML/JSON, with folder and taxonomy structure preserved — not just raw files downloading fine.
What does GDPR Article 20 specifically require?
The right for individuals to receive personal data they provided to a controller in a structured, commonly used, machine-readable format, and to have it transmitted to another controller where feasible.
Is GDPR's portability right the same as general DAM data portability?
No — it's narrower, applying to personal data like a model's name or a contributor's contact details, not the whole asset catalog.
What's the most common gap organizations discover too late?
Custom fields, controlled vocabularies, and rights annotations often have no clean export path and end up rebuilt by hand during a migration.
What's the practical test for whether a DAM has real portability?
Running an export and trying to reconstruct the library's structure and metadata elsewhere, done before signing the contract rather than after.
Why does poor portability matter even if raw files export fine?
Metadata can be trapped in proprietary custom fields with no export mapping, so the library's tagging, rights terms, and structure don't survive the move.
Sources
- GDPR Article 20 gives data subjects the right to receive personal data they provided to a controller in a structured, commonly used, machine-readable format, and to transmit it to another controller. checked 2026-08-07 — GDPR Article 20 (gdpr-info.eu)