Depends. There are many types of migration.
In many cases, you will be migrating from one fully functional application to another fully functional application. Since the new application is a fully functional application, the functional requirements are completely known-- after all, somebody built the thing.
The migration effort is primarily around converting the database structures to suit the new application. The goal is a big bang event where the old application is retired and all users are directed to the new application.
In this case, it would be pretty hard to stuff it into an agile or iterative approach. There is only one release. The data have to be converted all at one time, during the go-live window.
So while you may have several dry runs, each of which will produce fallout reports (data that could not be converted), in the end there is no functioning software until the very end. This is counter to the agile idea that you are making small changes in a manner where each release is a functional product with a subset of functionality.
In other cases, you might have two applications running in parallel, and may convert modules one at a time. For example, if you are converting from Clearquest and Subversion to TFS, you might migrate your code in one go, then migrate your defects, then migrate your tasks. You might first work out a federated identity system to allow a user to seamlessly switch between applications, then configure the menu system to point them at different software depending on what has been converted at the current point in time. Arguably this could be approached in an Agile manner.
In yet other cases, you are not really migrating but re-implementing. For example, if you are migrating from a customized application to another application that you just purchased, and a gap analysis has shown you will need to customize the new application too. In this case the project could be Agile, because you are re-implementing features as you go.
I wouldn't say that the statement was fallacious without knowing more about what the project is. At a bank, if they are migrating their core host, it would most certainly be a big bang event, because of the data integrity requirements-- a bank account can't have two master ledgers or else you will run into serious accounting problems. But if they are keeping their host but switching out a couple customer-facing web sites, it could conceivably be done in stages. Then again, it is quite likely that any one of those stages would be much too large to fit into what is typically thought of as an iteration.