Once you’ve migrated your DFS infrastructure from Server 2003 to Server 2012 R2, there are some housekeeping issues to which you should attend.
In the best of all worlds, before you performed your DFS migration, you rationalized your DFS infrastructure. This would mean that before you performed the migration, you removed replicas and namespaces that were no longer utilized prior to the migration. A “prune first, migrate second” approach.
With the inevitable pressure to migrate before the end of support deadline arrives, many organizations will instead take the approach of “migrate first, prune later”.
One of the truths about files stored in file shares is that their access pattern almost inevitably follows a curve. Files most likely to be accessed immediately after they are created. As time passes, the file is accessed less frequently. At some point the file will never be accessed again. One of the terms used to describe a file that won’t be accessed again is “cold data”.
You should do your best to ensure that you’ve got a system for regularly removing cold data from your organization’s DFS replicas. This is because just as new files are always being created, older files are reaching the point where nobody needs access to them anymore. This doesn’t mean you can just delete them – there are likely to be compliance implications that dictate how long you need to keep the files. However no one states that you need to keep them replicating throughout your organization’s DFS deployment.
File Server Resource Manager includes a tool that allows you to identify cold data. There are also many other third party tools that you can use to perform this task. However, just be aware that if you wait until after you perform your migration, every file may get “touched” so that it looks like it was recently accessed. You might have to wait some time to determine which files still need to be part of the DFS milieu and which can be safely warehoused because they are unlikely to be accessed again.