Once the new system works, the old one is taken apart so completely that going back would mean a reconstruction project, and the debate over returning to the old way ends.
Borderline: whether this move is justified depends on the situation, and only the person in it can judge.
An example
A regional bank had run its old core banking platform alongside the new one for fourteen months, and every steering meeting reopened the question of rolling back. The chief operating officer waited until the new platform had closed two quarter-ends without a manual correction. Then she brought a decommissioning plan to the board: terminate the old vendor's support contract, migrate the last product lines, wipe the legacy environment, and move the twelve people who still maintained it onto the new platform team. One thing was kept on purpose, a read-only archive of eleven years of transactions that examiners could query. The board approved the plan in one session. Within a quarter the parallel license fees, about $2.3 million a year, were gone, and so were the rollback rehearsals. The next time a branch director complained about the new screens, the conversation was about fixing the screens.
Why it works
Dismantling the legacy makes staying on the new path easier, because the organization stops paying to run two systems and to defend the migration against every rollback proposal. Going back looks worse, since the old way no longer exists as a working option. And going back becomes far costlier: re-licensing software, rehiring people who knew the old system, rebuilding interfaces, and explaining the reversal to the board and auditors. A half-burned bridge invites a rollback campaign, so the destruction has to be complete, and the new system has to be at least good enough to run the business.
The thinking behind it
Thomas C. Schelling In The Strategy of Conflict (1960), Schelling argues that the power to bind oneself can be a source of strength: a party that visibly removes its own option to retreat forces the other side to adjust. Decommissioning the old platform is that move inside a company. Once the legacy is gone, the rollback debate has nothing to return to, and skeptics adjust to the new system because it is the only one there is.
Avinash K. Dixit Investment under Uncertainty (1994), by Dixit and Pindyck, treats irreversible commitments made under uncertainty as giving up an option: whoever can wait holds the value of learning more first. That is the cost side of a burned bridge. Wiping the legacy destroys the option to go back. The move therefore belongs after the replacement has proven itself and the decision is final, when little is left to learn.
When it fits
Migrations and new operating models that already work and keep getting relitigated are the case for it, where the cost of running both is visible and growing. You need the authority to sign decommissioning contracts and enough standing to absorb blame for the hard weeks of cutover. It does not fit a replacement still short of minimum viable, or a sponsorship that may not outlast the project.
How to use it well
Prove the new system first, against criteria agreed in advance, such as clean closes, uptime, or a full business cycle without workarounds. Then map what the old system does for processes nobody thinks of as part of it: feeds, reports, archives, audit trails.
- Keep what regulators and auditors require, in a form that cannot run the business.
- Retire everything else in one planned sequence, with dates, so nothing is left half-standing.
- Move the people who ran the old system into roles on the new one, so their skills stop being a constituency for going back.
- Tell the board what you are giving up, including the rollback option, and what it would cost to rebuild.
What it costs and where it backfires
You give up the rollback option, and that is a real loss if the new system fails in a way your tests missed. Burning the bridge over a weak replacement turns a migration problem into a crisis for the whole company. The sponsor carries the blame for every rough week of cutover, and a sponsor who leaves mid-burn leaves the project exposed. Everything here rests on proof and on timing. Dismantling before the decision is final forecloses a choice the board was owed, and hiding the replacement's condition to get the decommissioning signed conceals a material fact from the people approving it.
When it is used on you
You will see decommissioning contracts signed and legacy environments wiped before the replacement has been proven, and rollback rehearsals stop. Ask for the evidence that the new system is ready, insist that regulatory and audit capabilities survive, and push for a funded rollback option until the proof is in. Map which legacy functions other processes depend on before anything is shut down.