Data portability and exit
You can take your records at any stage.
Lock-in is the fear every archivist has heard. The answer here is structural. Records export at every stage in standard formats, so portability is part of the architecture, not a renewal concession.
Last reviewed July 2026
- Export
- Every stage
- Formats
- DC · EAD3 · MODS · METS · BagIt
- Packaging
- BagIt transfer
- Media
- Original files
What leaves with you
Everything, in formats you can read.
Descriptions, at every stage
Export catalog records as Dublin Core, EAD 2002 or EAD3, MODS, and EAC-CPF, at any point in their life, not only at the end. The hierarchy and authority records come with them.
DC · EAD 2002 / EAD3 · MODS · EAC-CPF
Preservation packages
Package records with their media as METS with PREMIS, and produce BagIt transfer packages your next system can verify against a manifest.
METS + PREMIS · BAGIT
The media itself
Export the original media files with their SHA-256 checksums. In a customer-controlled self-hosted deployment, those files already sit on infrastructure you control.
ORIGINAL FILES · SHA-256
A live interface, not a one-time export
Serve and harvest through OAI-PMH so records can move continuously. Portability is a live endpoint, not a one-time export you have to request.
OAI-PMH · SERVE · HARVEST
What an exit looks like
What leaving actually involves.
An exit is a sequence you can run and check. You export the descriptions and authority records in the standard formats above. You generate BagIt packages that bind each record to its media and to a manifest. You take the original media files with their checksums.
Then you validate every part against its schema, using your own tooling, before you rely on it. A portability promise you cannot verify is marketing. One you can verify is architecture.
Validate the exports before you depend on them.
A working setup using your records, not a sales presentation.