This two-part series was written in collaboration with Johanny Torrico, Community IT’s Director of Ongoing Network Support. We’ve received the following types of questions frequently, and so we have chosen to provide you with the answers in this blog series. You can find additional questions in Part 1.
This post was updated May 2016.
There are two drivers of a SharePoint implementation being a significant initiative for an organization. One is the change management needed to get users on-board with SharePoint workflows, getting them used to (and accepting) finding and accessing files in a web browser instead of in File Explorer. The second is the architecting and organizing of file libraries. Questions addressed in planning architecture include:
Metadata are the “tags” that SP attaches to documents and other SP items. This includes things like permissions (who can access, who cannot), when it was created and modified but can (and should) also include customized tags (examples: “programs” or “planning” or “HR” or “critical” or whatever). With a file server, your organizing principle is the folder hierarchy, but with SP, it’s the metadata. You can end up searching or listing docs by the tags you add to files. What’s cool is that docs can have more than one tag, which is why it’s more powerful than folder hierarchy. With hierarchy all your HR docs are probably in the HR folder, but with tags they get the HR tag but might also get the “planning” tag and/or “critical” tag. Please note that my examples are only examples. We don’t use any of those tags at Community IT except HR.
SharePoint is a terrific repository for the standard Microsoft Office documents (Word, Excel and Powerpoint), works moderately well for PDFs, jpegs and other modestly sized read-only image files. Office 365 SharePoint has a recently upgraded file size limit of 10 GB so even video files could be stored in it, although actual work on large media files should always be done locally.
SharePoint won’t work as a place to store database files (Quickbooks, Sage, etc.).
For organizations of less than ten seats who have moved everything else to cloud services, it does seem reasonable to replace the file server with Office 365 SharePoint Online. For larger organizations, with more complex requirements, having an on-premise for domain controller and utility/management functions is of great value so keeping the file server role on an on-premise server for at least some files (maybe older archival files) may make sense.
As our practice evolves, we are leaning away from positioning SharePoint as a way to get rid of file servers. We prefer to view (possible) eventual deprecation of file servers as a side benefit of a SharePoint implementation. The benefits of SharePoint should focus on the power of next generation file collaboration (far superior remote access, ability to share with external partners, versioning, co-authoring, vastly improved search and discoverability, etc.) rather than on its potential to remove the last piece of server hardware in the server room. Though we understand why that possibility is attractive, we don’t see it as a significant enough benefit to warrant the investment a successful SharePoint implementation demands.
We recommend third party backups, because just because your data is in the cloud doesn’t mean that it’s protected to your organization’s requirements. Microsoft takes snapshots of its customers’ SharePoint sites every 12 hours and maintains those snapshots for 14 days. So if a virus on your computer (not Microsoft’s) infects your SharePoint library and makes all the files unreadable (less unlikely than one might think), you could open an incident with Microsoft and they could roll back your library to the point it was at up to 12 hours before the infection. Note that this process could take several days, during which SP wouldn’t be available. See this online resource.
According to a 2013 survey by the Aberdeen Group, the most common reason for SaaS data loss was end user deletion with the second most due to employee overwriting of data elements shared by others. SaaS providers may provide multiple warnings about making sure data changes are desired before the application is closed but end users will still make mistakes. SharePoint mediates these risks by providing a recycle bin and versioning control, but in our experience these tools are not infallible.
Our Best Practice is to deploy a third party backup solution. Implementing a third party backup solution provides more ownership and control over a potential recovery. Instead of waiting for Microsoft to approve the recovery request the organization would be able to initiate a restore based on their own requirements and timeline. SaaS applications provide a high level of performance and availability, but it is still important to protect and maintain access to those files outside of the vendor’s system.
Community IT has explored both SharePoint and OneDrive on our blog in the posts on OneDrive vs SharePoint and OneDrive vs Dropbox.
You may also be interested in free Webinar resources we have presented on Sharepoint, OneDrive, and Dropbox. See our catalog of past webinars here.
Wednesday June 17th at 3pm Eastern join Steve Longenecker for tips to set up or re-set your Google Workspace for security as you grow.
Fill out the form below to request a quote. We’ll be in touch shortly to discuss your needs and take the first step toward better nonprofit IT.