What I said to do is:

We have the same steps, just in a different sequence and worded differently.

You suggest starting with analyzing what you already have. I suggest starting with an analysis of what is needed. The reason I start there is it avoids prejudicing the analysis of needs by assuming that either what you already have "must exist for a reason", or "would be good to hang on to because that will save time". When modeling the needs of the business, you should start with no prejudices based on existing systems, unless you know that existing systems are properly modeled for some subset of what you are modeling the new system to be. This avoids, "What we need is X, but what we have is W, so let's keep what we have and try to kludge it into some Frankensteinian thing that might more closely resemble X."

You suggest gathering new requirements second. My version, you've already done that. Different sequence, same step. Mine has the advantage of being a "fresh look", yours has the advantage of not having to re-analyze things that have previously been correctly modeled and have not changed since that was done. Mine has the disadvantage of having to re-model everything, even things that might already be correctly modeled. Yours has the disadvantage of assuming that prior modeling was correct and that nothing it modeled has changed. If you avoid that flaw in your version, you just did the work twice, in both steps 1 and 2, while mine does the work once.

Your step three is an implicit part of my final step, of working out how to get old data from old sources into the new database. Same step, different words.

Your step four is also part of my final step. Same step, different words.

Yours doesn't have any actual doingness steps, like moving the data (it just has analyzing it), while mine does have that, but it's implied in yours that the purpose of the analysis is to do thing. Same actions, different implicit/explict on the wording.

So, the only material difference is that I suggest figuring out what you need first, and what you have second, and you suggest the inverse sequence on the exact same things.

The only possible advantages/disadvantages of either is that mine assumes less inheritence from existing systems is needed, while yours assumes more will be a good thing. In my experience, different situations require different assumptions on that point. I tend to work from "what do we actually need, regardless of what we have" and then try to integrate existing resources into it, because that helps clarify the actual needs without prejudice. I've found that more useful more often. But it doesn't make it "right" and yours "wrong", so long as anyone using either system understands why it's done the way it is and the pros/cons of each.