“Ever since we moved to the cloud, opening files is slow.” It’s one of the most common complaints after a migration — and one of the most fixable, because the cloud platforms themselves are almost never the bottleneck. Microsoft and Google serve these files from infrastructure your business couldn’t buy; when access feels sluggish, the cause is nearly always somewhere between their data center and your double-click. Here are the five usual suspects, in the order we actually find them.
Suspect one: sync doing something heroic in the background
The most common cause by far. The OneDrive client on a user’s machine is quietly processing something enormous — an initial sync of a migrated library, a colleague’s 4,000-file dump into a shared folder, a photo archive someone dragged in — and everything else queues behind it. The tells: the sync icon perpetually spinning, “processing changes” for days. The fixes: patience for legitimate one-time syncs (initial migration churn is real and finite) · selective sync discipline — nobody needs the entire company SharePoint synced locally; sync the libraries you work in, browse the rest on demand · and Files On-Demand left on (its default), so files download when opened rather than all at once. Half of “the cloud is slow” tickets are one machine syncing a mountain nobody meant to move.
Suspect two: the network the cloud now depends on
Migration quietly changed what your internet connection is for: it became the hallway to your file server. Three network realities bite in order — upload bandwidth (business connections are often asymmetric; saving and syncing files up crawls on a thin uplink even when browsing feels fine — and the cable plan that predates your migration probably wasn’t sized for this) · Wi-Fi doing what Wi-Fi does — the office’s real wireless coverage, not the cloud, behind that one slow conference room · and everything sharing one pipe, where a right-sized connection, decent equipment, and failover for the bad days is now core infrastructure spending, not an office expense. The diagnostic is simple: if files are slow on Wi-Fi and fine wired, or slow at 2 p.m. and fine at 7 a.m., you’ve found your suspect.
Suspect three: the library that grew wrong
SharePoint performs beautifully within its design and gets weird outside it: libraries with hundreds of thousands of items in one flat structure, folder trees so deep that paths hit length limits, permission structures fragmented into per-file exceptions that slow everything they touch. If one specific library is the complaint, the library is usually the cause — and the fix is structure: split the monster into sensible libraries or sites, flatten the archaeology, archive the decade of stale content per your retention decisions. Bonus: everything else about that library — search, access review, backup — gets faster too.
Suspect four: working against the grain
Some slowness is workflow mismatch rather than malfunction. Multi-hundred-megabyte files opened directly from web links will feel heavy; the sync client exists precisely so big files open locally at disk speed. Legacy habits — mapping SharePoint as a network drive, emailing 80MB attachments instead of links — fight the platform’s design and lose. And genuinely huge-file work (CAD, media, datasets) has its own patterns and sometimes its own tooling — a topic with its own article, because “put it in OneDrive” isn’t the whole answer at that scale.
Suspect five: the machine itself
Cloud clients are software running on the endpoint: an aging machine with a spinning hard drive, 8GB of RAM, and six years of accumulated startup cruft will make any file system feel slow — the cloud just gets blamed because it’s new. If slowness follows a specific computer rather than a specific library or location, check the hardware’s age against the lifecycle before touching a single setting; an SSD-equipped machine from this decade is the fix more often than anyone wants to admit.
The bottom line
Cloud file sharing is fast when the pieces around it are: sync configured with restraint, an internet connection sized for its new job, libraries structured within design limits, workflows that use the grain, and endpoints that aren’t the actual bottleneck. Run the suspects in order — sync icon, network, library, workflow, machine — and “the cloud is slow” almost always resolves into one specific, fixable thing that isn’t the cloud at all.