The case for a rewrite is always persuasive. The existing system is genuinely difficult to work with, everyone can see it, and a clean start promises relief from accumulated compromise.
The case against is simply the record. Rewrites routinely take far longer than estimated, and while they run, the business is paying for two systems and getting improvements from neither.
The knowledge problem
An old system encodes years of decisions, many undocumented and some load-bearing. The odd conditional nobody understands is often a regulatory requirement, a workaround for a partner's behaviour, or a fix for an incident that predates the current team.
A rewrite starts by discarding that knowledge and rediscovering it through production failures. That is the real cost, and it is rarely in the estimate.
Replace at the seams
The alternative is to find a boundary, put an interface in front of it, and replace what sits behind it while everything else continues to run. Then do it again. Each step is small enough to reverse and delivers value before the next one begins.
It is less satisfying than a clean start. It also has the considerable advantage of working, and of being abandonable at any point without having destroyed anything.
Instrument before you touch anything
Before changing behaviour, make the current behaviour visible. Log the inputs and outputs of the component you intend to replace, in production, for long enough to see the real distribution of cases.
This almost always reveals usage nobody expected, and it turns the replacement from a guess into a specification you can test against.
When a rewrite is the right answer
Occasionally it is: when the platform is genuinely unsupported, when the system is small enough to hold in one's head, or when the business requirement has changed so fundamentally that the old model no longer describes reality.
The distinguishing feature of those cases is that the argument is about the problem, not about the discomfort of working in the existing code.
