Migration readiness · Field guide 02
The metadata preservation checklist.
A successful import is not proof that the archive survived. Preserve every source, define the fields that matter and verify the result asset by asset.
Preserve the sources separately
Photo metadata can live in several places at once: EXIF written by the camera, IPTC or XMP embedded in a file, an XMP sidecar, a catalog database, a spreadsheet, a folder name or a staff member’s memory. Treat each as a distinct source. Copying the image folder alone may preserve pixels while losing captions, collection membership and rights notes.
- Original files: preserve unchanged copies with their current names and directory paths.
- Sidecars: keep XMP and other companion files adjacent to the assets they describe.
- Native catalogs: retain the database, preview cache and application-version information.
- Exports: create XML, CSV, JSON or other supported exports without replacing the native source.
- Documentation: save field definitions, controlled vocabularies, abbreviations and export settings.
Define a minimum viable record
Choose fields based on the work staff must perform. A useful agency baseline often includes a stable identifier, filename, caption, creator, creation date, location shown, location created, project or program, subjects, rights holder, usage restrictions, source collection and original-file location.
The distinction between “location created” and “location shown” matters. IPTC defines both because the photographer’s position may differ from the place depicted. Sensitive species or cultural locations may also require restricted access rather than broad display.
| Field group | Preserve | Verify after import |
|---|---|---|
| Identity | Stable ID, source filename, checksum | Every record still points to the intended file |
| Description | Caption, title, keywords, projects | Phrases, diacritics and hierarchy remain intact |
| Time and place | Original dates, time zone, created and shown locations | Dates were not shifted or reduced to file-modified time |
| Rights | Creator, credit, owner, usage terms, restrictions | Restrictions affect access and export as intended |
| Relationships | Collections, sets, sequences, derivatives | Membership and order survived—not just text fields |
| Provenance | Source system, import batch, change history | Staff can tell imported facts from later edits |
Create the field map before the move
A field map states that a source value has a specific destination and transformation. It should show source field, source format, destination field, cardinality, allowed values, transformation rule and exception behavior. “Keywords → tags” is incomplete if nested subjects flatten into an unordered list or if commas inside phrases split one concept into two.
Choose an explicit policy for conflicts. Embedded caption versus catalog caption is not merely a technical mismatch; either may be newer or better. Preserve both source values until an accountable reviewer decides which becomes the working value.
Use a representative validation set
Build a small test set that contains the archive’s difficult cases: long captions, empty fields, non-English characters, multiple photographers, uncertain dates, nested collections, custom fields, missing originals, repeated filenames and restricted locations. Export expected values before migration, then compare after import.
Validate four layers: the file, its fields, its relationships and the staff workflow that depends on them.
Require an exception report
A trustworthy migration does not hide uncertainty. Require counts and identifiers for skipped files, unsupported formats, truncated values, unmapped fields, duplicate matches, missing originals, broken sidecars and records requiring human review. A clean-looking destination can conceal large losses if exceptions are not visible.