When migrating between storage systems, I've found the easiest approach is to consider your migration options from closest to the application, down to the bottom of the stack - storage.
For example, I'll usually take this approach at a high level when planning:
VMWare - Use Storage VMotion to move VMs to new storage
Exchange - Use DAG replication to add in new constituents on new storage and then evacuate old ones
iSCSI or FC attached LUNs - Volume manager replication and physical volume replacement (LVM, VxVM, Windows Dynamic Disk replication)
CIFS or NFS shares - We have a tool called XCPthat can do very fast copies, enabling a quick cut-over
iSCSI or FC attached LUNs - Where no volume manager is available or where considerations dictate, we can performForeign LUN Import (FLI)to bring LUNs into the system, or we have professional services option for low outage cutovers using a rentedDTA2800appliance
However, since you're already on a NetApp system, if it's already on Clustered ONTAP, there is the option of upgrading the source system to the same version of ONTAP as the new system, joining the new system to the cluster, and just doing vol moves behind the scenes, and then LIF moves, and then remove the old nodes from the cluster. If it isn't already Clustered ONTAP (ie, it's 7-mode), we have the 7-Mode Transition Tool (7MTT), which can do structured moves of data across using snapmirror.
Hope this helps! Please feel free to post any followup questions.
THank you for the excellent response. Many of these options I hadn't considered but will look into. We are currently on Data Ontap 8.3.1 on the Clustered Source SAN; so using Storage Vmotion and Volume moves is a good thing to look at.
Hi Alex, Do you have any documentation for the suggested solution below?
However, since you're already on a NetApp system, if it's already on Clustered ONTAP, there is the option of upgrading the source system to the same version of ONTAP as the new system, joining the new system to the cluster, and just doing vol moves behind the scenes, and then LIF moves, and then remove the old nodes from the cluster.
Long story...but in the end it was decided to move from Fiber Channel (on our current FAS3220) network, with several file, sql and vmware hosts attached to 10GigE for our new A300 AFF with NEW SQL clusters, File servers and NEW ESX Hosts. We bought an Aruba 5400zl 10GigE switch and I'm having a very difficult time figuring out how I'm going to connect the two disparate storage network together to allow us to migrate LUNs and datastores to the new 10GigE network.
They mention earlier that it's running 8.3.1, so cDOT. A300 min OS is 9.1, FAS3220 max OS is 9.1. So there is the option of upgrading the FAS3220 to 9.1P9 or later, and then joining the A300 to that cluster. However, we strongly don't recommend presenting a LUN via both iSCSI and FC.. so given the desire to change architecture, I'd be inclined to do it as data migration
For vmware, it's easy - storage vmotion onto the new AFF. For hosts serving file data, if you are ok with moving to CIFS, you can use XCP or robocopy to do a migrate into a CIFS SVM. For SQL hosts, I'd look at application level migration options, such as adding in a MSCS host that uses the new NetApp.