Fred Lackey

Why Legacy Systems Persist

Legacy systems do not survive because they are good. They survive because they work — and because replacing them is genuinely hard. The codebase that ran fine in 1998 now carries twenty years of undocumented business logic, edge cases learned the expensive way, and institutional knowledge that lives only in the heads of engineers who may no longer be at the company.

Most modernization efforts fail not from technical incompetence but from underestimating this weight. A wholesale rewrite discards everything the old system knew. A naive incremental approach creates a system that is half-old, half-new, and fully incoherent. The path through requires both technical depth and organizational patience — an understanding that the goal is not to move fast, but to move without breaking the trust of the business that depends on these systems daily.

Forty years of working inside these systems — from founding-team work on Backup Exec in the early nineties through directing engineering at one of America’s largest insurers — has produced a specific, battle-tested approach to this problem.

Approach & Principles

Legacy modernization is not a technology problem. It is a trust problem. The business trusts the old system because it has proven itself over years of operation. Earning that same trust for the new system requires a disciplined, transparent approach that never leaves the business exposed.

Understand Before Touching

Every modernization engagement begins with deep archaeology. What does this system actually do? Not what the documentation says it does — what does it actually do? The gap between those two answers is usually where the hardest work lives. Weeks spent understanding a legacy codebase can prevent months of rework later.

Strangle, Don’t Detonate

The strangler fig pattern — incrementally routing traffic from the old system to the new one while both run in parallel — is the most reliable path through complex modernization. It enables progressive validation, rollback at any point, and gives the business continuous confidence rather than a high-stakes cutover event.

Preserve Business Logic, Transform Delivery

The logic embedded in a legacy system is often the most valuable thing in it. The goal is rarely to change what the system does; it is to change how it does it. Separating business rules from their implementation is both the hardest part and the most important architectural discipline in this work.

• Avoid “big bang” rewrites that replace certainty with risk across the entire business at once
• Establish clear seam points in the legacy system before writing a single line of new code
• Run old and new systems in parallel long enough to build genuine confidence in the replacement
• Document business logic as it is discovered, not after the migration is complete
• Measure operational metrics throughout — performance regressions in the new system erode trust faster than any bug
• Plan for the political dimension: modernization always has stakeholders who benefit from the status quo

Applied in Practice

Theory without application is speculation. The following engagements represent real modernization work — each with distinct constraints, timelines, and organizational contexts that required adapting the approach to the situation rather than applying a formula.

Common Failure Modes

The same failure patterns appear across organizations of every size. Recognizing them early is the most reliable way to avoid them.

Modernize vs. Rewrite

The most consequential early decision in any legacy engagement is whether to modernize incrementally or rewrite from scratch. Both are legitimate approaches. Neither is universally correct. The right answer depends on signals that must be honestly assessed before any architecture work begins.

Most real engagements land in neither extreme — they are hybrid approaches where specific modules are rewritten while surrounding systems are modernized in place. The discipline is in making that boundary decision deliberately, not by default.