Legacy Is Not a Failure State

After thirty years in retirement technology — including a decade building a recordkeeping system from the ground up — I've watched the word "legacy" do a lot of damage. In most industries, legacy is shorthand for systems that should have been replaced years ago. In retirement, it usually means something different: systems that work, that have absorbed two decades of business rules and edge cases, and that nobody on the current team fully understands.

Those are not the same thing. Conflating them is the most expensive mistake leaders make in this space.

What "legacy" actually contains

A retirement recordkeeping platform that's been in production for 20 years isn't just code. It's the operational substrate of the firm. Inside that code base lives:

• Plan rule logic accumulated across thousands of plans, including the workarounds for every plan amendment, sponsor request, and acquisition the firm has absorbed
• Compliance handling for every regulatory shift since the system was built — SECURE 2.0, ERISA changes, hardship rules, Roth catch-up logic, the lot
• Integration scaffolding with payroll providers, custodians, trading platforms, NSCC, DTCC, and dozens of internal systems
• Operational know-how encoded as scripts, configurations, and conditional logic — most of it written by people who are no longer with the firm

The system runs because all of that machinery interacts correctly. Saying "we'll replace it" doesn't replace the system. It replaces the visible 20%, leaves the embedded 80%, and quietly transfers the institutional risk onto whatever team has to reconstruct decades of business rules from scratch.

The two failure patterns

In the engagements I've worked, every modernization that went wrong followed one of two patterns.

Pattern 1 — The replacement that wasn't. A firm commits to replacing a legacy core. The new platform launches. The old platform stays in production because the new one can't yet handle 15% of the plan configurations. Three years in, the firm is running two platforms simultaneously, with most of its development capacity going to keeping the old one alive while the new one slowly absorbs functionality. Total cost is 3-4x the original estimate. The legacy that was meant to disappear is now part of the operating model indefinitely.

Pattern 2 — The paralysis. A firm acknowledges the legacy risk but won't fund modernization at the scale required. Instead, it adds a thin wrapper of new tooling around the core — a portal, an analytics layer, a reporting tool. The legacy keeps running, but now there's more attack surface and more dependency. When the senior operators retire, the wrapper survives. The core doesn't.

The middle path — modernize selectively, preserve operationally, document aggressively — is the one that consistently works. It's also the least exciting one to put in a board deck, which is part of why it's underused.

What modernizing legacy actually looks like

When the engagement is structured to preserve operational integrity, the work falls into a predictable sequence:

Document what the system does. Not the architecture diagram — the actual behavior. What does the contribution posting job do when it encounters an unmatched deduction code? What happens to vested balances when a plan amendment changes the schedule mid-year? The answers exist in the code; getting them out requires people who can read it. We've spent entire engagements parsing 35,000+ custom scripts across a single platform to build this kind of documentation.

Stabilize the volatile parts. Some portions of any legacy system are stable and don't need attention. Others have been patched repeatedly and are accumulating defect risk. Identifying and shoring up the second set, while leaving the first set alone, is the kind of triage that prevents production incidents.

Modernize the boundaries. The places where the legacy core touches the outside world — payroll feeds, participant interfaces, sponsor reporting, compliance outputs — are where modernization delivers the most value with the least risk. API layers, modern reporting infrastructure, and decoupled experience layers can be built around a stable core without touching the engine itself.

Plan the retirement, don't force it. Some components of every legacy system genuinely should be retired. The discipline is in choosing them carefully, sequencing the replacement so production stays intact, and accepting that a 5-year roadmap is honest where a 2-year one is fiction.

The reframe

The most useful thing any retirement technology leader can do is stop treating legacy as a failure state. The platforms that survived 20+ years of operation are the ones that worked. The work isn't to erase them. It's to extend their useful life, document the institutional knowledge inside them, and modernize around them in a way that doesn't ask anyone to bet operations on a rewrite.

The firms that get this right keep running. The ones that don't usually find out the hard way.