In our organisation, we are using file server and SharePoint. Now, we want to migrate all data from file server to SharePoint 2013. It is almost 500 gb and our concern is if we migrate to SP then what will be the performance of SP or what is the best to do? thanks
Assuming your 500 GB of file share data consists of mainly Office documents, you would soon realize that SharePoint stores documents differently. The initial overhead of telling the system that this is office documents is stored only once and not one per document. On average, 500 GB of Office documents, will give you only 250 GB of SharePoint database for the same documents.
250 GB of data will be best stored in two different content databases on the same web application. The big part is categorizing where everything goes. Do you use multiple document libraries or filter out content with metadata? To deal with this you'd need to make a solid Information Architecture of which documents are organizational, part of a process, project documentation, news letters, offers, supplier data, agreements and so one.
When you have that in place, it will be pretty obvious where to store everything in your current intranet of a new space.
500GB isn't too much content for SharePoint, however you should carefully consider your information architecture before migrating content into SharePoint, and look specifically at
- How many site collections you'll need. Check the recommended maximum database sizes for the version of SharePoint you're looking at (e.g. for SharePoint 2013 look at https://technet.microsoft.com
- What content types you're going to need. Importing all data into SharePoint without assigning appropriate content types first just moves the mess of data from one location to another.
- What your security requirements are. Ensure that appropriate security is configured before migrating content into SharePoint.
Keeping database sizes small helps both with farm performance, as well as backup and DR scenarios.
We've seen a variety of approaches to migrating content from file shares to SharePoint, including:
- Lift and shift. In this scenario, all content is migrated into SharePoint (usually by IT). This can be useful if all data in the file shares is useful. If not, then some information that you don't want tends to get migrated. structure manipulations can be performed during the migration process. It's also worth having a housecleaning exercise performed on the data by the data owners (if possible) before migration.
- File shares read-only. In this scenario, the file shares are made read-only so that users can access files from the shares, but anything that is useful/is modified/is created is saved into SharePoint. This has the advantage that only regularly used content is migrated into SharePoint. After time (say 6 months), the useful information has been migrated and the file shares can be archived/disabled.
- General access. In this scenario, the file shares are left as-is and users are asked to migrate content to SharePoint. This tends not to work too well, as users who are resistant to migrating to SharePoint will continue to use the files shares while other users dive into SharePoint and information sharing within the organisation tends to become difficult.
We've seen the best levels of success with the middle (file shares read-only) option for migration.
In case you are looking for a tool for this migration scenario I would suggest DMS-Shuttle for SharePoint. It can move folder structures from file system to SharePoint on-premises or SharePoint Online. Additionaly you can use filters and various bulk operations. There is a 15 day trial version: http://dms-shuttle.com/downloads/. Disclaimer: I'm working for the company.