You have multiple options.  1) ASM: Present the new HVs to all hosts and have ASM move the data for you. Then remove the old LUNs.The downside is, your are not in control and you have to depend on a DBA to do this for you. So if he or she gets it wrong, the blame game will start. Also, if you yank a single LUN from a ASM group, it will destroy the entire group. We had this before and representing the LUN back didn't help it and we had to do a full restore. IMHO, you should only do this if you can't afford the downtime (usually a lame excuse because how would you ever upgrade the database) and you have full confidence in your DBAs.The advantage to this approach is that you get a chance to change volume sizes.  2) OpenReplicator: Sync the data between the old LUNs and the new one with OpenReplicator. OpenReplicator is not free but I have seen EMC offer it for free temporarily for data migrations. You are in control but you need downtime to pull the old and present the new HVs.I think, technically, you can change HV sizes too (go larger only, can't go smaller) but I don't know how ASM would deal with that.  3) dd This is the poor man's approach. Present the new LUNs and dd the data over bit by bit to the new LUNs. I don't know when this would be the best alternative but it is a viable option. Source and target LUNs have to identical in size and the database has to be down while the data is copied.
We have solrais 10 hosts and Oracle 11G with ASM disks. We are planning to migrate ASM disks (physical EMC disks) from one host to another bigger capacity hosts. As ASM disks are allocated as Raw disks (100GB) each, immaterial how much it is used, Is there any way to smoothly migrate this on DMX-4 any best practice, or tips, or procedure?
Oracle ASM disks on DMX-4 migration question