Hi @drPhil 

Happy New Year! Not a bad way to welcome the new year either, with a project to replace to new storage ;)

There are many ways to do this, so i’ll go from order of easiest (preferred) to most dificult:

1. Move Mount Path:
   https://documentation.commvault.com/11.24/expert/9302_moving_mount_path.html
   This option uses a workflow to copy data from the existing MP’s to the new storage (you’ll want to slice the storage up to match the existing). Once the copy is complete, it then updates the GUI to reflect the new location and everything continues without any other changes. (Note: if the storage is shared between multiple media agents, the sharing paths are not updated and this is a manual update as the workflow only updates the primary Media Agent) The downside here, is that for a portion of the copy process, the MP must be taken offline to ensure no new data is being written to it or data aged from it, AFTER the copy is started.
    
2. Create New Libraries and Associate with existing DDB. Seal and continue.
   This method you create the new library within Commvault. It lets you slice up the storage and present it to the Media Agent however you like with how ever many Mount Paths/Luns you like.
   Once created, you share the library with the existing DDB and immiediately seal the DDB.
   This ensures the sealed DDB and jobs are associated to the old library and new jobs the new DDB.
   This requires no changes to storage policies. The old library hangs around until the jobs associated with are aged out and at this point you can clean up the GUI and remove the old library. (Note: the downside here is the retention. If data is kept for 12months, cleanup must wait 12 months, not an issue if the storage is destined to retirement, but if you’re planning to repurpose it than becomes an issue).
    
3. Auxiliary Copy all data to new library.
   This option takes care of the downside from option 2, since we don’t need to worry about the retention. However is the most resource intensive, as you’ll have to create new Library, DDB and Copies for each storage policy.
   Once created, you than need to PICK every job and ensure they copy successfully. The risk for data is almost always down to human error, so ensuring all jobs are picked is critical.
   The upside though, you’ve got all your data migrated to new storage and DDBs and there is no ‘downtime’ so you can immiediate decom the old storage once the new storage is setup and move on.
    
4. This option is not actually recommended, however depending on the storage, some vendors will include a ‘replication’ or ‘migration’ tool, which migrates data at the block level, essentially making a identical replica.
   If you’re new storage and old storage are the same vendor, and they offer something like this, than you can simply migrate data, update the GUI to reflect the ‘new’ location (provided it changes) and than do nothing else.
   Actually, you might consider running a Data Verfication to atleast have peace of mind.

Let me know if you want any extra info or detail.

Cheers,
Jase

Hi all and happy new year !

In my case I would select the option 3, for the reasons detailed by @jgeorges . I already performed this operation a few times and it worked fine. 

Auxcopy everything from old array to new, then maybe promote that copy as new primary, and you can later dismiss the old array as everything had been copied.

Let us know your comments on thaT.

Hi @jgeorges and @Laurent ! Big big thanks for sharing your experience and knowledge, that’s help a lot.

Recently, the deployment of the new storage array has been finished. As described and suggested we have opted for the third option - Auxiliary Copy all data to new library. Everything went smoth and without serious issues.

Once again, thanks community for the support!