The case for a rewrite is always persuasive. The existing system is hard to change, nobody enjoys working on it, and a clean start promises relief. The case against is that rewrites take longer than estimated, deliver nothing until late, and often end with two systems to maintain instead of one.
Move it first, improve it after
Lifting a system onto cloud infrastructure largely as it stands is unglamorous and often the right first step. It is reversible, it finishes, and it gets you predictable environments, backups and monitoring. It does not fix the architecture, but it makes the next change safer.
Carve off the parts that change most
Rather than replacing everything, identify what changes most often and extract it. New work happens in the new component; the old system keeps serving what it already serves. Each step is small enough to abandon if it turns out badly.
Put a boundary in front before you change behind it
An interface in front of the old system means callers do not have to know what sits behind it. You can then replace the implementation gradually without coordinating every consumer at once.
What to settle before starting
What the system must keep doing exactly as it does now, including the behaviour nobody documented.
Which data is authoritative, and what happens when old and new disagree during the transition.
How you roll back a step, and who decides.
What you will stop doing to make room for the work. Modernisation competes with features, and pretending otherwise is how it stalls.
A rewrite is sometimes genuinely the right answer. It is just rarely the first one, and it should be chosen with the costs on the table rather than because the current system is unpleasant to work in.