The comparison now reaches the reader before the decision does. Departments publish the month in which named legacy services will be refactored, migrated or replaced, so a proposal sits beside a dated plan for a comparable service and has to stand on its own evidence. The reader gains a starting point that once had to be assembled from nothing, and loses the room to wait a year in silence.
The principle is narrower than the phrase suggests. A legacy system upgrade is not the purchase of a newer system. This is a decision about which behaviour of the current system must keep producing precisely the same answer, taken before a user chooses a technology. Everything below is a check on whether that decision exists, ordered by the moment at which it can still change the outcome.
Three live software applications show the shape. The roadmap for modern digital government records that the Department for Work and Pensions has committed to refactoring the Severe Disablement Allowance service by December 2026, with all cases migrated and payments made through the new service; that the Home Office has been moving police forces and agencies from the Police National Computer onto the Law Enforcement Data Service since September 2025; and that from March 2026 the Department for Environment, Food and Rural Affairs is migrating nineteen critical legacy applications to the cloud and decommissioning two legacy data centres. One of those is a rewrite of rules, one is a replacement of a data service that other organisations read from, and one is a move of applications whose dependency map was never complete. The checklist that follows is written to tell the difference before the money is spent.
The fortnight before approval is sought
The reader can or cannot see the user who has the business decision. Naming the technical lead, the platform lead and the delivery manager does not answer the question. The reader either has or has not got a written statement of the answers the system must keep producing, agreed by the department that consumes them. The reader either has or has not read the published milestone for a comparable service; a case made without it is a case made blind.
Two registers decide this stage. GOV.UK's managing legacy technology guidance says a body may not be confident that it has all the information about its systems and infrastructure and suggests regular reviews, so an estate map older than the last review cycle does not pass the check. The same guidance calls for a complete and accurate register of data assets, maintained for security and privacy reasons and checked regularly, so a register that has not moved since the last change to the estate also falls short. GOV.UK adds that retaining legacy systems beyond the best viable point of depreciation or replacement carries higher risks and costs, which is the sentence to put in front of people arguing that nothing needs to happen.
Before a route is named
The reader either can or cannot state which behaviour each candidate route preserves. Catapult shows retain, retire, rehost, replatform, refactor, rearchitect and replace as ways to modernise a legacy system, and the Kodesage guide uses these same paths in a decision process, with both marking the main business constraint as the factor that determines the path. A reader who has already chosen a platform before choosing a route has answered the wrong question first.
The commercial status is either settled before design begins or it is not. The Cabinet Office digital handbook points to the Government Commercial Function's guidance on legacy IT, which advises incorporating clauses that require regular updates and maintenance so that systems do not become obsolete, and to the Legacy IT Risk Assessment Framework used across ministerial departments. A reader whose support contract has no exit clause and whose supplier has no obligation to keep the product current is in a different situation from one whose contract carries both, and the difference should be addressed in the case before the first design meeting.
Before the first line of the replacement is written
The parallel-run plan either has an assigned lead or it does not. The measure of progress is either traffic moved or code moved. The rollback time for a migrated service is either stated in minutes or it is undefined. Catapult's guidance observes that running old and new capabilities in parallel can reduce risk for critical systems, so the archaeology of undocumented business rules stays in the critical path of every programme that dropped its parallel run to save a quarter.
The rule that decides each application is either written before the application register is opened or it is written afterwards to fit what the register showed. Those who know the undocumented rules are either interviewed and their answers written down, or they remain the only copy. The security status of every component that no longer receives vendor patches is either logged with the control that blocks an attacker or it is assumed.
While both systems are in service
The limit between the old estate and everything built since either has one proprietor or it has none. Every interface across that limit has a designated manager, a written direction of travel, a contract reference, and a dated log showing it still carries traffic after the last change at either end; an interface missing any of those is an interface no one is defending. The read path either sits off the transactional core or it competes with the payments.
The charge register shows every recurring payment with the user who must halt it and the date it ends, or it shows costs without a user. The old system either has a decommissioning date or it stays indefinitely, and that decision is made now.
Before switch-off
Every rule that affects a payment or a price is either written down with a test that demonstrates it, or the new system is being trusted. Retention and archiving decisions are either made and documented or they will be made under pressure. The support contract is either terminable without penalty on the planned date or the plan has to move. The receiving team is either identified and trained or the knowledge is lost when the project ends. GOV.UK's guidance on skills is blunt about this: the people who bridge the gap between legacy and new technologies are the asset, and a team that has not been built during the programme will not be built after it.
The month after switch-off
The new system either produces the same answer on the sampled cases or the differences are written down and accepted by the function that consumes them. The old system either remains available read-only with a decommissioning date or it has gone without one. Someone outside the original programme either can or cannot operate the replacement without the team that built it. The estate register has either started the next entry or the software has ended at a single system.
A legacy system upgrade rarely breaks because the code is hard. The upgrade is unsuccessful because the answer the old system gave was never written down, so no one could tell whether the replacement gave the same one. The checks above are variations on a single question, which is whether the software captured the behaviour it was protecting while the system holding that behaviour still ran.