The Social Security Administration processes benefits for over 70 million Americans. The core systems that handle those calculations run on COBOL, a programming language first released in 1960.[1] The code works. It has worked for decades. And almost nobody left knows how to maintain it.

In 2017, the SSA announced a multi-billion dollar plan to modernize these systems. The effort was expected to take about five years. Then the pandemic hit, and the project stalled.[2] As of 2025, the COBOL is still running, still processing trillions of dollars, still holding together a system that tens of millions of people depend on every month.

The previous posts in this series explored systems where planks are replaced freely: microservices designed for impermanence, codebases rewritten piece by piece, open source projects that fork and diverge. Legacy systems present the opposite problem. The ship's identity is perfectly preserved. Every original plank is in place. But the wood is rotting, the builders are gone, and nobody is sure which planks are structural.

The COBOL Problem

COBOL processes an estimated $3 trillion in daily commerce worldwide.[3] It runs ATM transactions, insurance claims, banking operations, and government benefits. The language is older than most of the people who depend on the systems it powers.

The problem is straightforward: the developers who wrote these systems are retiring or have already retired. Universities stopped teaching COBOL decades ago. The institutional knowledge of how these systems work, why specific decisions were made, and what undocumented behaviors downstream systems depend on is disappearing with the people who built them.

This creates a peculiar identity crisis. The system's identity is intact in every technical sense. The code hasn't changed. The behavior hasn't changed. The inputs and outputs are the same as they were thirty years ago. But the human understanding of the system is eroding. The ship is the same ship, but the crew that knows how to sail it is gone.

Preservation Without Understanding

There's a concept in philosophy called "zombie knowledge": information that exists in a system but is no longer understood by anyone. Legacy codebases are full of it. A conditional branch that handles an edge case discovered in 1987. A workaround for a bug in a mainframe operating system that was patched in 1994 but the workaround was never removed. A calculation that produces correct results for reasons nobody can explain.

The code is documentation of decisions made by people who are no longer available to explain them. Each line is a plank placed by a specific shipwright for a specific reason. Remove it, and you might sink the ship. Leave it, and you're maintaining something you don't fully understand.

This is the anti-Theseus problem. In the classic paradox, the question is whether replacing planks changes identity. In legacy systems, the question is whether keeping all the original planks preserves identity when the knowledge of why they were placed is lost. The material is the same, but the understanding that gave it meaning has evaporated.

The SABRE System

American Airlines and IBM built the SABRE reservation system in 1960.[4] It was one of the first large-scale real-time transaction processing systems ever created. Over six decades later, the system's descendants still process airline bookings worldwide, serving over 350,000 travel agents and more than 400 airlines.

SABRE has been modernized repeatedly over those decades. The hardware has changed. The interfaces have changed. Layers of abstraction have been added. But core booking logic, refined over sixty years of edge cases and regulatory requirements, carries forward. The system embodies accumulated knowledge that would be extraordinarily difficult to recreate from scratch.

This is what makes legacy systems so resistant to replacement. The code isn't just instructions for a computer. It's a repository of institutional knowledge, encoded in conditionals and exception handlers. Every bug fix represents a real-world scenario that someone encountered and solved. Rewriting the system means rediscovering all of those scenarios, and you won't know which ones you've missed until they cause failures in production.

The BBC Domesday Paradox

In 1986, the BBC created a digital version of the Domesday Book to mark the 900th anniversary of the original. Thousands of people contributed photographs, maps, and descriptions of life in Britain. The data was stored on custom LaserDiscs readable only by specially modified BBC Micro computers.[5]

By 2002, the project was essentially unreadable. The LaserDisc players had failed. The BBC Micro computers were museum pieces. The software was incompatible with anything modern. A £2.5 million digital archive, designed to be a time capsule, became inaccessible in sixteen years.

Meanwhile, the original 1086 Domesday Book, written on vellum with ink, remains perfectly readable after nearly a thousand years.

This is a different kind of legacy problem. The BBC Domesday Project didn't rot from neglect. It was abandoned by the ecosystem around it. The data was fine. The medium was fine. But the tools needed to access it disappeared. The ship was seaworthy, but the harbor dried up.

Digital preservation faces this challenge constantly. File formats become obsolete. Hardware interfaces disappear. Software dependencies stop being maintained. A system can be perfectly preserved in every technical sense and still become inaccessible because the context it depends on has moved on.

Windows and the Burden of Compatibility

Microsoft Windows represents perhaps the most ambitious attempt to solve the legacy problem through sheer backward compatibility. Windows 11 can still run applications designed for Windows Vista and, in many cases, software from even earlier versions.[6]

This compatibility comes at enormous cost. Raymond Chen, a veteran Microsoft engineer, has written extensively about the lengths Windows goes to in order to keep old software running. The operating system contains compatibility shims, special-case code paths, and workarounds for bugs in third-party applications that shipped decades ago.[7]

