I want to tell this the way it actually happened, because if you're reading a page titled "OneDrive sync is slow with a large library," you're probably standing exactly where we stood a while back — staring at a spinning tray icon, an angry colleague behind you, and a "processing changes" balloon that has been up since yesterday.
We didn't set out to build software. We set out to move a company off an aging file server. What we learned on that road is the entire reason OneMount exists.
Why we moved to the cloud in the first place
The old \\server\share was fast and everyone understood it — but it was also a single
box in a single building. No version history worth the name. Backups that someone had to remember.
Nothing for the people working from home. When a file got overwritten, it was just gone.
SharePoint Online and OneDrive for Business fixed all of that on paper: real version history, Microsoft-grade security and access control, availability from anywhere, and live co-authoring in Office. We believed in that move. We still do — the destination was right. It was the transport that fought us every step of the way.
Then the library crossed a terabyte
Our main department library was around a terabyte spread over an enormous number of files — years of documents, exports, scans, project folders. The plan was simple: point the OneDrive sync client at it and let people work in Explorer like always.
It did not go simply. New computers took the better part of a day to do their first sync. On weaker connections the initial sync would get most of the way there, drop, and start over from zero. And the tray icon spent days on end saying "processing changes" — a state that, on large libraries, is genuinely known to last for days rather than minutes.
That number reframed everything for us. We weren't misusing the tool. We had simply asked a file-copying sync client to mirror a library it was never designed to hold. Every synced file needs the client to track its hash, its timestamps, its sync and conflict state — and that bookkeeping is what falls over at scale.
The conflicted copies
Then came the file we still tell stories about. Two people opened what looked like the same
spreadsheet. The sync client, lagging behind, hadn't finished bringing one person's version down.
Both edited. Both saved. And the cloud gained a second file:
Budget (SomeName's conflicted copy 2026-03-14).xlsx.
Read that back slowly. We had moved to SharePoint specifically for a clean version history — one file, a chain of who-changed-what-and-when, roll back to any point. And the sync client, on the way to the cloud, was shredding exactly that: forking the file, duplicating data, and leaving humans to merge two spreadsheets by eye. Conflicted copies are a documented, everyday behaviour of offline-and-lagged edits, and at our scale the lag was constant.
People wanted their network drive back
By this point the mood had turned. Everyone had been happy on the old network drive, and they were
right about one thing: X:\ was instant, it never "processed changes," and
every program on the machine understood it. Nobody had ever filed a ticket that said "the drive
letter is stuck importing."
But going back meant giving up the very things we'd moved for — version history, security, remote access, co-authoring. We flatly refused that trade. The honest conclusion was uncomfortable and, in hindsight, obvious:
We didn't want the cloud or the network drive. We wanted the cloud's brain and the network drive's hands — the version history and security of SharePoint, reached through a plain drive letter that doesn't copy anything to the disk.
Why "just use the browser" didn't fly
"Then just open files in the browser" is the standard answer, and for a chunk of the company it's fine. For the rest, it's a non-starter — because a large amount of real business software can only open a path, not a web address.
- Accounting and ERP systems (the kind that live on a mapped drive and expect a database file on it).
- Access back-ends, shared databases, and the reports built on top of them.
- Engineering and CAD files with links to other files by path.
- Backup jobs, batch scripts, scheduled exports, and that one 2014 macro nobody dares rewrite.
None of them can open https://…sharepoint.com/…. They open X:\Projects\….
Take away the drive letter and half the company simply stops working — no matter how modern the
cloud behind it is.
People wanted to share in one click
There was one more request that came from every organization: "give us a button to share a file quickly, right from Outlook." People send colleagues and clients links to documents all day — and each time they had to open the browser, find the file in SharePoint, and copy the right link. A small friction, multiplied by hundreds of times a day.
And the "right link" isn't one link. A colleague inside the company wants the path on the mounted drive (it opens the exact same file). An outside person needs the SharePoint web link that survives a sign-in and opens in the browser. Choosing by hand every time is one more source of mistakes and wasted minutes.
We tried the dedicated tools
Before we wrote a line of our own code, we did the responsible thing and tried the existing tools that promise "SharePoint and OneDrive as a drive." I won't name them — this isn't about beating a competitor, it's about a pattern we kept running into, and it's the pattern that finally pushed us to build our own.
They asked for an app registration first
Before a single drive appeared, they wanted an Azure app registration in the tenant — admin consent, a project to create, a security review to pass. For a drive letter. On every tenant a customer of ours might have. That alone made them impossible to hand to a small company without a dedicated IT department.
Team editing didn't really work
This was the one that hurt. The whole reason we'd endured the migration was so that several people could be in one workbook at once. With these tools that was gone. Either the file was hard-locked to one person while everyone else waited, or two people worked in parallel and got — yes — version conflicts again. The single best thing the cloud gives you, real-time co-authoring, was quietly switched off the moment the file went through their drive.
Every save overwrote the version history
And then the deepest problem, the one you don't notice until you go looking. Each time you saved, the tool pushed a brand-new copy of the whole file up to the cloud — a fresh overwrite, not an edit of the living document. The clean chain of versions — this paragraph changed on Tuesday, roll back to Monday, see who did what — was replaced by a stack of full-file overwrites with no real lineage. The tool was technically "in SharePoint" while quietly dismantling the reason anyone chooses SharePoint.
A drive that breaks co-authoring and flattens version history isn't cloud storage with a drive letter. It's a network share wearing a SharePoint costume.
So we built OneMount
Everything we needed was on that list of failures, written as a set of requirements. So we built the thing that met all of them at once:
- A real Windows drive letter. Every legacy app — accounting, Access, CAD,
backups, scripts — sees an ordinary
X:\and is happy. No browser, no rewrites. - No sync, no copies. The terabyte stays in the cloud. Nothing downloads to the disk, so there is no 300,000-file wall, no day-long first sync, no "processing changes."
- No app registration. A normal Microsoft 365 sign-in, the same one people use for Outlook. Nothing to create in Azure, nothing for an admin to approve.
- Real co-authoring and full version history — kept. Because the file on the drive is the cloud document, not a copy of it, Word and Excel open it as the live SharePoint file. Several people edit at once, AutoSave works, and the version chain stays intact. We tested it with one workbook and two people, side by side, live.
- Sharing in one click. Right-click a file or folder on the drive and the OneMount menu in File Explorer copies the SharePoint web link (for outside people), or the drive path (for colleagues inside), opens the file in SharePoint, shows its version history, or sends it to Outlook. Exactly the "share button" organizations kept asking for.
That last point is the whole game. We didn't want to reach the cloud by copying files out of it — that's what had been destroying version history all along. We wanted the drive letter to be a window onto the cloud file, so everything SharePoint does well keeps working. That's the line OneMount is built on, and it's why the path from this story led to a product rather than another workaround.
If you're in the middle of this right now and just want the drive letter working today, the practical companion to this story is here: how to map SharePoint as a network drive in Windows — the methods, the real limits, and what actually holds up →
Sources