I think that there is no developer in the world who never had to face this situation: there was an older version of “something” – the app, the program, the interface, the function. And now you need to create a new version (most often – because you are migrating to the new system), and you need to make sure this new version of “something” produces the same result.
First of all, this never happens. I’ve never experienced the situation, when the new procedure would produce “exactly the same result”. There are always mismatches. And second, when you start to validate them in more details, turns out, that the “new” one is better, than the “old” one, in a sense that most of the time it would turn out, that the new code fixed some issues of the old code :).
Moreover, quite often we already know, that the old code is wrong. But for some reason we are still trying “first to make in work, like then old one, and then fix it”.
I think in most cases it’s pure “phycological”. We think that the fact that the old code was running for a while and nobody complained, sort of validates it. But quite often the end users actually know about the errors, and they learned to correct then in the after-processing (at one of my consulting assignments I’ve learned that the error in the client financial software was know about for almost … 30 years!!!). Or people might not care. Or have no ways to validate correctness.
In any case, if we already know for sure that some parts are wrong, an we want to rewrite them anyway, I do not see a reason to “first replicate what it was”. It’s might be as easier (and better!) to gather new requirements, as if it was just another new development, and to validate results against these requirements, not the old version!