The question is rarely asked early. It usually arrives when a small change has taken unexpectedly long, when a security update is due, or when the developer who has always handled it announces they are leaving. Then it is suddenly in the room and an answer is wanted quickly.
The obvious answer is usually the wrong one. An old system feels like a case for a rebuild, and an expensive quotation feels like a case for repair. Both are decisions taken with the gut.
Three routes, not two
Setting rebuild against repair misses the route that wins in the majority of projects: step-by-step replacement. The new system takes over one area after another while the old one runs alongside and gradually shrinks.
Whether that route is open is decided by a single question. Can the old system be cut apart at a sensible point without everything wobbling?
When repair is enough
Repair is right when the core still holds and only the surroundings have aged. You can tell because the words inside the system are still the words of the business. An order is called an order and behaves like one; so does an invoice.
The structure then stays, and what gets renewed is the version, the dependencies, the interface and the places where debt has piled up. That is unspectacular, plannable and possible in stages that each leave the system running. How such a version jump goes is under Laravel versions and upgrades.
When only a rebuild remains
One finding genuinely argues for a rebuild: the domain model no longer fits. The system has no concept of a process your business has run for years, and people work around that with detours that are called something different in the program than in reality. When a complaint is recorded as an order with a negative quantity and a code in the notes field, that is not a blemish but a model that misses the point.
Two further reasons occur and weigh more than they sound. The technology is dead, because there is no security cover left for the language, the framework or the database and nobody wants to work with it. Or there is no access to the source code any more. In that case the decision has already been made for you.
Why the middle route usually wins
A rebuild in one go has a day on which everything has to work at once. Until then the old system still needs developing, because the business does not stand still, and the new system chases a target that keeps moving. Projects rarely fail on the technology; they fail on that simultaneity.
The step-by-step route trades that risk for effort. It needs a seam between old and new across which both sides talk, and a rule about which system owns which data. Building that seam costs time a rebuild would not spend. In return something is finished after every stage, and the whole thing can be stopped without everything being lost.
What the decision really turns on
Not the age of the code. There are twelve-year-old applications that develop beautifully and three-year-old ones where every change is a risk.
It turns on the state of the domain model, on whether the system can be cut apart, and on how much development has to continue during the changeover. Those three points can be settled in a few days, and settling them is considerably cheaper than guessing them.
How we go about it is under software modernisation.
