UPDATE 6/9/18 NetApp updated the KB:
https://kb.netapp.com/app/answers/answer_view/a_id/1029919
https://kb.netapp.com/Advice_and_Troubleshooting/Data_Protection_and_Security/SnapMirror/How_to_migrate_a_SnapMirror_XDP_destination_volume_to_a_diffe... - updated link OCT 2020.
The KB now support the mechanism that is described here with MirrorAllSnapshots, confirm you can also migrate the sources, and added another workaround to re-enable the deprecated DP.
Hi
i had a free evening so i tried to do something similar to this KB but using XDP with MirrorAllSnapshots instead of DP as the KB suggest.
and i have a good news IT WORKED 
. is it supported? does it have limitation? would it break on version difference? i have no idea - and suggest you to try it on your system before moving the workload and perhaps have NetApp verifying it as supported.
i will send a link to this post as comment to the KB. and as DP going to be deprecated in the next release. this seems to be a good replacement.
Attaching the output. i did it all on a single 9.1P6 cluster and a single SVM with two nodes (node1 as the source for the old and new SV's and Node2 as the Destination for the old and new SV's).
All the objects are technically independent.. so yes - in your environment each volume would be on dedicated cluster. and i assume different versions (i only have one cluster to test on)
in short: (you can also find these comments in the attachment):
#Creating the "existing scenario", SRC and DST volumes, a file in the SRC volume and few snapshots that are snapvaulted across
#Creating the Volumes on the "new" SV's SRC and DST clusters, And mirror in each "site" from it's old to new cluster using MirrorAllSnapshots and XDP(not DP as in the KB)
#Once users ready to move to the new clusters - release/break all 3 relationships to make the new source writable (you can start only with that one if you wish)
#Take the old clusters volumes offline to make sure no one writes to them
#Create and resync the actual SV relationship (yes, without running baseline on the WAN)
#Verify that all the snaps exists and the test file is intact
Good luck
Gidi
UPDATE 6/9/18 NetApp updated the KB:
https://kb.netapp.com/app/answers/answer_view/a_id/1029919
https://kb.netapp.com/Advice_and_Troubleshooting/Data_Protection_and_Security/SnapMirror/How_to_migrate_a_SnapMirror_XDP_destination_volume_to_a_diffe... - updated link OCT 2020.
The KB now support the mechanism that is described here with MirrorAllSnapshots, confirm you can also migrate the sources, and added another workaround to re-enable the deprecated DP.
Hi
i had a free evening so i tried to do something similar to this KB but using XDP with MirrorAllSnapshots instead of DP as the KB suggest.
and i have a good news IT WORKED . is it supported? does it have limitation? would it break on version difference? i have no idea - and suggest you to try it on your system before moving the workload and perhaps have NetApp verifying it as supported.
i will send a link to this post as comment to the KB. and as DP going to be deprecated in the next release. this seems to be a good replacement.
Attaching the output. i did it all on a single 9.1P6 cluster and a single SVM with two nodes (node1 as the source for the old and new SV's and Node2 as the Destination for the old and new SV's).
All the objects are technically independent.. so yes - in your environment each volume would be on dedicated cluster. and i assume different versions (i only have one cluster to test on)
in short: (you can also find these comments in the attachment):
#Creating the "existing scenario", SRC and DST volumes, a file in the SRC volume and few snapshots that are snapvaulted across
#Creating the Volumes on the "new" SV's SRC and DST clusters, And mirror in each "site" from it's old to new cluster using MirrorAllSnapshots and XDP(not DP as in the KB)
#Once users ready to move to the new clusters - release/break all 3 relationships to make the new source writable (you can start only with that one if you wish)
#Take the old clusters volumes offline to make sure no one writes to them
#Create and resync the actual SV relationship (yes, without running baseline on the WAN)
#Verify that all the snaps exists and the test file is intact
Good luck
Gidi
