Digital Heritage: How Archivists Preserve Software After It Stops Running

Software disappearance has several layers

Software does not disappear in a single technical event. A service may stop accepting users while its application remains downloadable. Its website may remain online after the underlying functions have been disabled. Installation files may survive while the servers, authentication systems, databases, or external services required to operate them are gone.

For archivists, these distinctions matter because a preserved file is not necessarily a preserved application. A mobile application package, for example, may contain executable code but depend on a remote account system and an unavailable application programming interface. Keeping the package records part of the product, but it does not recreate the complete service. Preservation work begins by identifying which parts existed and which relationships made them function.

The shutdown announcement belongs in the archive

An end of service announcement is a primary document in the history of a software product. It records how an organization described its decision, which functions it identified as ending, what timetable it communicated, and what arrangements it made for existing users. The language can also reveal how the organization understood the product's importance and its obligations at the point of closure.

App shutdown notice examples can be studied as a documentary category even when the application itself is no longer accessible. A notice might appear as a website announcement, an email, an in-app message, a support article, or a final account page. Each format has different preservation risks. Email can be retained by recipients, while an in-app message may disappear when the application stops communicating with its servers.

Archivists should record the announcement's publication context, its stated effective dates, the organization responsible, and any later revisions. If a notice changes, its earlier version can be historically significant. A revised deadline, an additional export period, or a changed description of available alternatives documents how the closure developed. The announcement should be preserved as a dated document, not merely summarized in a catalog description.

Preservation methods answer different questions

Bit-level preservation retains a digital object in its original form. It is an important starting point because it maintains the original sequence of data, but it does not guarantee that future computers will be able to interpret the object. An archive may preserve an old executable perfectly while lacking the operating system or hardware needed to run it.

Migration moves information into a format that can be used by contemporary systems. A document produced by retired software might be converted into a more widely supported document format. This can preserve readable content and make future access easier, although some original formatting, interactive behavior, or application-specific functionality may be lost. The original should be retained alongside the migrated version whenever preservation resources allow.

Emulation takes another approach. It recreates an older computing environment on current hardware so that historical software can operate in conditions closer to its original setting. This can be particularly useful for games, interactive applications, and multimedia works whose meaning depends on behavior and interaction. Emulation also introduces maintenance requirements, technical dependencies, and possible licensing constraints. The appropriate method depends on what the archive needs to preserve and make accessible.

Preserving the environment around an application

An application is rarely an isolated object. It may depend on a particular operating system, browser, database, hardware component, network service, file format, or authentication method. These dependencies should be recorded because they explain why an apparently intact application might no longer function. Technical documentation can also help future researchers distinguish an intentional product decision from a later compatibility failure.

A useful preservation record identifies the application's name, available versions, known operating environments, dependencies, interfaces, file formats, and relevant documentation. Where possible, it also records screenshots, representative workflows, installation instructions, and descriptions of expected behavior. Screenshots show appearance, while recorded interactions and technical documentation can help explain what users were able to do.

Software Heritage, for example, focuses on preserving publicly available software source code and its development history. Source code offers evidence of implementation and change, although it does not automatically preserve every service dependency, hosted resource, or user-facing experience. An archive should state precisely which components its collection contains and which remain outside its scope.

A product sunset checklist for preservation teams

Preservation planning is most effective while the product still operates. Teams can identify important records, establish access arrangements, and document dependencies before staff, servers, and institutional knowledge disperse. A sunset checklist should assign responsibility to named organizational roles, including product, engineering, communications, and records management.

The following checklist provides a practical starting point for product teams and collecting institutions:

- Preserve the original shutdown announcement, subsequent revisions, and related public documentation.

- Record software versions, operating requirements, dependencies, and known external services.

- Retain original source code, installation packages, configuration records, and relevant technical documentation where authorized.

- Identify user-created material and establish which preservation or export arrangements are available.

- Capture representative interface states and workflows, including the final operating state.

- Document ownership, licensing, access restrictions, and the location of preserved materials.

A complete preservation plan should also distinguish between public records and information that requires restricted access. User data, credentials, personal communications, and confidential technical material should not be collected indiscriminately. Institutional policies, applicable permissions, and professional archival standards determine what can be retained and made available.

From technical survival to historical access

Preservation succeeds at different levels. A file may survive without being readable. A document may be readable without retaining its original appearance. An application may run in an emulator without access to its original online community or commercial infrastructure. These are meaningful preservation outcomes, provided the limitations are described accurately.

Digital heritage therefore depends on maintaining a relationship between objects and their documentation. Future researchers need to know what an application did, how it was distributed, which technical conditions supported it, and what happened when its service ended. The immediate next step for an organization planning a shutdown is to assign an archival owner and create a preservation inventory before decommissioning any production systems.

Questions readers ask