All of the above are decent methods of doing a hardware migration.
Please keep this in mind, the more you change the more unknown you added to your project, and therefore more risk. Technically speaking Symantec's Support does not provide 'support' and official procedures to do this migration because of all the variables and unknowns. If you need to perform the move and reduce risk, Professional Services should be considered.
The highest probability of success on a migration is to go from like hardware to like hardware, version to same version, and like O/S to like O/S -- including 32bit versus 64bit O/S. The more you change from this, the higher the risk. Although there are more risk involve, it is possible to migrate NBU or parts of NBU such as the catalog, from 1 machine to another, of different O/S versions, types, etc (Professional Services from Symantec can help with this too). It is best to test these scenario on lab machines before performing on a production system on your own.
The minimal risk you need to be aware of is any integrety issues when copying files (or restoring files) from 1 host to another. This is rare, but it can happen. The part you will care the most is obviously your catalog. If you have some advance scripting knowlege you can script a utility to get a recursive md5 sums of all files under your database area on both target and original master server and ensure they are the same. Nearly everything else outside of database/catalog can be rebuild by re-installing NBU in 1 form or another.
As far as copying over the database from 1 machine to another; the basic tool available to you would be the catalog backup and recovery. This works only on same O/S type.
However, if you have access to a SAN, or NAS, it is possible to also copy the files over as well. For example, in windows, if the OS type is exactly the same and the drive letter is to remain the same, you can pretty do this (highlevel), install NBU into the same drive letter and same folder as the original machine. Then disable NBU services from starting, reboot. Next copy the entire VERITAS folder off the original master to the new master. Re-enable the NBU services, and start them up. This has been known to work IF the 2 machines/hardware are 99% binary/registry compatible! This means if your original machine is 32bit windows 2003, your new machine cannot be windows 2008 64bit for this method to work without complications.
1 more thing people fail to do, your hostname/IP for the most part cannot be changed. Usually you can change the IP, but the master's hostname should not be changed.
Do not be tempted to ever spoof the hostname via drivers\etc\hosts file! I've seen customer tried this from NBU 4.5, where it work without issues, then about 5 years later, all sorts of issues occurs.
