Legacy Systems Are Not the Risk, Your Plan to Replace Them Is
Your oldest system has one advantage that gets little weight in a business case. Your people usually know how it fails. They know its limits, its workarounds, and what to do when it stops.
A replacement resets that knowledge on the day you go live. The new system arrives with failure modes nobody has seen, and a workforce that has not yet learned how to recover from them. The decision to replace and the decision to go live are different decisions. They deserve different scrutiny.
Why Legacy Systems Take the Blame
The case against old technology is real. In Information Technology: Agencies Need to Plan for Modernizing Critical Decades-Old Legacy Systems, published in July 2025, the United States Government Accountability Office (GAO) found that 7 of the 11 federal systems most in need of modernization run with known cybersecurity vulnerabilities, and 8 use outdated programming languages.
Age alone is not the test. Ashok Subramanian, Head of Technology, Europe at Thoughtworks, makes the point in A new era of modernization: Accelerating the journey to value. "Modernization doesn't always equal moving to the latest and greatest technology." Many systems have run for 30 to 40 years and still do what they were designed to do, he notes. The better test is fitness for purpose.
So replacement is often the right call. The trouble starts when leaders treat a sound decision as a safe one. An old system's risk builds slowly and shows up in budgets and delays. A replacement's risk can concentrate in a few days and land on customers, employees, and regulators at once.
McKinsey & Company and the BT Centre for Major Programme Management at the University of Oxford studied more than 5,400 IT projects. In Delivering large-scale IT projects on time, on budget, and on value, the authors reported that large projects, defined as those with initial price tags above $15 million, ran 45% over budget and 7% over time on average. They delivered 56% less value than predicted. The authors also reported that 17% of IT projects go so wrong that they can threaten the company's existence. The study dates to 2012 and its headline figures cover large programs, so read them as a gauge of scale.
The TSB Migration in 2018
In April 2018, TSB, a bank in the United Kingdom, moved its customers onto a new IT platform. According to the Financial Conduct Authority (FCA) and the Prudential Regulation Authority (PRA), the data itself migrated successfully. The platform did not hold. All of the bank's branches and a significant share of its 5.2 million customers felt the initial failures, and it took until December 2018 to return to business as usual.
The regulators fined the bank a combined £48.65 million in December 2022. Their release, TSB fined £48.65m for operational resilience failings, says TSB failed to organize and control the program adequately and to manage the risks from its critical outside supplier. Mark Steward, the FCA's Executive Director of Enforcement and Market Oversight, said the firm "failed to plan for the IT migration properly."
TSB's own account in TSB Board publishes independent review of 2018 IT Migration differs. It says planning began more than 4 years earlier, with nine successful dress rehearsals and a pilot of more than 1,600 employees. It also says two data centers were configured inconsistently, testing missed it, and customer contact volumes exceeded its contingency resources. TSB disputed parts of that review by Slaughter and May, then agreed in 2022 to resolve the matter with the regulators, which qualified it for a 30% penalty discount.
Four years of preparation left gaps where it counted. Testing the system is not the same as testing the organization around it, and someone has to absorb the surge when customers cannot get through.
Phoenix and the Cost of Holding the Date
The pattern shows up in the public sector too. The Government of Canada set out to replace a 40-year-old pay system used by 101 departments and agencies. In Building and Implementing the Phoenix Pay System, the Auditor General of Canada found that Public Services and Procurement Canada removed critical pay functions, curtailed system tests, and skipped a pilot to meet its budget and timeline. Executives ignored signs that the pay center, the departments, and the system were not ready.
Auditor General Michael Ferguson called the project "an incomprehensible failure of project management and project oversight." The audit found it cost hundreds of millions of dollars more than planned and affected tens of thousands of federal employees. Ferguson named three problems common to the project and the response that followed, weak oversight and governance, unengaged departments, and underappreciated risk.
The National Audit Office (NAO) found a similar record in the United Kingdom. In The challenges in implementing digital change, published in July 2021, it found central government digital change falling short across 25 years of strategies. Gareth Davies, its head, tied that record to technology choices made before the business problem was clear.
These cases do not make a rule. Most are far larger than what mid-market companies attempt. But governance fell short in TSB and Phoenix, and in both the plan stopped short of what happens when the new system meets real volume.
What the Old System Knows That Nobody Wrote Down
A replacement plan can fail because the old system holds knowledge no specification captured. In Strangler Fig, Martin Fowler writes that building a new system to copy the old one sounds easy, yet he and his colleagues have watched that plan fail most of the time. Existing behavior is hard to uncover, and some of it is not wanted at all. Subramanian adds that no single person in an organization sees everything a system does.
The people closest to the work often hold what the documentation misses. In Delivering large-scale IT projects on time, on budget, and on value, McKinsey described a bank whose finance department joined only months before go-live. Late accounting changes delayed the launch by more than 3 months and cost more than $8 million.
The UK Government Digital Service gives a related warning. Its guidance, Moving away from legacy systems, first published in 2016, says to use the changeover for a fresh look at how the organization works and warns "do not just re-create the same system with new technology."
Plan the Retirement as Carefully as the Launch
In Information Technology: Agencies Need to Plan for Modernizing Critical Decades-Old Legacy Systems, the GAO says a modernization plan should include, at a minimum, milestones, a description of the work, and details on the disposition of the old system. Of the 11 critical federal systems, 3 had plans with all 3 elements, 6 had partial plans, and 2 had none. The GAO warned that initiatives without complete plans face a higher likelihood of cost overruns, schedule delays, and outright failure.
Retirement is part of the plan. A replacement program is incomplete until leaders can say when the old platform stops processing transactions, how history stays accessible, what happens to open items during cutover, who owns exceptions, and what triggers a rollback. Without those answers, you have an installation plan, not a transition plan. The Government Digital Service guidance, Moving away from legacy systems, adds that stakeholders should agree on a switch-off date set not too close to the end of a legacy contract, since a delay could otherwise leave no choice but to renew it.
A Three Phase Approach to the Move
A working approach, built from the cases above, has three phases. It is judgment, not a research finding.
The first phase audits the work before you pick the technology. Map the existing workflows, reports, and manual overrides, and separate the steps that exist for a business reason from the steps that exist as workarounds. Clean and standardize the data before anyone writes migration scripts.
The second phase runs old and new side by side. Parallel running or phased departmental rollouts push real transaction volumes through the new system and surface exceptions no walkthrough will find. The Government Digital Service guidance, Moving away from legacy systems, describes a similar technique, sending queries to the new interface and comparing the answers with the old one.
The third phase gates the cutover on readiness, not the calendar. Set objective gates before full migration, such as error rates, processing speed, and how well staff handle exceptions. Train secondary owners on exceptions first, and keep the old environment in a read-only or fail-safe state until the new one proves stable.
Duration matters too. The McKinsey study found that every additional year spent on a project added 15% to cost overruns. A health care provider planning about $1 billion over 8 years, twice the size and length of any comparable project in the database, was stopped at the green-light stage and asked to add intermediate checkpoints. The revised estimate fell in line with comparable projects and kept the desired scope.
Replacement can also succeed. McKinsey reported that one large public-sector organization replaced about 50 legacy IT systems with a standard enterprise resource planning system over 3 years, on budget and on schedule, though analysis had predicted an $80 million to $100 million overrun.
Questions Before You Approve the Plan
Does the scope cover the work people do around the system, or only the software?
Which behaviors of the old system must survive, and which are you deliberately dropping?
What evidence will show the business is ready, and who has the authority to say not yet?
If the new platform underperforms after launch, who covers the surge in demand, and with what resources?
None of this argues for keeping aging technology. The case for replacing it is often sound, and the case for how and when you do it needs the same discipline as the business case. Your legacy systems keep running while you prepare. Use that time to scope the work around the system, test the organization, and stage the move.
The old platform is also the easier risk to see, because its flaws are documented. The replacement arrives with presentations and projected savings, and its weaknesses have not appeared yet. A known flaw and a promised benefit are different kinds of evidence.
Then ask who in your company has the standing, and the willingness, to say not yet.
When the Replacement Plan Needs a Second Look
When a system replacement, a growth push, or a leadership transition tests how your company operates, Aspirations Consulting Group helps mid-market and Fortune 1000 executives weigh the decision, shape the plan, and keep strategy, operations, and people moving together.
Get Sharper Operations Thinking Every Weekday
Request a complimentary subscription to ACG Strategic Insights and join more than 10 million current and aspiring executives who receive practical thinking on leadership, operations, and strategy every weekday.
Thanks for reading!
~ Jerry Justice
Living to Serve, Serving to Lead™
Comments