I have something that hard to understand. You said that enable snaplock after the migration,but as far as I know, snaplock needs to enable at the aggregation level in advance. All existing systems are running in worm state. Netapp to netapp does not have any problems. However, centera, which uses api to store data, differs from us in that way, So I wonder if retention is not a problem after a regular migration(like using XCP) when migrate from Centera to Snaplock volume on FAS C-mode. And if I need a special way to migrate data while maintaining worm state from Centera to netapp.
The aggregate need to be enabled for snaplock. but it's not where the polices are being hold. For tests and first copy you can set on each volume a maximum number of min for retention as a very low figure. and then when the copy confirmed to be successful, change it to higher and run on the last access dates to up them. or apply a Event-Based-Retention to enforce WORM.
The attribute that controls the snaplock (last access as a release date) is as much as i know proprietary and not as part of a standard that is common with other vendors.
so carrying the date or polices over is not a straightforward task. if you don't want to invest in scripting it. you can maybe just apply a applicable high enough minimum lock or a Event-Based-Retention that will be enforced on any of the files you copying to it.
There's a whole chapter in https://www.netapp.com/us/media/tr-4526.pdf about "Transition from 7-Mode to ONTAP 9". they listing a few methods and software pieces for copy in the "Copy-Based Migration" section. note that they avoiding the set of the expiring date there as they expect it to already be set correctly on the 7-mode system. but it seems they also avoiding the actual enabling of the WORM, as unless you enable auto-append mode the copy itself will not activate WORM, you have to change the files from the current state - to writable (if not already) - and to read only again to activate WORM. i'm not sure why this is not addressed in that migration chapter - as i don't expect all the software's they listed there to do it themselves.
Note that they don't mention XCP there for some reason, but as you mentioned it - i think XCP can also be used for the reporting stage they included in the migration chapter. as XCP can do pretty robust signature file compare.
CC: @arpan in case he wish to add anything or take the feedback