Deduplication and vol move cutover

[nekone]

If you vol move a 100TB volume, the first transfer will have a transfer rate of about 160MB/s, but if you try to manually cut over, the transfer rate will be 1MB/s and won't switch after 5 or 6 hours.
Has anyone had this experience?
This volume is deduplicated and was manually deduplicated before being disabled.
100TB volumes that have never been deduplicated will not experience an incident.

Thank you and best regards.

[jaikumar]

A rough outline volume move is , 
#1 Starts with baseline snapshot transfer between the src volume and dest (a temp) volume 

#2 Then continously it checks for a snap delta between the source and destination volume and copies the delta

#3 And every time #2 is performed , volume move engine check if the snap delta to be copied will complete within the cutover window that is specified when the volume move was started (default is 30s). 
#4 If the snap delta copy can be completed by the cutover window then it will proceed to cutover if not it will go back the copy/replication phase.
----
Factors that define volume move entering volume move cutover
* the cutover window that is mentioned
* rate at which the data in the source volume is changing

Note: doesnt depend much on if the data in the volume is deplicated or not.

-----
Following things can be done
* Check if there are any errors in the volume move  (volume move show -instance)
* Since the IO will be fenced during the volume move cutover , if the host/protocol can tolerate IO responded with re-triable reponse , increase the volume move cutover to an higher limit.

* Throttle the IO on the primary volume by setting a QoS policy and this can be removed after the cutover is completed.

[nekone]

Thank you for your reply.
There was not enough information.
The following is a supplement.

This is a vol move from FAS to AFF. On the AFF side, the deduplication and compression of the aggregate are set to "Auto."
Even in that case, is there any impact of duplication?

and ontap is 9.14.1.