Which three things settle it?
The data model. If the data is sound, the interface and the code can be rewritten; if the model is broken, everything built on it is broken too. The most valuable thing to rescue is usually the data rather than the code.
Then whether the code is readable and runnable: can a new developer stand the project up on their own machine? And whether the business rules are written down. If the rules live only in the head of the person who left, reading the code still does not explain what it does.
When is rebuilding cheaper?
If the codebase will not run, if dependencies have gone so long without updates that the upgrade path has broken, or if the data model does not match the reality of the business, rebuilding is almost always cheaper.
And the sum should not be done by looking at what was already spent. That money is gone and should not shape today’s decision; the only question is which route costs less from here.
Is partial recovery possible?
On most jobs that is the right answer. The data is preserved, the modules that work are left alone, and the failing part is rewritten and integrated.
It spreads the risk and keeps the company trading. Replacing everything at once, on a project that has already stalled once, creates the chance of stalling twice.
What should you ask of the incoming team?
A team that agrees to take a system over without reviewing it has priced a risk it has not seen, and that price gets overrun. What to ask for first is a written assessment.
It should contain: an inventory of access and assets, the state of the code and the data model, security findings, and the three options — continue, partial rewrite, rebuild — compared on cost and risk.