Older software is often spoken about as a problem to be replaced. In many organisations it is also the thing that still takes bookings, holds records or keeps a service running.
That changes the decision. A rewrite can look cleaner on paper and still be the riskier option if the current system is poorly understood or cannot be switched off.
Start with an appraisal, not a rebuild plan
A useful first step is a plain account of the current state: what the system does, who depends on it, which parts are fragile, and which risks are urgent.
That appraisal should separate three things:
- work that needs to happen soon because of security, hosting or reliability;
- improvements that would make the system easier to run;
- ideas that can wait until the live service is stable.
Stabilise before you widen the scope
If the platform is already difficult to deploy, restore or understand, adding features will not help. The first improvements are usually unglamorous: supported language or framework versions, clearer authentication, fewer abandoned dependencies, and a way to release changes without guesswork.
Once those foundations are steadier, it becomes possible to decide whether a staged rebuild is justified.
Rescue is a delivery problem as much as a technical one
Projects stall for more than one reason. The code may be unfinished, but so might the scope, the decision-making or the handover. A rescue piece of work has to look at all of that, otherwise the same stall appears under a new name.
Deploy’s approach is to make the next step small enough to complete, visible enough to review, and safe enough that the live operation can continue.