In 1086, William the Conqueror commissioned a survey of England written in ink on sheepskin parchment. You can still read it today, 940 years later. In 2019, MySpace vaporized fifty million songs during a routine server migration and shrugged. That contrast is the whole story of modern computing in miniature, and a sharp investigation into how the technology industry is erasing its own history argues that these disasters are not freak accidents — they are the predictable output of an industry that treats its own past as a liability line item. The evidence, once you start collecting it, is damning. And for developers, it is personal, because the things being erased are the exact artifacts we need to do our jobs.
Case File #1: The Migration That Ate a Generation of Music
Start with the most brazen example on record. In March 2019, MySpace quietly admitted that every audio file uploaded between 2003 and 2015 was gone — an estimated 50 million tracks from 14 million artists, as NPR reported when the scale of the loss became clear. The company blamed "a server migration project" and suggested users "retain your back up copies." Kickstarter's former CTO Andy Baio voiced what every infrastructure engineer was thinking: real migrations have checksums, verification passes, and rollback plans. The more plausible explanation was that hosting a decade of old MP3s cost money, and deleting them cost nothing.
For working developers, the lesson is chilling in a specific way. This was not a startup running out of runway. This was a platform that once outranked Google in U.S. traffic, holding the only existing copies of early recordings by artists like the Arctic Monkeys and countless unsigned musicians — and it discovered, correctly, that there is no penalty for destroying an archive. No regulator called. No fine was issued. The market did not care.
Case File #2: The Survey That Outlived Its Own Technology by Negative 900 Years
The second case is older and stranger. In 1986, the BBC marked the anniversary of William's original Domesday Book by building a modern sequel: over a million Britons, mostly schoolchildren, contributed photos, essays, and maps documenting daily life across the UK. The project was stored on custom laserdiscs readable only by a specially manufactured Philips player wired to an Acorn BBC Master computer. By 2002 — just sixteen years later — the hardware was nearly extinct and the archive effectively unreadable, prompting the memorable observation that the digital Domesday Book lasted 15 years, not 1,000, while its parchment predecessor remained perfectly legible in the National Archives.
The Domesday fiasco teaches a different lesson than MySpace. Nobody was negligent; everyone involved was ambitious, well-funded, and cutting-edge. That was precisely the problem. Proprietary formats, bespoke hardware, and undocumented dependencies are preservation poison, no matter how good the intentions. It took a multi-year academic rescue effort using emulation just to claw the data back. Every developer shipping data locked inside a closed SaaS platform today is building a thousand tiny Domesday discs.
The Pattern Behind the Wreckage
Line up enough of these incidents — GeoCities deleted with its 38 million handmade pages, Yahoo Groups purged with two decades of niche technical discussion, vendor knowledge bases folded into acquisitions and switched off — and a mechanism emerges. Digital history dies through a repeatable chain:
- Storage is an expense, so old data is the first budget cut when ownership changes or margins tighten.
- Formats and platforms are proprietary, so content cannot outlive the company that hosts it.
- Deletion is invisible, so there is no reputational cost until years later, when the loss is irreversible.
- Preservation is nobody's job title, so it happens only when volunteers like the Archive Team scramble in the final weeks before a shutdown.
Notice what is not in that chain: malice. The industry does not hate its history. It simply has no line item for remembering it, which in economic terms amounts to the same thing.
The Part Where You Come In
Here is the uncomfortable truth for engineers: we are simultaneously the victims of this amnesia and its foot soldiers. Every time we ship documentation exclusively to a hosted wiki we do not control, encode critical context in a Slack thread with a retention policy, or delete a "stale" repo that contains the only explanation of a production system's design, we are running our own tiny server migration project.
The countermeasures are unglamorous and cheap. Keep decision records in the repository, next to the code they explain, in plain text that will survive every platform of the next forty years. Export and archive vendor documentation your systems depend on, license permitting. Feed the Internet Archive proactively instead of assuming it will catch everything. Choose open formats for anything meant to outlive a product cycle, because the Domesday laserdisc is what "innovative storage" looks like two decades later. And when your organization proposes deleting old material to "reduce clutter," ask the question nobody asked at MySpace: who checked what is in there?
Parchment survived nine centuries because it required no permission, no player, and no hosting bill to read. Our industry has built the most powerful information machinery in human history on top of media that cannot reliably survive a budget meeting. Until we treat memory as infrastructure rather than overhead, every migration is a potential extinction event — and the next fifty million files are always one quiet Tuesday away from being gone.
Top comments (0)