Every rewrite I have seen started with the team's understanding of the old system: what it does, which parts matter, which parts can go. The team is usually right about most of it. The part it is wrong about is the part that hurts, because a rewrite reproduces what the team understands and silently drops the rest.
What the users know
The people who use a system every day carry a model of it that no document has. They know the workaround that has quietly become the main workflow. They know the export that is pasted into a spreadsheet every Friday and drives a decision nobody on the engineering team has heard of. They know that the fields have to be in that order because the form is filled out while someone is on the phone, reading from a card. They know which error message means try again and which means call someone.
None of that is in the code in a way an engineer would recognize as a requirement. It is in the code as an accident, a field order someone chose in 2015, a report that was a favor, and the rewrite plan reads those as things to clean up.
Why asking is cheap
A rewrite is the most expensive thing an engineering team does. A conversation with a user is one of the cheapest. The asymmetry is the whole argument. An hour with five people who use the system will not tell the team everything, but it will almost always turn up the one thing that would have been discovered in production, after the launch, by the person it broke.
So I think the conversations belong before the plan is set, not after the design review, when the shape of the new system is already a thing people are attached to.
What I ask
I do not ask what they want, because the answer is a feature list and I cannot tell which items matter. I ask what they do. Walk me through yesterday. What did you open first. What did you do with that. What happens when it goes wrong. What do you do with the thing at the end.
I ask what they would miss. If this screen were gone tomorrow, what would break in your day. The answers are specific and often surprising, and they are a list of things the new system must do whether or not anyone on the team thought of them.
And I ask what they hate, because the things people hate about a system are often the things the team is about to faithfully reproduce, on the theory that the old behavior is the spec.
What I do with the answers
The answers go into the plan as requirements, with the user's name attached, so that when someone in a design review proposes dropping the Friday export, there is a person to talk to rather than a guess to argue about.
Some answers change the plan's scope. Some change its order, because a workflow the team thought was minor turns out to be the one that cannot be down for a week. And some answers are the most valuable kind: the user does not need the thing the team was about to rebuild at all, and a chunk of the rewrite disappears.
The component library version
This applies with particular force to component libraries, where the users are other engineers. A library rewrite that does not ask the teams using it how they use it will discover, after release, every prop they were relying on and every escape hatch they had quietly built. The engineers are easier to find than customers. There is no excuse for not asking.
A rewrite is a bet that the team understands the system well enough to build it again. I think the bet is far safer after an afternoon of listening to the people who already live in it.
Photo source: https://photos.robertstowe.com/bermuda