The team that runs an old, critical system argues the real risks of retiring it, in terms executives can check, and wins either a reprieve or a slower and safer retirement.
Borderline: whether this move is justified depends on the situation, and only the person in it can judge.
An example
A reinsurer's transformation program planned to retire its twenty-five-year-old treaty accounting system within eighteen months. The head of policy administration, whose team of twelve ran it, thought the plan missed most of the risk, and she knew a warning about catastrophe would be heard as turf protection. Her team spent six weeks producing a dependency map and a list of the 212 calculations the system performed that the new platform's specification did not mention. She then asked for a test: three quarters of treaty statements run through both systems. The new platform produced 31 mismatches, four of them on the largest treaties. The steering committee moved to a phased retirement over thirty-six months and asked her team to lead the data migration.
Why it works
For the team that runs a legacy system, keeping it, or slowing its retirement, preserves their headcount, their expertise, and their seat at the table. Raising the real risks makes retirement look worse, because the promised savings shrink once the risks are priced, and costlier, because whoever sponsors the retirement now owns a visible chance of failure. It is strongest when the system handles a high-stakes function, when the team has access to senior leaders, and when the program has no workstream of its own for retirement. Concentrated knowledge gives the team its authority and also makes its claims suspect until someone can check them.
The thinking behind it
Oliver E. Williamson In The Economic Institutions of Capitalism (1985), Williamson describes asset specificity: knowledge of one firm's systems loses much of its value elsewhere, and once such investments are made, the parties depend on each other. The team that runs a legacy system holds exactly that kind of specific knowledge, which gives it bargaining power over the retirement plan and makes its cooperation in the migration worth paying for.
George A. Akerlof Akerlof's The Market for "Lemons" (1970) shows that when buyers cannot verify quality, they discount every offer, honest ones included. Executives who cannot check a legacy team's risk warnings treat them all as turf protection. Turning each warning into a testable claim, a dependency map, or a parallel run removes the information gap that makes honest warnings sound like special pleading.
Mancur Olson Olson's The Logic of Collective Action (1965) explains why concentrated interests tend to prevail over diffuse ones: a small group with much at stake organizes easily, while a large group sharing a small cost does not. A legacy team defends its system as a concentrated interest, while the integration costs it imposes are spread thinly across many other teams. Tracing those costs back to the system gives the diffuse side a reason to act.
When it fits
This suits a team that runs a critical system and believes a retirement plan underestimates the risk, with the evidence to show it: dependency maps, incident history, test results, the calculations nobody documented. It needs access to the steering forum and enough standing to ask for a test.
How to use it well
Turn every warning into something that can be checked.
- Write down each risk with its specific mechanism and a way to test it.
- Produce the dependency map and the documentation yourself, even though it weakens your monopoly on the knowledge.
- Propose a parallel run or a phased retirement in place of a single switch.
- Put the full cost of keeping the system on the table, including the integration spend other teams carry.
- Offer to lead the migration. A team that helps retire the system keeps a role in what replaces it.
What it costs and where it backfires
You will be read as protecting your own jobs, and every claim you cannot support costs you credibility on the ones you can. Keeping a system alive passes integration costs and slower change to the teams around it, and they will notice. Inflating risks you cannot support, withholding documentation to keep others dependent, or slowing work on the replacement would turn a defense into falsification and sabotage.
When it is used on you
Watch for one system scoped out of the transformation again and again while integration layers multiply around it and only one team can speak to its risks. Trace the scattered costs back to the system, ask for an independent risk assessment so warnings become testable claims, set up a retirement workstream with its own sponsor, and build knowledge of the system outside the team.