Short answer
Metadata mapping defines how each field and value in a source system translates into the new DAM metadata schema, including folder paths that become metadata values. A mapping table lists four things per field: source field, target field, conversion rule and default value. The taxonomy owner signs the table off before the first production batch, because every later change means re-running batches.
What metadata mapping is
Metadata mapping is a migration specification that translates every source field, folder level and embedded value into a field and value of the new DAM schema. The mapping sits between the DAM metadata schema designed in phase 1 and the batches run in phase 2 of the DAM implementation. DAMSelection assessment: the mapping decides how findable the migrated library is on day one.
Mapping covers four kinds of source data:
- Structured fields in an old DAM, a PIM or a spreadsheet.
- Folder paths on shared drives and cloud storage.
- Embedded metadata inside files: IPTC, XMP and EXIF.
- File properties: file name, file type, pixel dimensions and dates.
Each kind needs its own rules. Structured fields map field to field. Folder paths and file names need parsing. Embedded metadata needs a reliability check before it maps at all.
The mapping table
The mapping table is the single signed-off document that a migration script or vendor tool executes, with one row per source and target pair. Each row states where the value comes from, how it changes on the way, and what happens when no value exists.
| Column | Content |
|---|---|
| Source field | Field, folder level, embedded property or file property |
| Target field | Field name in the new DAM schema |
| Conversion rule | Split, merge, normalise, format or look-up rule |
| Default | Value when the source is empty or unmappable |
| Required | Yes or no, per asset type |
| Validation | How a batch check proves the field correct |
| Owner | Person who answers questions on the row |
Worked example: a mapping for product and campaign images from a shared drive and an old DAM.
| Source field | Target field | Conversion rule | Default |
|---|---|---|---|
| Folder level 2 | Brand | Look up folder name in the brand vocabulary | Flag for review |
| Folder level 3 | Asset type | Map "Packshots" and "Product shots" to Product image | Other |
| Folder level 4 | Campaign | Strip the year prefix, look up the campaign list | None |
| Year prefix in folder name | Year | Extract the four digits | Year of capture date |
| SKU pattern in file name | Product SKU | Extract the pattern, validate against the PIM | Empty, flag for review |
| Old DAM "Keywords" | Keywords | Split on comma and semicolon, trim, lower case | Empty |
| Old DAM "Usage" | Permitted channels | Map free text to Web, Print, Social and Marketplace | Rights unknown |
| Old DAM "Expiry" | Rights expiry date | Convert DD/MM/YYYY to YYYY-MM-DD | Empty, restricted |
| XMP dc:creator | Creator | Copy | Studio name from folder |
| IPTC Copyright Notice | Copyright notice | Copy | Organisation name |
| EXIF DateTimeOriginal | Capture date | Convert to YYYY-MM-DD | File creation date |
| EXIF GPS fields | Not migrated | Strip on ingest under the privacy rule | None |
| Full source path | Legacy path | Copy as read-only text | None |
The legacy path row keeps traceability. Users and support staff can find where an asset lived before, which helps during the first months after cutover.
Folders to metadata
Folder-to-metadata mapping turns each meaningful folder level into a facet value such as brand, asset type, campaign or year. Users found files by clicking through folders. In the DAM they find the same files by selecting facet values, so every meaningful folder level needs a target field.
Map folders in five steps:
- Export the full folder tree with file counts per folder.
- Identify what each level means per source, for example brand, then asset type, then campaign.
- Mark levels with no stable meaning, such as "Final", "New" or personal names, as ignored.
- Write a rule per level: direct look-up, pattern extraction, or a manual map from folder name to value.
- Test the rules on the full tree and review every folder that matches no rule.
Worked example: the path /Marketing/BrandA/Packshots/2024_Spring/Final/BA-10233_front.tif maps as follows.
| Path segment | Meaning | Target field | Value |
|---|---|---|---|
| Marketing | Department share | Ignored | None |
| BrandA | Brand | Brand | Brand A |
| Packshots | Asset type | Asset type | Product image |
| 2024_Spring | Year and campaign | Year, Campaign | 2024, Spring collection |
| Final | Status | Ignored | None |
| BA-10233_front | SKU and view | Product SKU, View | BA-10233, Front |
DAMSelection assessment: write rules per source and per top-level folder. Teams built their folders at different times for different purposes, so one rule set for a whole drive misreads levels.
Value normalisation
Value normalisation maps synonyms, spelling variants and free text to the approved values of each controlled vocabulary. Without normalisation, one facet shows "Packshot", "Pack shot" and "packshots" as three values, and every filter returns partial results.
Normalise with a synonym table per field:
| Field | Source values | Target value |
|---|---|---|
| Asset type | Packshot, Pack shot, packshots, Product shot | Product image |
| Channel | web, Website, online | Web |
| Region | NL, Holland, Netherlands | Netherlands |
| Language | EN, Eng, English UK | English |
| Usage | "ok for socials", "social only" | Social |
Apply four normalisation rules:
- Convert dates to the ISO 8601 format YYYY-MM-DD, the international standard for writing dates.
- Normalise case and spaces before any look-up.
- Send free text that matches no value to an unmapped-values report, and keep it out of list fields.
- Route new values found during mapping to the taxonomy owner, who adds them to the vocabulary or maps them to an existing value.
DAMSelection assessment: the unmapped-values report is the most useful output of the mapping work. The report shows where the vocabulary misses real-world values and where source data needs a manual decision.
Embedded metadata
Embedded metadata in IPTC, XMP and EXIF fields maps into the DAM where it is reliable and stays out where it is not. Fact: the IPTC Photo Metadata Standard defines properties such as Creator, Copyright Notice, Description, Keywords and Alt Text (Accessibility), each with an XMP and an IPTC IIM implementation. EXIF records technical capture data such as date, device and, on some devices, location.
Assess reliability per source before mapping:
- Read embedded fields from a sample with a metadata utility such as ExifTool, which reads and writes EXIF, IPTC and XMP.
- Measure fill rate and consistency per field across the sample.
- Map only fields that are filled consistently, such as creator and copyright from a professional studio.
- Set precedence: when an old DAM field and an embedded field disagree, the mapping states which one wins.
- Decide whether the DAM writes approved metadata back into files on download, so metadata travels with the asset.
Map generative AI markers from day one. The IPTC Photo Metadata Standard includes a Digital Source Type property with values from an IPTC controlled vocabulary. That vocabulary includes "trainedAlgorithmicMedia", labelled "Created using Generative AI", and "compositeWithTrainedAlgorithmicMedia", labelled "Edited using Generative AI". Map those values to a DAM field when present, so governance rules on AI-generated assets apply from the first batch.
Treat location data as personal data risk. EXIF GPS fields can reveal where a photo was taken. Decide per asset type whether to keep or strip location, and record the rule in the mapping table.
Defaults and unknown values
Defaults decide what happens when a source has no value, and safe defaults restrict an asset until a person confirms it. DAMSelection assessment: a default never grants more use than the source evidence supports.
| Field type | Safe default | Reason |
|---|---|---|
| Usage rights | Rights unknown, restricted | Blocks use until legal and rights confirm |
| Expiry date | Empty, with restricted status | Prevents silent unlimited use |
| Brand or product | Flag for review | Wrong values mislead search and integrations |
| Asset type | Other, with a review report | Keeps the asset findable while flagged |
| Creator | Studio or agency from the folder | Keeps attribution |
| Alt text | Empty, in the enrichment queue | Generated text needs human review |
Defaults also feed governance. Every asset carrying a review flag lands in a queue with an owner and a deadline, and the share of flagged assets becomes a quality KPI after go-live.
Test and sign off the mapping
The mapping passes when a test migration shows correct values on real assets and the taxonomy owner signs the table. Run sign-off in six steps:
- Apply the mapping to a test sample covering every source and asset type.
- Report the fill rate per target field and compare it with the source.
- Report every unmapped value and every default applied.
- Let content owners check 20 known assets per source against what they expect, as the DAMSelection rule of thumb sample.
- Fix rules and re-run until the reports show no unexplained gaps.
- Freeze the table with a version number, and route later changes through the change process in the DAM governance model.
The DAM migration plan places sign-off before batch 1, and the DAM migration checklist tracks it as a gate item. The Metadata Model Builder produces the target fields to map into.
Frequently asked
What is metadata mapping in a DAM migration?
Metadata mapping in a DAM migration is the specification that translates every source field, folder level and embedded value into the new DAM schema. A mapping table records source field, target field, conversion rule and default for each row. The taxonomy owner signs it off before the first production batch runs.
How do you map folders to metadata in a DAM?
Export the folder tree, identify what each folder level means per source, and write a rule per level that turns the folder name into a facet value such as brand, asset type, campaign or year. Ignore levels with no stable meaning, such as "Final". Test the rules on the full tree before migration.
Should we keep embedded IPTC and XMP metadata?
Keep embedded IPTC and XMP metadata where a sample shows it is filled consistently, such as creator and copyright from professional studios. Ignore fields with low fill rates or conflicting values. Set precedence rules for conflicts with old DAM fields, and strip EXIF location data where the privacy rule requires it.
Who owns the metadata mapping?
The taxonomy owner owns the metadata mapping and signs it off. The migration lead applies it, the IT and integration owner scripts it, and content owners check results on known assets. Legal and rights confirm the defaults for rights fields, because those defaults decide which assets users can download.
What happens to values that do not map to the new schema?
Values that do not map go to an unmapped-values report, and list fields receive the agreed default. The taxonomy owner reviews the report, adds legitimate values to the controlled vocabulary or maps them to existing values, and the batch runs again. Unmapped free text never enters a list field.