Digital preservation planning is the work of keeping digital information usable, intelligible and trustworthy as file formats, software, hardware, storage systems and user expectations change. It connects long-term digital preservation, file format obsolescence, technology watch, significant properties, format migration, emulation, normalisation, preservation metadata and repository risk into one continuing decision system. The central problem is not simply how to save files. It is how to preserve the information, evidence, behaviour and meaning that future users actually need.
A strong digital preservation strategy therefore begins before a format becomes unreadable. Archives, libraries, museums, research repositories and records programmes monitor technological change, identify vulnerable formats and dependencies, define the characteristics of digital objects that must survive, compare preservation actions, test transformations, retain provenance and verify that long-term access still works. Migration and emulation are not rival slogans. They are different interventions for different preservation jobs.
The practical keywords—digital preservation planning, preservation strategy, technology watch, significant properties, file format migration, emulation, digital obsolescence, preservation risk, long-term access, format sustainability, preservation metadata, OAIS and trusted digital repositories—all converge on one question: what must remain true about this digital object after the surrounding technology has changed? Once that question is explicit, preservation becomes a disciplined process of observation, modelling, intervention, validation and learning rather than a periodic scramble to rescue old files.
The preservation problem is change
Physical preservation is often imagined as resistance to change. Digital preservation is stranger. The preserved bits may remain exactly the same while everything required to interpret them disappears.
A file can retain perfect fixity and still become practically inaccessible because its application is no longer available. A database can survive while its schema documentation vanishes. A game can retain every executable byte while the operating system, graphics interface, network service and hardware assumptions it requires become unavailable. A spreadsheet can open in a newer application while formulas, macros, links or visual behaviour change silently.
This creates the defining paradox of digital preservation: sometimes the only way to preserve access is to change the representation.
PRESERVE BITS but also PRESERVE INTERPRETABILITY and sometimes CHANGE REPRESENTATION without losing what matters
Preservation planning exists to govern that paradox.
1. Preservation planning is a continuing function, not a rescue event
The Digital Preservation Coalition’s Digital Preservation Handbook describes preservation planning as monitoring repositories and their environment so that changes affecting accessibility can be detected and preservation actions can be planned. The OAIS model likewise places Preservation Planning alongside archival storage, data management, administration and access.
The implication is important. Preservation planning should not begin when users can no longer open something. By then the institution may already have lost software, expertise, documentation, licences or representative test environments needed to make a controlled decision.
A mature planning function continuously watches four moving systems:
- the collection — formats, versions, dependencies, scale and value;
- technology — software, hardware, standards, codecs, storage and services;
- the institution — skills, funding, policy, risk appetite and infrastructure;
- the designated community — what future users know, expect and need.
Planning happens where those four systems intersect.
2. The object is not the file
One reason preservation strategies fail is that they begin with a filename rather than the intellectual or functional object.
A digital object may be a single file. It may also be a package, database, website, software environment, email account, research workflow, interactive artwork, geospatial dataset or audiovisual work with many components.
Consider a website. Preserving only HTML files may omit stylesheets, scripts, fonts, images, video, APIs and server-side behaviour. Consider a spreadsheet. Preserving visible values may omit formulas and dependencies. Consider an email. Preserving the message body without headers, attachments or thread relationships can alter evidential meaning.
The planning question must therefore be:
What is the preservation object, and what relationships make it function as that object?
3. Significant properties turn “preserve it” into a testable claim
Preservation cannot keep every possible property under every transformation. A migration may change byte structure while preserving visual appearance. An emulated environment may preserve interaction while changing underlying hardware timing. A normalised image may preserve pixels while discarding proprietary metadata.
This is why preservation practitioners use ideas such as significant properties, significant characteristics or preservation intent. These concepts identify the properties that must remain sufficiently stable for the object to continue serving its intended evidential, informational, aesthetic or functional role.
For a text document, significant properties might include words, reading order, pagination, typography, annotations or revision history depending on purpose. For a photograph they may include pixel dimensions, colour behaviour, tonal range, metadata and orientation. For software they may include input-output behaviour, interface, timing, dependencies and interaction.
The key is not to create an abstract list of everything measurable. It is to connect properties to the receiver job.
OBJECT PURPOSE + EVIDENTIAL / FUNCTIONAL ROLE + DESIGNATED COMMUNITY → SIGNIFICANT PROPERTIES → TESTS → ACCEPTABLE CHANGE BOUNDARY
4. Significant properties are contextual
The same format can contain objects with different preservation priorities.
A PDF used as the authoritative record of a signed decision may require preservation of signatures, page geometry and visual appearance. A PDF containing a research article may prioritise text, figures, equations, citations and reading order. A PDF generated as a temporary access copy may not deserve the same preservation treatment at all.
This means a repository should resist universal property checklists detached from collection purpose. The right preservation target emerges from appraisal, context and intended future use.
5. Technology watch looks for changes before they become emergencies
Technology watch is the listening system of preservation planning.
It observes developments that could change preservation risk: vendor support, operating-system compatibility, software availability, standards revisions, browser behaviour, codec support, storage technologies, security changes, licensing, cloud-service retirement, format adoption and new preservation tools.
Useful signals include:
- a vendor announces end of support;
- a format disappears from common authoring software;
- a browser removes a required feature;
- a codec becomes difficult to obtain;
- a cloud API is deprecated;
- a preservation registry changes risk information;
- a validator discovers widespread non-conformance;
- security policy prevents an old application from running;
- a replacement format becomes stable and widely supported.
Technology watch should produce candidate review events, not automatic transformations.
6. The collection needs its own observatory
External technology news matters only when connected to actual holdings.
If a repository knows that a format is becoming obsolete but does not know whether it holds ten files or ten million, planning remains abstract. The preservation inventory therefore needs to connect stable format identification to collection scale, value, dependencies and access demand.
The earlier file format identification route supplies format identities. The validation route supplies conformance evidence. Preservation planning turns those observations into prioritised action.
FORMAT RISK SIGNAL × NUMBER OF OBJECTS × VALUE / CONSEQUENCE × DEPENDENCY COMPLEXITY × ACCESS NEED × AVAILABLE REMEDIATION → PRIORITY
7. Obsolescence is not a binary state
Formats rarely switch from alive to dead on one date.
Obsolescence is usually a gradient. Authoring support declines. Vendors disappear. Documentation becomes harder to find. Skilled users retire. Operating systems stop supporting applications. Conversion tools remain for a while. Open-source readers may survive. Virtualisation can extend life. Emulation may restore access later.
A useful risk model therefore avoids labels such as “old = obsolete”. It asks about actual support conditions.
- Can current software render the object correctly?
- Are multiple independent implementations available?
- Is the specification documented?
- Can the repository still obtain required licences?
- Are external services required?
- Can the environment be virtualised or emulated?
- Is there a credible migration destination?
- Can significant properties be tested after transformation?
8. Format sustainability is broader than popularity
The Library of Congress Sustainability of Digital Formats framework considers factors including disclosure, adoption, transparency, self-documentation, external dependencies, patents and technical protection mechanisms. These factors explain why widespread use alone is not enough.
A popular format may still depend heavily on one vendor. A less common format may be openly documented and supported by several tools. A technically elegant format may be poorly adopted. A self-documenting container may survive institutional change better than a format whose meaning depends on undocumented external databases.
Sustainability is therefore a system property, not a popularity contest.
9. Preservation triggers should be explicit
Without triggers, institutions either act too late or migrate unnecessarily.
A trigger is an observable condition that requires review. Examples include:
- support falls below an agreed threshold;
- a required application becomes unavailable;
- validation failures rise;
- security policy blocks the rendering environment;
- storage or platform migration threatens dependencies;
- a designated community can no longer use the current representation;
- a new standard materially improves preservation prospects;
- access demand justifies creating a more usable representation.
The trigger should open an assessment, not predetermine its outcome.
10. Migration changes representation to preserve access
Migration transforms a digital object from one format, version or technical environment into another. It is among the most common preservation strategies because contemporary software can often create new representations that remain easier to render and manage.
Examples include converting an obsolete word-processing format into an open document format, transcoding audiovisual material into a supported preservation codec, or moving structured data from a proprietary database export into a documented interchange representation.
But migration is never merely “save as”. It creates a new object state and therefore a new evidential obligation.
SOURCE OBJECT → TRANSFORMATION TOOL → TARGET OBJECT → VALIDATION → PROPERTY COMPARISON → HUMAN / AUTOMATED QA → PROVENANCE EVENT → ACCEPT / REJECT
11. Migration can lose information while appearing successful
The most dangerous migration failure is not a file that refuses to open. It is a file that opens and looks plausible while something important has changed.
Possible losses include:
- fonts or layout;
- colour information;
- embedded metadata;
- formulas and macros;
- links and references;
- annotations;
- transparency or layers;
- timecode and audiovisual metadata;
- interactive behaviour;
- precision or data types;
- rights information;
- provenance embedded in the original format.
The National Archives’ digital preservation guidance stresses the need to assess the risks of migration and compare significant properties before and after transformation. The correct test is not “did conversion finish?” but “did the properties we committed to preserve survive within tolerance?”
12. Migration needs measurable acceptance criteria
Before a large migration begins, the institution should define what counts as success.
Acceptance criteria can include:
- target format validates against the intended specification or profile;
- page count remains stable;
- text extraction matches expected content;
Continue through the World Systems Directory for connected systems, delivery and evidence routes.
Continue through the World Systems Directory for connected systems, infrastructure and governance routes.