Where it starts
With an inventory, not with opinions: what is installed, what was written
by hand, what runs on schedule, where the data actually lives. Half a day
of reading usually explains more than a week of meetings.
Then a short written answer: what is worth keeping, what is worth fixing,
and what is cheaper to rewrite than to repair.
What usually turns out to be true
The project rarely stalls on something exotic. It stalls on a scope nobody
wrote down, on custom code nobody can read, and on a database that was
never looked at until it got slow.
None of that is fatal. All of it is work that can be planned once it is
named.
What you end up with
A working system and a map of it: what each custom part does, what it
depends on, and what to watch. Written so the next engineer - not
necessarily me - can take over without archaeology.
And, if that is the honest answer, a straight recommendation to stop:
sometimes finishing costs more than starting over.