Thanks Chad.
So would it make sense to run migration and backup from disk to copy pool simultaneously? Disk pools are on SAN
No, you don't want to do that.
I have seen issues where the backup stgpool is trying to process a file at the same time as migration. If the backup stgpool finishes it first - all good. If not, (assuming that caching is turned off on the disk storage pool; there are issues that mean that I tend to keep it off unless there's a really good reason to turn it on) the backup stgpool can't finish, has to backtrack, and start a different file (rewinding the file, if I remember rightly.)
At least, that's my opinion, based upon extremely slow progress of the backup stgpool while the migration chugs along quite happily. I could be wrong; there isn't quite enough information in TSM to determine which files are being duplicated/migrated by a given process.
I prefer to let the backup stgpool run, then start migration once it's finished. There's also the question of performance; I'd rather have one process doing a sequential read and write, then another doing the same, than have two processes contending for the same source data/disks.
Simultaneous migration and copy pool duplication was introduced in 6.2 (look at the AUTOCOPY parameter, set on the storage pool), but you're running 5.5.4, which makes that a moot point. A useful feature - and long overdue - but I'm still of the opinion that you're better off sticking with 5.5, unless you have a compelling reason to upgrade (large database, log regularly filling, deduplication) - too many maintenance releases and patches pulled, although it's getting significantly better.