Transferring data from one system to another is not just about copying files. Fields, codes, and relationships can have different meanings. A completed import can therefore leave behind errors that only emerge when people resume work.
I propose to describe what information they have to pass and how they will be compared. Counts, totals and checks on representative cases help to recognise differences. An equal number of records does not prove that each content has been transferred correctly.
A hypothetical example is a product archive in which the new system interprets variants differently. The description of the model can remain visible, while the bond with size and color changes. Verification should then follow a real activity, such as preparing an order with that information.
The transition also requires a plan for the transition period: who can edit the data, when the copy is taken, and how subsequent tasks are handled. I propose to preserve a recovery path and the evidence of the controls, with competent support. The migration is ended when the data allows the expected work to be done, along with the training needed to properly use the new system.