If you took a copy of the original file, data and all and converted it as described, the data in data fields (as opposed to calculation fields) should be identical. It will be very unlikely that any will be different.
But if you want to do a record by record, field by field comparison, you could export the data from the original file into a text file such as a merge, tab or csv format file. You can then import this data into a copy of your table in the converted copy and then use scripts plus a relationship to do a field by field comparison of the imported data with the converted data to ensure that they are identical.
Note that I stressed this for data fields (text, date, number, container...), not fields of type calculation. When I converted from 5.5 to 10 several years ago, I found that the very calculation expressions were modified during the conversion process where many fields ended up enclosed in "getasnumber" function calls. If a very few cases, I found that I had to remove the added function calls before the fields evaluated correctly. So while this field by field comparison is very unlikely to catch an issue in a data field, it might spot an issue in a calculation field.
Note 2: one change between then and now is how FileMaker indexes text fields. In the older versions, punctuation characters were not included in the indexing while they are included now. Thus, in FileMaker 5, a relationship that matches by text fields would match the text "Name" successfully to the text "Name." or even the more subtle "Name " (note the space after the "e"). But these values will not match in current versions of FileMaker.
Hello Mr. Phil,
Thanks so much.
While I agree that files converted as described "should" be the same, the client will probably want some kind of verification that they are the same.
I think my best bet is to export, compute on exported data, then run the same computation on data from V13 (after converted).
I understand about the calculation fields and the client is already aware that somethings like scripts and layouts may need to be visually / hand validated. I think most of these older databases they have do not actually have computation fields or at least not many.
I like the idea of "performing calculations on the data" as a way to verify them, but...
I seem to recall that there was a bug back in FileMaker 5 that sometimes resulted in incorrect rounding of the data. Saw that in some of my records.
Thus summary and other aggregate statistical values produced in FileMaker 13 might not match the same values produced in FileMaker 5 even though the data is the same.
So if you are going to use that kind of verification, be sure to use the same version of FileMaker to verify both sets of data.