Conserving a digital work does not consist solely of ensuring it launches. A programme may execute and respond at a different speed, display a different image, or lose an interaction. Visible behaviour may also be preserved while the technical conditions that provided historical meaning to the work disappear.
Obsolescence compels one to choose which loss is acceptable. I read these cases from the perspective of digital creation, collecting, and documentation, rather than from emulator engineering.
Flash did not disappear in a day
Adobe ended support for Flash Player on 31 December 2020 and began blocking its execution on 12 January 2021. For works created with Flash, the problem was not merely opening an SWF file. Many integrated fonts, video, sound, scripts, interaction, or external resources.
Ruffle addresses part of the problem through emulation. The project is defined as an open-source Flash emulator written in Rust and capable of running in browsers via WebAssembly. That description does not equate to total compatibility: a work must be tested and compared.
The NEXT: conserving at scale without feigning equivalence
Electronic Literature Lab documented in 2026 the conversion via Ruffle of 680 versions of Flash works conserved at The NEXT. The laboratory compared those versions with legacy computers that still supported Flash or with Pale Moon. When the result did not sufficiently approximate the original, it tested Conifer.
The progressive withdrawal of Conifer necessitated a review of that strategy. In May 2026, the team reported that the 680 versions had been converted and that it was beginning to version them, retaining the original as version 1.0.
“Converted” does not mean “identical”. It means that a new, accessible version was produced within a process involving comparison, intervention, and version control.
When the conservation strategy ages
Preservation tools also become obsolete. A virtual machine requires a hypervisor; an emulator, maintenance; a web capture, a player; a migration, retaining the previous version and explaining the changes.
Digital conservation does not reach a final state. It organises relays between systems and leaves sufficient evidence to evaluate each one.
The Erl King: two versions face to face
The Erl King (1982-1985), by Grahame Weinbren and Roberta Friedman, combined obsolete hardware, software written by the artists, and components built for the work. In Seeing Double, held at the Guggenheim in 2004, the original version was displayed alongside an emulated version.
The Fondation Daniel Langlois documents concrete differences: the original employed an SMC-70, CP/M, Pascal, laser discs, and a Carroll touchscreen; the new version, a Sony computer, Linux, Java, flat screens, and Elo touch technology. The computer, operating system, language, audiovisual support, and screen were changed.
Emulation was not a silver bullet
Caitlin Jones’s study notes that there is no “silver bullet” for conserving electronic works. The project required artists, conservators, programmers, and technicians.
Emulation does not eliminate interpretation. One must define which environment is imitated, which differences are acceptable, and what occurs when the contemporary interface transforms the experience.
Comparing more than just execution
A test should separate execution, image and sound, interaction, space, technical history, and rights. Approving the launch does not automatically approve the other layers.
Version control is acknowledging intervention
Identifying the original as version 1.0 avoids presenting the conversion as if nothing had occurred. It is advisable to retain the received file, original environment, intervention, tool, date, person responsible, known differences, and resulting files.
What is conserved when not everything can be conserved
The Erl King received an individual and intensive intervention. The NEXT worked with hundreds of works and changing tools. Both cases show that conserving requires prioritising execution, appearance, interaction, historical support, access, or study. The choice must be declared.
What these cases do not demonstrate
They do not prove that Ruffle reproduces every Flash work without differences, that emulating is always preferable, that a work remains conserved forever, or that the most accessible version replaces the original.
To take action
The guide on obsolescence, migration, emulation, and reinterpretation assists in choosing and registering a strategy. To prepare dependencies, consult how to conserve creative code. For web works, consult how to conserve a web work or a net art project. For the accounts, services, and domains upon which a work depends, consult invisible dependencies in digital art.
About the open conversation
It remains to be defined what it means for a work to 'function again'. Is it sufficient that it executes, or must its behaviour, temporality and appearance also be preserved? Furthermore, when migrating, emulating or converting, which losses are considered acceptable and who declares them?
Executing a work again does not, in itself, demonstrate that it has been preserved in its entirety. Nor are the cases reviewed sufficient to establish a threshold of admissible loss or to compare methods between works of a different nature.
If you possess comparisons between versions, known faults or documentation of interventions, and you are able to share them with their context, this notebook remains open: write to me.