We’ll soon be migrating to O365 and from SharePoint 2010 to SharePoint Online. We have a large number of network drives used by the various teams in our local authority which we planned on migrating into SharePoint. We sought advice from a SharePoint consultant who suggested migrating the drives may not be the best solution and to keep them as drives, moving only our corporate and collaboration docs into SP.
I wondered if anyone else has been through the same process and what they decided upon?
It sounds as though you are in the same situation as us. It’s likely that we will only migrate our core (shared) documents over to O365, although we will also be creating team sites within SharePoint where business functions can store their own content. In future we want to close down our shared drives and direct everyone to saving content to SharePoint within specific team sites.
Happy to chat through this further with you if you like, feel free to email me
adam.hussey@… Thanks Adam
i would be mindful when migrating shared drives, is there potential of duplicated information and useless content poluting SP365?
If you are seeking a single source of truth for business critical info and line of business records then suggest avoiding SD migration. If however you are creating a centralised version of what already exists then it’s probably not such a big issue, but suggest you show users how to migrate and ask them to only save important information to reduce rubbish content
Best if luck !
Decipha (a business of Australia Post)
I’d typically advise clients to not wholesale migrate network drives to SharePoint. The key considerations are retention — you should be deleting unnecessary files and findability. Even as impressive as SharePoint’s search engine is, the more content that you put in the corpus the less likely it becomes that the search engine will be able to correctly anticipate the users real query to respond with the most relevant content.
One hybrid we’ve done is to migrate everything, make it read only, set an expiration date, and start the clock ticking for folks to remove it from the temporary migration location. I don’t recommend this approach generally but in the case we used it the server hardware was failing so we needed a temporary stop-gap
. Good luck.
Thor Projects LLC
From a theoretical best practice perspective, I agree with the commentators on this thread. If you have the money and time available to clean up your shared drives before migrating to O365 (or any pay-for-consumption repository), then it’s certainly best to do that. Many proven tools exist that can help with the process, accompanied by experienced consultants who can run the process on your behalf.
The real world doesn’t always afford such luxuries, however. Sometimes there are executive mandates that force you to get it done faster than you’d prefer.
In those cases, as one commentator noted above, you can press the online repository into service immediately and clean up after the fact by applying active policy to the contents.
Let’s say for the sake of discussion that in your current state your users have personal content both on their “P:” drives on network shares and in the local ‘Documents’ library on their C: drives. Workgroup content is stored on “S:” drives. Approved and published official record content is kept in an on-premises legacy ECM somewhere.
The “git ‘r done and clean up later” approach I’ve used successfully to effect the cloud transition as quickly as possible is as follows:
. Move the P: drive and C: drive contents to each user’s personal cloud repository (OneDrive for Business in the O365 case).
. Retain synchronized ‘virtual’ copies of all content locally, to be retrieved dynamically if required. (To the user, it should appear as if nothing has really changed).
. Move the contents of the “S:” drive to the team’s Group or Team site online (again, using O365 terms). Use manual processes, GPO or scripting to put synchronized virtual copies of this content on each group member’s local file system.
. Apply a global retention policy of “retain N months from date of last modification” to all of the content you’ve just moved online (being sure to retain the date of last modification from the source across the move, so old stuff expires immediately). When the policy causes items to become eligible for disposition, send a notice to the item owner informing them that they need to either update the item (indicating that it’s still work in process) or go through the publishing process to promote it to a location that is managed for longer-term retention. If no action is taken following a couple of reminders, disposition the expired items.
Implementing the above approach can be challenging using only out of the box capabilities. Tools like ours can make it much easier.
Since most of the ROT items will likely be kept in the user’s personal repository, their existence will not clutter up everyone else’s Search results (due to security trimming). Over time, as the policy causes the ROT to gradually disappear (and prevents further ROT from accumulating), Search results will improve. From day one, properly implemented Search will also facilitate active ROT identification and elimination, independently of lifecycle policy. As users come to rely on Search, they’ll find ROT to be annoying, and they’ll eliminate it naturally.
One commentator has suggested that on-premises storage used for fileshare content is less expensive than cloud storage. I’ve never found that to be true, at least not when the cost of on-premises managed storage is fully accounted for. Cloud storage is ALWAYS far less expensive than on-premises storage, so there are good economic and security-driven motivations to migrate sooner rather than later.
If you want to migrate the contents of those legacy ECM repositories to the cloud without losing any policy, history, or audit details in the process, that’s ossible too, but not the subject of this thread.
In the short term, I would agree with your consultant. Most share drives are little more than dumping grounds full of ROT. Compared to the cost of SharePoint, just leaving the dead wood languish in cheap share drives may be a good idea. That said, establish governance and work on IA for the stuff going in SharePoint. Get top down support to wean people off share drives going forward, let the individual teams move and organize what they think is important, and via retention policy start deleting what remains in those drives.
We don’t have SharePoint but a number of network drives. Prior to initiating our O365 migration, we moved those drives to our AWS cloud. It’s been transparent to the organization. It also allowed us to separate the efforts and reduce the risk. 🙂
I agree with previous comments. I am currently managing a similar project for a client, and advising them about the same points. I have managed many such project, and this is one of the questions that comes up many times — and as usual, it depends on the goals, objectives, and scope of the project. Please let me know if you would like to chat offline.
I advise clients to only migrate content from shares that is known to be authoritative (meaning single, correct instance and version) records and use a “trickle feed” (bringing in other content on an as and where needed basis). This approach follows some well established standards.
That said, I highly recommend considering a hybrid architecture versus a cloud-only (SharePoint Online – SPO) approach, and pointing the SharePoint search index at the shares so that content remaining in the shares can be more readily found and then the trickle feed approach works. Saves a bunch of time validating that large volumes of content migrated correctly, and, as other have pointed out, also reduces the likelihood of migrating a bunch of ROT.
You also might want to consider some of the content analytics solutions designed to help with categorization, meta data harvesting and de-duplication/versioning. One of the strengths of going to SPO is that you lessen the risk of having important documents stored on individual devices and ‘home’ directories. Moving these documents to OneDrive provides a level of security and also facilitates collaboration because you no longer have to email/move documents to collaborate – they can stay on your OneDrive and subsequently moving them to a SharePoint site is just a logical change in location.
EXCELLUS HEALTH PLANS
I have worked with a number of companies trying to get rid of shared drives. There are some additional things to think of not particularly mentioned here. If your network drives are ONLY used for collaborating on office type content, these won’t be as much of an issue.
Back in SharePoint 2007, there were 84 file extensions that were blocked from being loaded into Sharepoint. In 2013, that list was 104 file extensions. The reasoning for that list was somewhat convoluted but primarily it was used to prevent malware from making its way into a SP site – but there were other functional and performance based things as well. What I learned from that list and from helping people try to get their content into it was that people do multiple things on network drives:
-Accidentally capture malware
-Store and share personal pictures, music, and multimedia
-Develop and use small databases (access, for example)
-Create and develop software Download and store software
-Create archives (like zip files) – some of which can get extremely large
-Backup emails Backup databases
-And any number of other weird things.
Typically, this content will comprise about 50% of your network storage; and none of this should go into a SharePoint site or into an O365 cloud. Not all of it is ROT or eTrash. Some of it is really quite healthy – and you should continue to provide an on-prem place for these things to happen.
I’d recommend an analysis of your files (Gartner has a list of file analysis tools that do well) and think about content holisticall
While I do agree with most of what has already been said, I am proponent of cleaning up your files before migrating them to either O365 or the cloud. I just don’t see users taking the time to clean up or depose of files once they have been migrated. Applying records retention is a great idea, but it risks not being followed or worse yet, inadvertently disposing of files that really need to be kept. I like the idea of using a tool to scan and categorize the files before moving them. The biggest obstacle to cleanup, migration or record classification is the dependence on the end-user to review and clean up their files. Organizations should look at investing in a tool that will collect the files into categories that can be reviewed as a whole entity, have security policies applied and mapped to a records retention plan. Automating the process will both minimize the employee disruption and reduce the time to an acceptable length. I see this step as the first step in the implementation of a content management strategy. Please feel free to contact me if you are interested in getting more information on the discovery and categorization step or a more comprehensive view of a content management implementation method logy that I have created
Absolutely! I literally just had this conversation with a new client today
I think it’s important to note that blocked file types have been removed from SharePoint so every file type CAN be uploaded into SharePoint (or OneDrive).
I agree that there are lots of things on network storage that really need to be removed and figuring out what those are is a process.
Thor Projects LLC
Tom, you are in good company for sure. I have worked with many companies, almost every one we engage with, that struggle with the same problem. The heart of the issue seems to be that the user community has never been responsible for their content nor given any guidelines to help adequately manage it. This problem has grown over time and often decades of content has been dumped in file shares. Most would agree that it is mostly ROT (redundant, outdated and trivial) but no one is willing to take the time and expense to the “separate the wheat from the chaff”.
The only people that can add meaning to the content are the “owners” themselves and they don’t have time. Tools can help but, in most instances, we don’t trust them to assume that kind of responsibility. It is quite a conundrum. Nothing changes if nothing changes and this if very much the case here. For most of our clients this is the first time they have really thought about how they manage (or ignore) their content and the owner’s contribution. The Modern Workplace offered by M365 cannot be recognized without intentionally designing the user experience and helping users successfully transition to it … with as little “pain” as possible.