Legacy usually does not mean broken. It means the system still does its job, but changing it is slow and frightening, the person who wrote it has moved on, and it is pinned to something that is going out of support.
The instinct is to rewrite it. Rewrites are the highest-risk option available, because the old system encodes years of small decisions nobody wrote down, and the new one has to rediscover all of them while the business keeps running.
The lower-risk path is to put the new system alongside the old one and move one capability at a time, with both running until the new one is trusted. It takes longer on paper and goes wrong far less often.
When the platform is genuinely unsupportable, when the domain has changed so much that the old model is wrong, or when the system is small enough that a rewrite is weeks. We will say which of these applies rather than defaulting to the bigger project.
Yes - that is the normal case here. The first piece of work is usually an assessment so everyone knows what is actually there.
There usually is not. The system and its database are the documentation, and reading them is part of the assessment.
Not necessarily. Sometimes the right answer is to keep the platform and fix the parts that make change expensive.
Tell us what you are trying to do. If something off the shelf already does it, or the job is smaller than you think, we will say so.
Get in touch