I would construct some kind of a test-script, e.g. using Test::More as its driver, which executes a series of queries with known results.

I don’t think that a simple database-dump would be sufficient unless you have first determined that every table has a primary key and that the dump utility orders items by that key.   (And if it does have a primary key, testing for the behavior of the program in the case of a key-collision is beyond scope.)   Instead, and in any case, I would run a series of queries using ORDER BY and GROUP BY as necessary so that the results of each query are known to be comparable.

My approach as described is basically “forensic testing.”   Or what has sometimes been called “discovery testing.”   Your goal is generally to determine what “the right answer” is, within a set of well-defined test cases chosen by you, and then to determine if both the old and the new code produce an identical outcome.   You can’t do that with “100% coverage,” by the way, and in any case you do need to approach the problem in a way that points fairly directly to targeted sections of the code (in both the old and the new programs) and that does so in a way that points to a diagnosis and/or solution.   This will be an ongoing tool, that the company never had before but that you can expect to be used from now on.   Plan and design accordingly.   (Hence my suggestion of using an existing test-framework as the driver.)

It can certainly be awkward to discover ... and you probably will discover ... that the existing application is wrong in some way that materially affects the existing report outputs that the company has come to rely upon in a business (e.g. auditing) sense, such that producing a different answer is more objectionable.