Alternatives to OneDrive and SharePoint (and when to consider them)Alex Fields
One of the things I often get asked about is how to deal with various limitations in OneDrive and SharePoint Online. For those who don’t know, SharePoint Online is the file storage & sharing solution underpinning the Microsoft 365 universe of applications, including the popular Teams application, while OneDrive for Business provides for personal file storage (i.e., modern replacement for “My Documents”) as well as a client application for keeping all your cloud-based documents synchronized to your local device.
Our SquareOne peer group recently had an informal, ad-hoc meeting about this problem: Where do you turn when OneDrive and SharePoint are (seemingly) unable to meet the needs of the business?
This can happen for a few different reasons. So, before we talk about solutions, let’s examine the most common limitations that organizations can run into when using SharePoint and OneDrive.
Not enough (shared) file storage
Every single user in Microsoft 365 gets a minimum of 1 TB of personal data storage (OneDrive space). This is not usually a bottleneck for most organizations. However, SharePoint Online (where you would put any of your “shared” Company data), is limited to 1 TB + 10 GB per licensed user.
For an Enterprise organization with thousands of users, those seats add up quickly, and you will easily have several terabytes of storage available. For example, 10,000 employees x 10 GB each = ~100 TB. Small business subscriptions unfortunately share the same limitation as Enterprise, so that means a 30-person organization only gets a measly ~1.3 TB of storage total for all shared documents in SharePoint Online.
This is a problem. Particularly if there are very many files, or very large files such as architectural or engineering drawings, or high-density images, or anything like that. That meager storage will be consumed very quickly indeed. Yes, it is possible to buy additional SharePoint storage, but at USD $0.20/ GB/month, it is some of the most expensive storage space in the cloud.
My personal wish here is that Microsoft would just change the storage limitations for “Business” plans so that instead of 10 GB/user, we get something better like 100 GB/ user (at least). Or, better yet, just give us like a “Business Ultimate” plan that includes unlimited email and file storage and charge a premium price like USD $35 or $40/user/month.
Too many files to sync, or other limitations
OneDrive includes a client app that will automatically synchronize your personal files to the local desktop (we have a similar app to make them available on personal mobile devices, as well). You can optionally choose to sync shared locations in SharePoint Online in addition to your OneDrive files. However, when you attempt to sync too many files, you can cause problems for the sync application, and then your employees fall into the Pit of End User Despair™.
How many files is too many? Well, that’s a complicated question. Microsoft recommends syncing no more than 300,000 files and folders total to your computer. But that is somewhat misleading, because I have seen the client sustain more files than that (especially since the release of the 64-bit client), but I have also seen the client bomb out under even less stress (more like 90-100K files). If memory serves right, this limitation actually comes from a .DAT file stored somewhere in your local app data folder.
As well, larger files such as architectural and engineering drawings will sync (and support for large files has improved in the last year since the release of the 64-bit client), but it still is not the same experience as working with general Office files. For example, co-authoring is not a thing here, and syncing large files is more demanding; upload times can be very slow, especially over budget links such as DSL.
Therefore, certain SMB organizations that regularly use larger file types (e.g., construction, engineering, architecture, attorneys who deal with patents which include engineering drawings, etc.) may still find the sync experience is less than ideal for their requirements, especially if they are used to having SMB shares available on their LAN.
There are a few other limitations on file structure (such as depth of folders/length of file path), and number of files per folder or view (5,000), but these are not run into quite as frequently as the other problems I just now touched on. Plus, they are generally more “correctable” than running up against storage quotas or sync issues, which are less in your power to control. Nevertheless, several other limitations do exist, and you should be aware of them.
What do we do about these limitations?
Historically the way we dealt with these problems was to tell the customer, “Well of course it isn’t working, because you aren’t doing it right!”
We would scold them for needing access to so many objects on every client device, all the time. “Don’t you know that it is impossible to work with that many files in any reasonable timeframe? Imagine trying to contribute to more than 300K files in a month, or even in a year! Nobody actually does that, so why sync all the data to begin with?!”
Or, “Look, you can’t expect every third-party file type to be supported equally: if you work with some larger file types, do not expect co-authoring on them, instead plan to download/upload your changes like you would have for all types of files 10 or 15 years ago.”
While these statements may be true, and difficult to argue with, the simple fact is that back in the olden days when customers just had a primitive NTFS file server with SMB file shares, users could keep whatever they wanted, for however long they wanted, and have access to it any day of the week. They didn’t have to obey the seemingly arbitrary laws of the Microsoft Cloud.
In an ideal world, we could just easily migrate all files and folders, as they exist today, from point A (usually an on-premises file server) to point B (the cloud), and have the experience be pretty much the same for end users. The problem is that file servers and SharePoint sites are apples and oranges. So, it’s not realistic yet to put those expectations out there (those who have, have paid dearly for it).
Yes, it is true that SharePoint does a bunch of cool stuff that your local file server cannot (e.g., metadata, search and indexing, retention labels, sensitivity for sites, etc.), but the reverse is also true: your old file server did some pretty basic things really well, some of which are still impossible for SharePoint and OneDrive.
Alternative #1: Use another popular cloud storage provider
I can’t speak for the Enterprise, but at least in the SMB market, the most popular alternatives to Microsoft’s “built-in” ecosystem for file sharing remain Dropbox, Box, and Citrix Sharefile (roughly in that order). Maybe Google Drive ranks in there as well, however, I know a lot of folks on Google’s platform also supplement with one of these other providers for file sharing, too. My personal favorite of these options is Box, but that’s just based on my own familiarity with it (others may feel strongly about one of these others—and that’s fine).
If you are going to supplement your Microsoft 365 subscription with one of these other solutions, I would recommend ensuring you get a real business plan, not a personal or “basic” plan. Generally speaking, this means you will be spending something like $25/user/month or more for a complete feature set, usually including unlimited storage space and Enterprise-grade security options. At the time of this writing, in the Dropbox world, this means aiming for at least the “Advanced” offering (for Teams). If you choose a Box subscription, this could mean the Business Plus or even Enterprise tier, and for Sharefile, you should be evaluating their Advanced or Premium options.
Why we do not have an “unlimited storage” plan in the Microsoft cloud is beyond me. If it were up to yours truly, Microsoft would have an unlimited offering that can compete with these other big hitters. The option for limitless capacity is probably the number one driver that pushes people into a third-party cloud when it comes to file storage. Note: You should not expect a switch into one of these other ecosystems to be a panacea: to eliminate all downsides, fix or prevent all sync issues, etc. However, when it comes to overall storage capacity, every other provider out there has Microsoft beat.
Anyway, if you decide third-party is the way to go, always set up Single Sign-On with Azure AD so that you can apply the same identity-based protections, such as Conditional Access, that you already enjoy with Microsoft 365. Also you should know that Box and Dropbox have integrations available with Microsoft Defender for Cloud Apps, so that you can monitor activity and create alerts and rules around these applications, just as you do for Microsoft 365, using the Activity log.
Alternative #2: Check out Azure File Sync
If you would rather not leave the Microsoft cloud, and especially if you want to maintain an experience as close as possible to your current Windows-based file server, then Azure Files is another solution worth taking a closer look at. This is basically SMB file shares in the cloud. However, the best implementation of it to replace existing file servers, in my opinion, would be Azure File Sync. This premium solution allows you to seamlessly extend your existing on-premises file server into the cloud, and the users generally cannot even tell the difference.
Basically, your existing file server gets an agent installed on it, which then synchronizes your shares into Azure Files. Client computers continue to connect to the local file servers, but the data can be migrated on the back end into Azure. Eventually the server just serves up cached copies of the most frequently accessed datasets. Better yet, you can choose to take the most infrequently accessed data (think: archives, etc.) and move those to “cooler temperature” storage in the cloud. This is cheap storage, which is slower to access, but less expensive to maintain. Active files can remain on “hot” storage so that access stays quick and reliable. This feature is known as “cloud tiering” and it is one of those things that makes the solution extra attractive. For backup, you simply deploy Azure Backup and configure a backup of Azure file shares on a schedule that works for your organization.
Now, let’s say that you need to replace your existing physical server, either because it is just time for a refresh, or because you had a sudden crash or hardware failure in your datacenter. No problem. In the short term, your end users can connect to Azure via VPN and get access to the cloud-based shares quickly. In the long-term, you would replace your physical server with something cheap and affordable: just install the agent to present the shares locally out to the network, and away you go.
Thus, Azure File Sync turns your local server into something resembling “Branch Cache” (if you were familiar with that Windows Server feature, it’s a very similar idea). It is not unreasonable to assume your current server capacity could be scaled back to maybe 20% of the storage requirements (most data lives in the cloud, with only the most frequently accessed items available on the local disks).
The big benefits to this service are that legacy applications generally still work with it (since it is still just SMB shares), and it tends to be more affordable per-user or “per-gigabyte” especially with cloud tiering enabled. Note also that both domain and workgroup environments are supported with this solution.
Alternative #3: Split the difference
The last option is to forge ahead (mostly) with Microsoft solutions: usually in a “hybrid” configuration where the on-premises server is going to be around for at least one more refresh cycle while your organization figures out the rest of the puzzle on its own. Note: you can still start to relocate certain Office documents into OneDrive, Teams, and SharePoint as well, but you don’t have to go “all in” either. Take the time to learn how your organization can work around the current limitations in various ways. This makes for an easier end-user transition while still taking advantage of the elasticity and flexibility of the cloud where it makes sense.
For example, we direct people to use the SharePoint web interface and/or the Teams client for most shared repositories, and only sync very few data locations that contain smaller numbers of files (like a specific project folder), or other areas where the users work daily. We generally also recommend enabling the groups expiration policy and retention policies to keep content fresh and current (removing old, dead data regularly).
In a big migration project, we may even recommend migrating only those datasets which are considered “active” working data, versus all the “archival” stuff which may not need to exist in the cloud, at all. This helps cut down on clutter and overall storage demand. Some of these legacy items might end up on a separate network segment somewhere, on a legacy file server, SAN, or NAS device (where they go to die a slow death). Or maybe this is where we find a separate cloud storage account and place it under the care of a specific individual or individuals with access to those particular locations.
I should perhaps mention, there is also an alternative OneDrive/SharePoint sync client out there called Zee Drive, which some people have reportedly found success with (I cannot say much about it other than what others have told me—in other words, this is not an endorsement by any means).
Keep in mind that many organizations fit nicely within the existing limitations and have no problem moving 100% into the Microsoft 365 cloud ecosystem. Especially “Microsoft Office-centric” professional services that work primarily in the Office apps, perhaps with a splash of Adobe on the side, etc.
At the same time, there are many, many companies who run into these barriers due to legacy apps, large file types, larger file sets, etc., and therefore, these folks often wander down a different path. Sometimes, this means going to a third-party cloud, or it means remaining in a hybrid situation, or patching together some other alternative. This is not a new problem, either. Honestly it is a bit surprising that even now, in the year 2022, we are still left wanting in certain areas, and there isn’t always just one satisfying “right” answer. But, that’s where your consulting comes in, isn’t it?
What else have you been deploying for your customers when Microsoft doesn’t quite fit the bill? Let us know in the comments, below!
Good article, and this is something we are seeing come up from time-to-time when working with customers on their migrations. One thing that I think you should at least make mention of is third party solutions such as Mindscape’s Zee Drive and iam Cloud’s Cloud Drive Mapper. We have found that in particular scenarios these solutions allow users to access all of their files in SharePoint Online without the OneDrive limitations while still providing many of the benefits. While they are definitely not for everyone, we’ve had success with many finance & accounting departments who have many linked documents (and need to maintain their drive letters so they don’t need to use a utility to try and update all of their broken links), need file explorer-based access to more than 300k files at a time, but want to move off of file servers.
I guess needs to be mentioned that all these additional solutions will drive budgets considerably higher than before migration to cloud. You probably win some going to M365 and ditching on-prem infra, but then you have to buy second service or leave some on-prem storage solutions running and then migration to cloud doesn’t look that nice.
Depends on how you look at it… most of the time the cloud is still more appealing, even with additional cost. The value of mobile access, uptime/resiliency, etc. is difficult to replicate on-prem also.
The biggest challenge is having lots and lots of files and a large storage requirement (think several dozen terabytes or more). This is simply cost-prohibitive, and not practical for SharePoint. For example, even buying an additional 1x dozen terabytes over your quota = ~$2,500/month. In this case you would most likely be looking at Azure File Sync (where you can take advantage of cloud tiering & cheap “cold” storage). Or, maybe you just set up a few select people with licenses/access to archival stuff that gets tossed into an unlimited Box account or something. These are more affordable ways to deal with extremely large datasets, if the goal is to get out of the datacenter business yourself, and lean more heavily into the cloud.
Forgot to mention. We are Box shop here (looking to move to OneDrive). And after using it for 3 years i must say Box has its own set of quirks and annoyances with sync. Fails to sync or download larger files regularly (ISOs) or even can’t reliably open cloud-only txt file of a few bytes size. This is with File Explorer integration. OneDrive being from the same vendor works more reliably with Windows.
Very timely! We just got our first SharePoint storage warning last week. I did hope to find some old sites with too many files – no such luck, our staff are actively using many different Teams. I don’t want to crack down on good behaviour or scare folks off into some kind of shadow IT crawlspace. The cost per TB is a bit heavy but one comparison I do make is the time required to manage an additional data storage location.
When it comes to options for archived files (read: the old G-drive or H-drive) – how good or bad an idea is moving these files into the OneDrive of a new paid user account and then sharing read access back to the relevant units?
Ian, we have adopted the “archive to OneDrive and create shared access” solution that you’ve suggested for one of our clients, and I think it’s quite a cost effective solution. One limitation to be aware of, however, is that you can’t map the shared OneDrive storage to a drive letter like you can with SPO, so users must access the shared OneDrive storage via a web browser, not Windows Explorer.
I should clarify my comment above. It is possible to access the OneDrive share in File Explorer by opening the share link in a web browser and select the Sync option, as you can do for any SharePoint library.
Strictly archive, so hopefully users would just browse the files online – no drive letters and no syncing either. I do wonder Microsoft throttles traffic differently on OneDrive shares versus Teams.
[…] Alternatives to OneDrive and SharePoint (and when to consider them). There are scenarios in which it is difficult to avoid some of the technical limitations of SharePoint technology. What to do in such cases? […]
How do you see people handling PDFs in SharePoint? You have to sync the library to windows explorer to open them in Acrobat.
Good article – would you be able to clarify “In the long-term, you would replace your physical server with something cheap and affordable: just install the agent to present the shares locally out to the network, and away you go.” How cheap/affordable if I am assuming it still has to run Windows Server OS with number of user CALs licensing if using physical boxes? Otherwise a NAS device in which case is there such an agent? However, if you mean an Azure Server VM instance acting as a File Server in the cloud, I’m guessing that would work (but CAL licencing still required?). It could still incur a fairly expensive monthly azure subscription fee in that case? If you have a suggestion that would be great. We are using Egnyte (expensive) because for small businesses, the issue for us is being able to establish/easily manage group membership and permissions for each department, beyond the sprawling Onedrive and difficult to manage Sharepoint repositories. Thanks!
There are many ways to cut corners on cost whether going hardware route or cloud vm. For example, I have even seen where someone used a little NUC with Server Standard on it, just to act as a little branch office server basically. Nothing super critical on it. All local network services (DHCP, etc.) handled by firewalls, and this was just there as a presentation layer for file shares, etc.–hardly anything.