Testing the application program per program is dramatically inefficient, up to a point where it can put the economic justification of the whole project in jeopardy.
By taking advantage of the automated nature of this transformation technology, one can improve the accuracy of testing while reducing its cost by orders of magnitude.
As a result of the migration process, a prioritized list of programs is produced. This list is divided in slices of increasing size, and sorted by decreasing complexity order, understanding of course that complexity here refers to the transformational complexity as opposed to functional complexity, which may very well not be correlated.
The first, top most slice, overs most of the complexity of the restructuring facility. By testing these as extensively as possible, one leverages on the fact that the transformations tested here are used throughout the portfolio under consideration. Since this first slice is limited in size (5 to 12 programs, typically), it can be tested very thoroughly, using any testing technique available today (white box, peer review, etc.).
After that this initial slice has been tested successfully, the next slice, significantly bigger (50 to 100 programs) can be tested in a simpler setting than for the first slice (Peer review may be dropped, for instance).
The third slice (500 to 1000 programs) can then be tested with shallow testing only, as the most complicated transformations and combinations have already been tested extensively.
After that, one can move chunks of 5000 programs to integration testing and production in a matter of days.