question

First of all whenever there is a storage change, there has to be a downtime unless you are using high availability options like Clustering etc. where a fail-over option is available. With Log shipping one cannot achieve zero down time. Not to mention, optimistically, with such huge changes one has to expect some downtime and be ready for the worst case scenarios. Since it does not include system databases, my first feeling is (I hope I am not missing something), it should be an iterative process. One database at a time. It will narrow down the chances of a major disaster and could be a very manageable process. Each database is taken into single user mode, a log backup is taken through LogShipping job (To keep LS chain intact), stop LS job for the DB, take the DB offline, **copy** the DB files to the specific LUNs and then point the re-located DB files against the Database using ALTER DATABASE MODIFY FILE option. I will not move the files in order to have the option available to revert in cases like faulty storage etc.). Bring the database online. I would also DBCC the DB after this process. There could be more efficient ways than this for sure but in all the cases there would be some extra efforts and more work required IMHO. I guess nothing is for free in this world ;)