Legacy modernisation for the system nobody wants to touch

Almost always incrementally. A rewrite requires knowing exactly what the current system does, and if that were true it would not be a legacy system. Incremental replacement lets you verify each piece against the original and stop if the value is not there.

Yes, and that is the common case. Behaviour can be established from the code, the data and observation of what it actually does in use. It takes longer than working from documentation, which is why the assessment stage exists.

Sometimes that is right, and we will say so. A stable system doing a well-defined job may not be worth touching. The question is whether you can still get security patches, still hire people who can maintain it, and still connect the things the business now needs.

By not switching anything off until the evidence says nothing depends on it. Running old and new in parallel and comparing behaviour finds the undocumented dependencies that no amount of planning would have surfaced.

Usually, because incremental replacement means the system keeps running while pieces move. That is one of the strongest arguments against a single large cutover.

Longer than a rewrite proposal will claim, and it is spread across the work rather than concentrated in one release. The assessment gives you a scoped view of each option so the decision is made with real numbers.