Forum Discussion
Migrating from network drive to SharePoint
stenci To get around the 300000 file limit it's an issue where you have to throw hardware at it. Balance the load across multiple machines using multiple clients.
SharePoint may not be the best place for this. As I said it sounds like this process just using SharePoint as a dumping ground.
I would say that if you're required to use SharePoint - this is incurring a lot of technical debt because of the need to use OneDrive client to sync contents as if they were in a local drive. Re-engineer the process to work for the place where you are storing the files there are plenty of different ways to automate the file upload process. I would also be mindful of how many files that are created that are like versioned by adding something to the end of the file because that could be de-duped by using versioning in SharePoint.
Whatever the outcome may be document what is going on because IMO - this isn't a process or development that I would want to come into having to figure out what is going on with it.
I can organize and split the files in different libraries, sites or groups, but I want to be sure that it will solve the 300,000 file limit.
Do you know if splitting in groups would work?
Because for an end user, sync is simplest to configure at a library level (e.g. a user either syncs or does not sync a given library), it would make sense to split the content into multiple libraries, rather than a single library.
- My understanding is that there if you have more than 2000 sub sites or 2000 libraries in a site collection, you may experience performance issues.
I agree with a lot of responses here. SharePoint isn't a direct replacement for a file share. If you were going to use SharePoint as your document management system for sharing and collaborating directly on documents, I could see it being a potential option if it had a solid information architecture.
However, it does seem like just trying to get rid of a file share and use SharePoint instead. I would recommend against this, and it's not the most cost effective storage.stenci To get around the 300000 file limit it's an issue where you have to throw hardware at it. Balance the load across multiple machines using multiple clients.
SharePoint may not be the best place for this. As I said it sounds like this process just using SharePoint as a dumping ground.
I would say that if you're required to use SharePoint - this is incurring a lot of technical debt because of the need to use OneDrive client to sync contents as if they were in a local drive. Re-engineer the process to work for the place where you are storing the files there are plenty of different ways to automate the file upload process. I would also be mindful of how many files that are created that are like versioned by adding something to the end of the file because that could be de-duped by using versioning in SharePoint.
Whatever the outcome may be document what is going on because IMO - this isn't a process or development that I would want to come into having to figure out what is going on with it.
Hi stenci
Due to large amount of data we may dig into the below problems.
1) Maintenance of Large amount of database
2) Consider long backup time
3) Search / Indexing shall complete with long delay.
4) Search result may inappropriate due to non indexing.
Its always better to categories and maintain required folder hierarchy for your repositories. By dividing docs in to multiple categories, store your document to multiple sites / libraries. In any technology, instead of maintaining large database, its better to divide into multiple chunks. SharePoint fast search have proved better results for regular users.
I'm starting to think that SharePoint is not the right tool for us.
Both the 300,000 file limit and being impossible to force check out are both show stopper for us.
