Every business eventually inherits an application that works but frightens everyone. Changes take too long, small edits break unrelated screens, and the person who built it is unreachable. The question is whether to repair or replace, and the honest answer depends on three things.
First: is the data model sound? Code can be rewritten incrementally. A data model that does not represent the business correctly poisons everything built on top of it, and fixing it is close to a rebuild anyway.
Second: how much behaviour is undocumented? An application that has run for years contains rules nobody wrote down, discovered only when they stop happening. A rebuild has to rediscover all of them; a refactor keeps them by default.
Third: what is the change you actually need? If the requirement is one new module, a rebuild is an expensive route to it. If the requirement is a different way of working, the old structure will fight you at every step.
We give this assessment before quoting, including when the answer is that the existing system is fine and the budget is better spent elsewhere. Recommending work that is not needed is a short-term win and a long-term cost.