Hi
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
Gidi
