Migrating to Nutanix Files

  • 22 September 2020
  • 2 replies


My boss is very interested in migrating our Server 2012 r2 file server to Files. One of the must haves is that we would have to keep our existing DFS namespace. I’m hoping someone can provide some pros, cons, benefits and pitfalls associated with this planned migration. Thanks.   

This topic has been closed for comments

2 replies

Userlevel 3
Badge +6

I would like to mention that the best way to do answer/approach this is to read all the documentation and KBs beforehand and even then to plan on having a consult w Nutanix pre-sales/SRE’s and Support.

We’ve been testing/reviewing Files for a while now so had been familiar with many of it’s (new) features over the years…. your mileage may vary. (What worked for us may not work/be needed for you.)


We did a similar migration about 10 months ago (successfully) of about 50+TB of data stored in over 100+ DFS-N folder targets,  and that many shares from 2 different types of sources (3rd party “NAS” solution and consolidated a few shares on Windows Servers (2012R2+ flavors) onto 2 Nutanix Files clusters.


I would read up on the differences between “Standard” and “Distributed” share concepts and plan out which shares your needs best match up with those two types. For us we ended up using all Standard shares, since I couldn’t guarantee that someone/some app didn’t create a file at the root of a Nutanix Files hosted share… Don’t think that has changed in Files 3.7 - but please double check that.


The DFS-N Namespace question was the least problematic for us:

i.e. assuming you have AD Domain based DFS-N roots it’s a matter of creating a new folder target pointed to the Files share (leave it disabled) but verify it opens up. Robocopy the data/verify numbers match up, then in a maintenance window disable the original share (and deny permissions to any non admins) and switch the DFS-N folder target from online to offline on original share and offline to online on the Files folder target. Test with clients...

If you have a large # of shares the whole process can be done via PowerShell...


We had 0 issues using this method. 


Some other things to consider:


I would also plan and test out your Files DR scenario/recovery options before you go live, not to mention review/buy the disk space on the DR site you’ll need (or 3rd party backup).

Check out these test-drives of Files to get familiar with it:


Do you know what your average daily change rate is? Your snapshots (for DR/Protection Domains) will grow by that size…

Do you know the ‘max’ # of connections you expect? I would plan on sizing the Files cluster accordingly - read the release notes for your desired version to see the RAM/CPU requirements on that. Don’t undersize it… 

We used robocopy to mirror source / destinations - If you plan on using “Previous Versions” in for your simple file level recovery, robocopy, if used with a “/MIR” option will find an extra directory you need to exclude on the Files side:

robocopy “sourcepath” “destinationpath” … /MIR ..... /XD “\\NutanixFiles\Share1\.snapshot”

Great! Thanks for the info David.