AtoM is standards-driven, so import and export are less about moving files and more about preserving structure and meaning as data crosses systems. Whether you are migrating a legacy catalogue, harvesting from partners, or feeding an aggregator, the format you choose determines how much of your hierarchy, authority records and rights information survives the round trip.

The main exchange formats are EAD 2002 (encoded archival description), EAC-CPF for authority records, Dublin Core, MODS, SKOS for vocabularies, and CSV for bulk data. Alignment with ISO 16175 (records in digital systems) and OAIS ideas of submission and dissemination information helps you reason about what each package must carry.

CSV import

CSV is the workhorse for bulk loading descriptions, authority records, accessions and events. AtoM publishes template headers you must match exactly.

  • Use legacyId and parentId columns to rebuild the archival hierarchy on import.
  • Encode files as UTF-8 and keep repeated values (e.g. subjects) pipe-delimited.
  • Run imports from the command line for large sets so they are not killed by web timeouts.

XML import & export

EAD preserves the full multilevel hierarchy and is the correct choice for archive-to-archive transfer; EAC-CPF moves the linked people and organisations. For interoperability with libraries use MODS or Dublin Core, and expose OAI-PMH so aggregators can harvest your metadata on a schedule.

In practice. Always test a migration on a copy first. Import a 20-row CSV sample, export it back out as EAD, and diff the two. Mismatches in dates, levels of description or parent links surface immediately - far cheaper to fix before you load 50,000 rows.

Key takeaways

  • Match the format to the job: CSV for bulk, EAD/EAC-CPF for hierarchy and authorities.
  • legacyId plus parentId columns rebuild multilevel structure on import.
  • Round-trip a sample and diff it before committing a full migration.

Check your understanding

Last modified: Saturday, 1 August 2026, 11:03 AM