From a Ship of Theseus perspective, Windows is fascinating. The operating system has been rewritten multiple times. The kernel has changed. The UI has changed. The architecture has changed. Almost no original code from Windows 1.0 survives. Yet it maintains behavioral compatibility with software from the 1990s. The planks are all new, but the ship still accepts cargo designed for the original vessel.

This is identity through contract, taken to an extreme. Windows defines itself by what it promises to run, not by what it's made of. The identity lives in the compatibility guarantee. Break that guarantee, and you've changed what Windows is, regardless of what the code looks like.

The Fear of Change

Legacy systems persist partly for technical reasons and partly for psychological ones. The technical reasons are real: the system works, the replacement is risky, and the cost of failure is high. But the psychological reasons are equally powerful.

When a system has been running for decades without major incident, there's a strong institutional bias toward leaving it alone. "If it ain't broke, don't fix it" is a reasonable heuristic, but it ignores the slow accumulation of risk. The system isn't broken today. But the people who can fix it when it does break are disappearing. The hardware it runs on is no longer manufactured. The security vulnerabilities in its dependencies are no longer patched.

The fear of change creates a paradox: the longer you wait to replace a legacy system, the harder and riskier the replacement becomes. Dependencies accumulate. Institutional knowledge fades. The gap between the legacy system and modern alternatives widens. Each year of delay makes the eventual migration more expensive and more dangerous.

This is the Ship of Theseus in reverse. Instead of asking "if you replace every plank, is it still the same ship?" legacy systems force the question: "if you never replace any planks, is it still a functioning ship?" The identity is preserved, but the viability is declining.

The Emulation Layer

One common approach to legacy preservation is emulation: building a new system that mimics the behavior of the old one. Banks run COBOL emulators on modern hardware. Museums run BBC Micro emulators to access old software. Gamers run console emulators to play titles from the 1980s.

Emulation is philosophically interesting because it creates a system that is materially different from the original but behaviorally identical. The emulated COBOL environment runs on x86 processors instead of mainframes. The instructions are different. The memory architecture is different. The timing is different. But the COBOL code runs the same way and produces the same results.

Is an emulated system the same system? By the material theory of identity, clearly not. By the functional theory, arguably yes. The emulator preserves the behavior, which is what matters for the downstream systems that depend on it.

But emulation has limits. It preserves the behavior of the system at a specific point in time. It doesn't preserve the ability to modify or extend the system. You can run old COBOL on an emulator, but you still need COBOL expertise to change it. The ship sails, but you can't add new planks.

What Legacy Systems Teach Us

Legacy systems reveal something important about the Ship of Theseus that the other cases in this series don't: identity requires more than material preservation. A system can retain every original component and still lose its identity in a meaningful sense, because identity also depends on the human context around the system.

A codebase that nobody understands is a ship that nobody can sail. The planks are all original, the hull is intact, the mast is straight. But the navigation charts are lost, the crew is gone, and the harbor it was built for no longer exists.

The microservices philosophy says identity lives in contracts and relationships, not in components. Legacy systems suggest something additional: identity also lives in the understanding that humans have of a system. When that understanding is lost, the system becomes an artifact rather than a tool. It still exists, but it no longer fully functions as what it was meant to be.

The ancient Athenians maintained the Ship of Theseus as a monument. They replaced the planks to keep it seaworthy. But imagine if they had preserved every original plank and simply forgotten how to sail. The ship would be perfectly authentic and completely useless.

That's the legacy system problem. And it suggests that the Ship of Theseus isn't just about material and form. It's about the living relationship between a thing and the people who use it.

References

[1] "Millions of 'dead' Social Security recipients actually caused by a COBOL coding quirk," TechSpot, February 26, 2025. https://www.techspot.com/news/106926-millions-dead-social-security-recipients-actually-caused-cobol.html

[2] "DOGE reportedly planning to rewrite Social Security Administration's software," SiliconANGLE, March 28, 2025. https://siliconangle.com/2025/03/28/doge-reportedly-planning-rewrite-social-security-administrations-software/

[3] "The $3 Trillion Code Nobody Knows How to Fix," Metaintro, 2026. https://www.metaintro.com/blog/cobol-developer-shortage-legacy-systems-career-opportunity-2026

[4] "SABRE Airline Reservation System," Engineering and Technology History Wiki. https://ethw.org/SABRE_Airline_Reservation_System

[5] Robin McKie, "Digital Domesday Book lasts 15 years not 1000," The Guardian, March 3, 2002. https://www.theguardian.com/uk/2002/mar/03/research.elearning

[6] "How Microsoft dealt with compatibility issues in Windows 95," The Register, November 13, 2025. https://www.theregister.com/2025/11/13/microsoft_windows_compatibility_chen

[7] "Outdated and Old IT Systems Slow Government and Put Taxpayers at Risk," U.S. Government Accountability Office, 2025. https://www.gao.gov/blog/outdated-and-old-it-systems-slow-government-and-put-taxpayers-risk