topic Migration from Centera to FAS in ONTAP Discussions

Migration from Centera to FAS

Sungwoo — Wed, 04 Jun 2025 13:43:03 GMT

My customer has been operating Netapp FAS with snaplock and EMC centera for a long time. ( almost 10 years and over 400TB)

This time they are going to change all to NetApp FAS.

The existing FAS systems are all 7-mode. they are OK.

But how to migrate centera to c-mode.

If you have a document about it or have experience, please share it.

Re: Migration from Centera to FAS

GidonMarcus — Tue, 15 May 2018 11:06:02 GMT

am i missing something. what the snaplock has to do with the migration ? is there a WORM on the originating system with polices that need to be retained?

the only recommendation i have is to only enable snaplock after the migration confirmed to be successful. otherwise - it might not be pretty.

Re: Migration from Centera to FAS

Sungwoo — Wed, 16 May 2018 02:15:32 GMT

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.

Re: Migration from Centera to FAS

GidonMarcus — Wed, 16 May 2018 18:12:58 GMT

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