A rescue isn't a rewrite by default. Done well, it keeps what's valuable and fixes what's broken. Here is what the process actually looks like.
Stage 1: Honest assessment
Before touching the code, an incoming team reviews the codebase, architecture and history to work out what is salvageable and what is not. You get a straight picture of the state of things, often for the first time. An independent code review is usually the fastest way to get it.
Stage 2: Stabilise
Stop the bleeding first. That means fixing the critical bugs, security holes and broken builds that put the project at immediate risk, so the ground stops shifting before any new work begins.
Stage 3: Re-plan
With a stable base and a clear assessment, the path to "done" gets re-planned realistically, scope, sequence and timeline based on the real state of the code, not the original optimistic plan.
Stage 4: Deliver
Work resumes in short, visible increments so you can see progress and rebuild confidence. See how we approach project rescue; we've rescued more than 20 projects other teams couldn't finish.