Your digital preservation program likely includes migration strategies, format registries, and perhaps some cloud storage. But when a researcher asks to access a 1995 CD-ROM or a Flash-based artwork, you're facing a different problem. Emulation is gaining traction in digital preservation, yet many institutions still treat it as an experimental side project rather than a core service.
That's changing. As collections accumulate more software-dependent materials, myths about emulation hinder practical implementation. Here's what you need to know.
Myth 1: Emulation and Virtualization Are the Same Thing
Reality: They solve different problems, and the distinction matters for your preservation strategy.
Virtualization runs modern software on modern hardware by creating isolated environments. For instance, Queen's University Archives used virtualized solutions for Flash-based artworks and database-driven websites, running these on lightweight virtual machine servers for gallery exhibitions.
Emulation recreates obsolete hardware environments in software. It's necessary when the original computing environment no longer exists. If you're preserving something that requires Windows XP and can't run on anything newer, you're in emulation territory.
For your retention schedule, virtualized content may have a clearer migration path. Emulated content requires ongoing maintenance of the emulation environment itself.
Myth 2: Users Won't Understand How to Access Emulated Content
Reality: The social challenges outweigh the technical ones, focusing on trust, not complexity.
Yale Library runs the only academic library unit dedicated to software preservation and emulation. When they started offering access through Emulation-as-a-Service-Infrastructure (EaaSI), they expected technical barriers. Instead, the main challenges were building relationships and establishing trust with faculty and researchers.
Researchers don't ask for "EaaSI access." They come with a problem: "I need my students to see this 1995 interactive CD-ROM" or "I have early 2000s Word documents that won't open." Yale's team works backward from that need.
In spring 2025, they supported two classes: Film & Media Studies students accessed a 1995 CD-ROM simultaneously (25 students), and Global Affairs students worked with early 2000s documents. The focus was on integrating born-digital archival materials into coursework, not on emulation mechanics.
Your communication strategy should focus on what the user gets access to, not how the technology works.
Myth 3: Emulation Projects Succeed or Fail on Technical Merit
Reality: Time constraints kill more projects than technical limitations.
Yale's team noted that problems rarely proved unsolvable with EaaSI. They failed because the researcher had to move on before the preservation team could investigate the material, locate legitimate legacy software, test multiple computing environments, and document access instructions.
Consider what that means for your service model. You need time to:
- Examine the born-digital material closely
- Identify the appropriate legacy software
- Acquire a legitimate copy (sometimes from eBay)
- Test the material in different environments
- Compare renderings to find the most appropriate one
- Write instructions for the end user
The University of Cambridge faced similar constraints with Minecraft Cambridge, a world created by over 1,000 university community members during the pandemic. The technical work was manageable, but deciding how to represent it, managing over 1,000 potentially identifiable player files, and documenting the preservation decisions took months.
Myth 4: Emulation Preserves the "Original" Experience
Reality: You're creating a documented version, and artist or creator input determines authenticity.
When Queen's University Archives revived digital artworks, they worked directly with artists when possible. One artist didn't mind creating versions of her work, which gave the team flexibility. For artworks without artist input, they avoided changes and relied on extensive documentation.
The project was informed by DOCAM guidelines and included hours of video with artists, including walkthroughs and conversations about intent. The ephemeral nature of the works came up repeatedly.
Cambridge's Minecraft world presents a similar question: should they provide gameplay videos, interactive access in a reading room, or world downloads? Each choice creates a different representation. The deposited version is from September 21, 2020, before the start of Michaelmas term. That cutoff point was a curatorial decision, not a technical requirement.
Your preservation description should document what changed and why. The emulated version isn't the original; it's a maintained artifact with its own provenance.
Myth 5: Licensing and Expertise Are Insurmountable Barriers
Reality: They're real obstacles, but institutions are solving them through shared infrastructure and documentation.
Queen's team struggled to find a Windows XP license. Yale manages controlled access to EaaSI to handle licensing constraints. Cambridge runs Minecraft Java Edition and depends on technology owned by Microsoft.
These aren't solved problems, but they're manageable within a service framework. The EaaSI platform has a public roadmap showing ongoing development. Yale shares their approach through guides and can be reached at [email protected].
Expertise is harder. Queen's identified "losing expertise" as a sustainability concern alongside obsolescence of source files and funding. But documentation helps. Cambridge published detailed case studies. Yale tailored implementations to known limitations rather than waiting for perfect solutions.
What to Do Instead
Stop treating emulation as an all-or-nothing decision. Start with:
Identify your actual demand. Yale noted that requests for emulation are increasing but still relatively low compared to other collection access. Measure before you build.
Document your current software-dependent materials. You probably have Flash content, obsolete word processing files, or database-driven projects already. Knowing what you hold shapes your preservation strategy.
Build relationships before you need them. Yale's experience shows that social challenges come first. Talk to researchers, faculty, and donors about software-dependent materials now.
Start with virtualization for recent materials. Queen's approach of using VMs for gallery exhibitions is less complex than full emulation and meets many access needs.
Plan for time, not just technology. Your service model needs to account for investigation, testing, and documentation time, not just the final emulated environment.
Contribute to shared infrastructure. Individual institutions can't maintain every emulation environment. Platforms like EaaSI exist because the problem is too big for solo efforts.
Emulation isn't a side project anymore. It's becoming a standard part of digital preservation service delivery. The myths are clearing, and practical frameworks are emerging from institutions willing to document what actually works.
