No more migrations from 7 mode after 9.5

[schaeferm]

I am wondering what the plan is to help people holding on to 7 mode migrate to a platform that only supports 9.6 like the the A320.  I can believe you are cutting people off before the end of support of 7mode, which is I think 8/2020?   Am I missing something?

[JGPSHNTAP]

This is interesting because A320 doesn't technically support 9.5 or lower, which I find kind of crazy.  

I would normally say downgrade to 9.5 and TDP over.  

[schaeferm]

exactly, my point is you cannot go to 9.5 so you cannot migrate if you needed to.

[TMACMD]

If data = LUN (or vmware datastore), then try to use Host (like storage vMotion with vmware)

If data = generic NFS, then use XCP-NFS

if data = generic CIFS, then use XCP-CIFS

Or, get a staging unit that can run 9.5, TDP to the staging unit, Join the A320s to the cluster (there is an option to allow). 

Vol move the data to the A320, unjoin the staging gear.

just thinking outload fellas!

[AlexDawson]

---

@JGPSHNTAP wrote:

This is interesting because A320 doesn't technically support 9.5 or lower, which I find kind of crazy.  

I would normally say downgrade to 9.5 and TDP over.  

---

The AFF A320 requires support for NVMe shelves, which is not present in 9.5 and not a minor consideration to add in. As TMAC says, TDP is just one option.

Granted, convenient, but there are plenty of other ways to get data transferred between systems.

xcp, cloud sync are just the starting point. Doubletake, platespin, storage vmotion, robocopy, LVM mirroring, etc. 

If this is a deciding factor, make sure your NetApp account team knows. If you are working through a partner, ask them to put you in touch with the NetApp team covering your region to give them this feedback.

[paul_stejskal]

Alex, TDP isn't supported past 9.5.

XCP is a new tool that can help with migrating data and can help migrate. It's designed to be like rsync but faster. I would definitely bring up these concerns with your account team.

[JGPSHNTAP]

Sorry @paul_stejskal  - That's a terrible answer

All the answers above are terrible in my mind.  You take away the core functionality of snapmirror which there is no better migration tool out there to move data.  Bad move on Netapp's part

Netapp 7-mode is still supported, so by taking away TDP, this was a very bad move.  Just sayin'

[paul_stejskal]

JGPSHNTAP, I feel your pain good sir. As Alex said however, the best way to provide that feedback is your account team.

[AlexDawson]

I get that 🙂 I mention TDP as one option to point out that it going away isn't the end of the world. 

As summary - We still have options for TDP if it is absolutely a requirement due to audit or other corporate process requirements, and your NetApp account team can help you out with them, but otherwise there are plenty of alternatives in many cases.

[TMADOCTHOMAS]

Just want to chime in that I think cutting off 7MTT is a mistake. We plan on upgrading from 9.3 to 9.4 and then 9.5 in the 1st quarter of 2020, but we will stay there purely because of the 7MTT issue until we get rid of our last four 2220 7-mode systems. Admittedly we hope to do that in the first half of the year, and I hope it happens, but I hate being restricted to which OnTAP version I can run in the meantime. I hope NetApp will reconsider.

[SeanHatfield]

Losing TDP, which takes 7MTT with it, is extremely inconvenient.  Front end file copy options like XCP and all the 3rd party migration tools are there, like they always have been, but what I liked about TDP was that it brought over the entire volume and its snapshots.  And because it operated at the volume level you could generally avoid having to do binary level comparisons and evidence gathering during the cutover window.  Either the whole volume came over or it didn't. 

7MTT went above and beyond by not just orchestrating the TDP jobs, updates, and cutovers, but it could also translate and apply the configuration from a 7mode system to an ONTAP SVM.  It was a really nice tool, but it was just one tool in the 7mode transition arsenal.  Many times we couldn't operate at the volume level, because qtree snapmirror relationships didn't align with volume snapmirror relationships, or some other sub-volume data restrcturing had to occur.

So what's left:

Front end file copy tools: XCP NFS, XCP CIFS, cloud sync, and 3rd party data migration products.

Foreign Lun Import (For LUN data if the source system has FC)

Swing gear: TDP to a 9.5 capable system, then either snapmirror, SVM-DR, or cascade the TDP target volumes to their final destination.

Hint: ONTAP Select supports 9.5.  

For the internal folks, the TDP Cascade kb is here:

https://kb.netapp.com/app/answers/answer_view/a_id/1087570

[TMADOCTHOMAS]

Thanks @SeanHatfield . I agree with the OP and would just say the idea of switching to a different method of transitioning data from 7-mode after four years of successfully using 7MTT, tons of experience ... makes absolutely no sense. In all honesty, we simply won't do it. We will stay on 9.5 until we are off of our final 7-mode systems, even if that's over a year from now. If we need to buy a new system, we will only buy systems we can downgrade to 9.5 if they are for the four offices we need to transition.

[TMADOCTHOMAS]

In case anyone searches this topic, support for TDP and the 7MTT was added back to 9.6 and 9.7:

https://kb.netapp.com/Advice_and_Troubleshooting/Data_Protection_and_Security/SnapMirror/Initialize_or_update_of_a_Transition_Data_Protection_(TDP)_Sn...