You would be pretty much looking forward to an approach to migrate a large file share to SharePoint thanks to the article’s title. Unfortunately, this article is not going to cover that. Migrating a large file share to SharePoint consists of a good process of both business and technical, including information classification, scalable architecture, planning information architecture to data migration. Hence, I’m not going to write so much about that here in this article. As SharePoint is a proven content management platform so there are many reasons to get rid of file share and move things to SharePoint.
Practically many of document management features are documented here: SharePoint 2013 Document Management Features
In reality when I get involved in such a migration, I rarely see the practical use of SharePoint for content management, rather than just a web access functionality, and a few out-of-the-box features such as versioning, permission, metadata or easier office web app integration. That came to me a question: What else do you consider for your migration? I sat down with IT project manager from several government agencies to ask this question. All gave me an interesting answer that they did not want to use SMB protocol due to security compliance. Oh wait, that is a very good reason especially for governmental environment. This does mean that to meet the requirement, what you need to do is give your end user another protocol to access files stored in file share.
And the tricky thought here is you do not have to move all of files in your file share into SQL Server databases. As long as end users do not use UNC path to access file share, you would meet the requirement. I used to engage in many tenders in which they required to migrate very large file share (approximately a range from 5 – 20 TB) within an expected short duration (1-2 months). This sounds crazy! If you do a calculation for a duration to upload 10 TB with a internet speed of 1 Mbps (with 10% overhead) you would have to spend 2,7 years. You would complete the manual migration within 3 months if you use 10 people continuously migrating over 24/7.
Use this link for the calculation: File Download and Upload Time Calculator
In the case of getting rid of SMB protocol, you can programmatically build a connector service to sync metadata and permission to SharePoint, while file binaries are still stored in your file share. From the user experience perspective, end users have access to your file share in SharePoint. They must open SharePoint, enter their credentials, retrieve permission before fully having access to the file they need.
If you are not confident to do so, look into DocAve Connector. This product allows you to attach any supported network, or cloud file share to SharePoint, taking advantage of SharePoint content management and presentation features without any migration. Contact AvePoint representative for more information. Bamboo File Share Library also does the job pretty well.
Talk to your customer and discuss if the duration is a key success, then choose an appropriate and acceptable solution in the migration, especially for large file share. The term “migration” is quite broad, and in my case it’s a migration of access protocol only. If you still cannot drive your customer to that way, chances are you would consider using proven enterprise RBS solution in the market, including DocAve StorageManager and Metalogix StoragePoint.
For SMB protocol related to security compliance, here are helpful references althougt perhaps out of date:
- SMB security flaw in Windows? Not really, says Microsoft
- Redirect to SMB
- New SMB Relay Attack Steals User Credentials Over Internet
- Is the SMB Protocol an Open Door to Network Intruders?
[Updated January 3, 2017 5:15 PM GMT +7] Layer2 File Server Synchronization also supports you to link from large file share to SharePoint or Office 365.