Digital preservation sometimes keeps an object alive by changing the very file format in which the object arrived.
That sounds paradoxical only if preservation is confused with freezing. A file can remain bit-for-bit unchanged while the software ecosystem around it disappears. An obsolete application may stop running. a proprietary format may lose vendor support. an old codec may become difficult to decode. a format may remain readable but no longer fit accessibility, security or operational requirements.
File format migration is the controlled transformation of digital content from one format, version or encoding into another so the object remains usable over time. Preservation migration is not merely conversion. It includes selection, characterisation, validation, provenance and explicit judgment about what must survive.
This article sits beneath How Library Preservation Works, How Significant Properties Work in Digital Preservation and How Preservation Metadata Works. The narrow question is: how do we change format without pretending nothing changed?
1. Migration Solves a Usability Risk, Not a Fashion Problem
A repository should not migrate files merely because another format is newer.
Migration has cost and risk. Every transformation can change content, metadata, rendering or behaviour. A defensible trigger is usually a preservation problem: declining software support, dependency risk, poor documentation, security constraints, inaccessible functionality or evidence that the current format no longer serves the designated community.
The Library of Congress maintains format guidance and sustainability information precisely because preservation planning requires evidence about format support, transparency and dependencies. See Library of Congress Digital Formats guidance.
2. Preserve the Original Where Policy and Rights Allow
A migration target can later reveal an unexpected loss. Keeping the original source provides a return path for future reprocessing or improved tools.
The Library of Congress states a policy of maintaining an authentic and accurate copy of digital content in the form originally received while allowing appropriate preservation actions such as format transformation. See Maintenance of Original Formats.
Original retention does not eliminate the need for migrated preservation or access copies. It prevents one irreversible conversion from becoming the only surviving evidence.
3. Characterise Before You Convert
Before migration, the repository should know what it has.
- format and version;
- file size and fixity;
- embedded fonts, profiles or attachments;
- macros, formulas or scripts;
- external dependencies;
- metadata fields;
- significant properties;
- known validation problems.
If the source is poorly characterised, the repository cannot distinguish a conversion loss from a property that never existed.
4. Choose the Target by Preservation Function
A good preservation target tends to have strong documentation, wide adoption, multiple implementations, stable standards and the ability to preserve the properties the collection requires.
That does not mean one format is universally best. The correct target for a photograph, spreadsheet, database, document, video or geospatial dataset depends on the object and the required future use.
The Library of Congress Recommended Formats Statement 2025–2026 provides one current institutional example of how preferred and acceptable formats are evaluated. See Recommended Formats Statement.
5. Migration Is a Transformation With a Loss Budget
Some properties will survive exactly. Others may survive approximately. Some may be intentionally dropped.
A word-processing document migrated to PDF may preserve visual pages and searchable text while losing editing structures, comments or macros. A database exported to CSV may preserve values while losing relationships and stored logic.
The migration plan should name these expected changes before the tool runs.
6. Batch Conversion Needs Representative Testing First
Running a conversion tool across one million files is not the first test.
A repository should sample representative and difficult cases: large files, unusual encodings, edge versions, corrupted examples, files with embedded features and objects near known tool limits.
The purpose is to discover failure modes before the migration becomes an estate-wide transformation.
7. Validation Must Test More Than File Opening
“The target file opens” is a weak acceptance criterion.
Validation should ask whether the target format is well-formed, whether important metadata survived, whether text extraction remains correct, whether image dimensions or colour properties remain within tolerance, whether formulas still work where required, and whether the significant properties defined before migration survived.
Automated checks can cover many structural properties. Human review remains valuable for layout, meaning, audiovisual quality or interactive behaviour that automated tools cannot judge well.
8. Fixity Changes by Design
A migrated file should not have the same checksum as the source because the bytes have changed.
The preservation system therefore records fixity separately for source and target and links them through a migration event. Fixity proves each bitstream’s internal continuity; preservation metadata explains their derivational relationship.
9. Migration Provenance Must Be Reproducible
Future users should be able to answer:
- which source file was migrated;
- which tool and version performed the conversion;
- which parameters were used;
- when the action occurred;
- which significant properties were tested;
- which validation checks passed or failed;
- who approved the result.
That record turns a black-box conversion into a preservation event.
10. Migration Can Be Normalisation at Ingest
Some repositories convert incoming objects into a smaller set of managed preservation formats during ingest.
This can simplify long-term operations. It can also create immediate information loss if the normalisation profile is too aggressive.
A mature workflow therefore preserves the original where appropriate and treats the normalised representation as a documented derivative rather than pretending the source never existed.
11. Migration Can Also Be Deferred
Repositories may choose to retain original formats and migrate only when risk crosses a defined threshold.
This avoids unnecessary transformation and relies on format monitoring, software availability and preservation planning to trigger action before access becomes impractical.
12. Some Objects Are Poor Migration Candidates
Complex interactive software, digital art, games and dynamic systems can depend on behaviours that no target format reproduces adequately.
For those objects, emulation may preserve experience or behaviour better than format migration.
The next article in this corridor owns that alternative.
13. Worked Example: Office Document
A repository holds a 1990s word-processing file. The original application is increasingly difficult to run.
The archive preserves the source, converts a copy into a sustainable document format, compares text, images and page structure, records the conversion tool and validation outcome, and links source and target through preservation metadata.
The migration improves accessibility without rewriting the source history.
14. Worked Example: Scientific Data
A proprietary statistical package contains numeric variables, labels, missing-value conventions and metadata.
A CSV export preserves raw values but can lose labels and typed semantics. A stronger migration package might preserve CSV plus a machine-readable schema, codebook and provenance record.
The preservation target is therefore a set of coordinated representations, not necessarily one replacement file.
15. Worked Example: Audio
An archive holds compressed audio in an aging proprietary format.
Migration to a well-documented preservation format can improve future renderability. The archive should compare duration, channel count, sample properties and audible output, preserve provenance and retain the original where policy allows.
16. Worked Example: eduKate Archive
A future preservation project may need to move WordPress exports, database dumps or static HTML into a new repository architecture.
The migration must preserve more than page text: canonical identity, internal links, dates, metadata, edition state and the relationships that make the knowledge estate navigable.
17. Failure Mode: Successful Conversion, Failed Preservation
A conversion tool reports no errors. Every target file opens. A month later, users discover all document annotations vanished.
The software succeeded at format conversion. The preservation project failed because it never defined annotations as a significant property.
18. A File-Migration Checklist
- Define the preservation risk that justifies migration.
- Preserve the original where rights and policy permit.
- Characterise source files before conversion.
- Define significant properties and accepted losses.
- Select target formats using documentation, adoption, dependencies and collection needs.
- Test representative and edge cases before batch conversion.
- Record tool, version, parameters, date and agent.
- Validate structure, content and significant properties.
- Create new fixity for migrated objects and preserve derivation relationships.
- Keep rollback or reprocessing paths available.
19. Read the Mechanism Forward, Backward and Sideways
Forward: preservation risk → source characterisation → target selection → test migration → validation → batch action → documented preserved representation. Backward: start from a missing property in the target and ask whether the requirement, tool or validation step failed. Sideways: compare archivist, format specialist, creator and user. Each may define acceptable loss differently.
20. The Civilisation Lesson
Long-term digital memory survives by changing carefully.
File format migration is preservation by controlled transformation: change the container when necessary, preserve the evidence of the change, and prove that the properties carrying meaning survived the journey.
Continue through How Significant Properties Work in Digital Preservation, How Preservation Metadata Works and the How X Works hub. Next: emulation — preserving the environment and behaviour when changing the object itself would destroy too much of what matters.