In every second company we walk into, there's a file server in some closet — usually with a mapped drive called "Z:\\\\company" and a folder structure that only two people in the building still understand. The decision to move it to SharePoint and OneDrive is rarely "should we"; it's "how do we do it without downtime and without losing the permissions that have been piling up there for ten years".
Earlier this year we ran exactly that migration for a 24-person audit consultancy. The old file server (Windows Server 2019, two disks in RAID 1, 920 GB of data) lived in a server room next to a UPS whose batteries had died two years earlier. Backups were "to a second disk in the same box". They had 12,800 folders, 412,000 files, six years of history on average, and a lot of 15 MB scanned PDFs. After the move to SharePoint Online (on the Microsoft 365 Business Standard licences they already had) plus OneDrive, they were left with three team libraries, a clear split between "mine" and "ours", and roughly 11,000 PLN a year less in running costs (electricity, server room maintenance, Windows Server licence, off-site backup). The whole project: 5 calendar weeks, with the actual "from now on we work from SharePoint" cutover taking a single weekend. Files lost: zero. People who couldn't open something in the first week: four — and each ticket got closed within an hour.
Here's how this is done properly.
What's actually on your file server
First truth: nobody in the company really knows. The second week of the project is purely inventory work, without touching a single file. Skip this and the rest goes blind.
- Size and file types. Sort folders by size. At our client, out of 920 GB total, 320 GB were zip archives of old projects nobody had opened since 2019. Those went to cold archive storage, not SharePoint. You pay per megabyte times years.
- Files larger than 250 MB. SharePoint handles them, but the sync client starts choking when whole directories are full of them. Video, large CAD files, ISO images, database dumps — that's not SharePoint territory. That belongs in Azure Files or on local storage.
- Files opened more often than once a month. Easiest way: a PowerShell script listing
LastAccessTime. At our client, only 18% of the data was actively in use. The rest is history that doesn't need to be synchronised to every laptop. - Paths longer than 400 characters. SharePoint has a hard limit of 400 characters on the full URL path. Folders like
Clients\\2018\\ABC Ltd.\\technical documentation\\revision_3_after_client_comments\\...are exactly the situation where the Migration Tool throws a red box at 4am. - NTFS permissions on the server. This is a separate sadness. Pull a report (
icacls, AccessEnum, or a PowerShell script) before you touch anything. In practice a 25-person company has 80–200 unique permission configurations. Many can be consolidated — and now is the moment to do it, because SharePoint doesn't like "permission per file" models anyway.
This stage isn't glamorous, but this is where you eliminate 60% of the problems.
SharePoint, OneDrive or Teams — what goes where
The most common mistake: dump everything into one giant SharePoint library and be done. Six months later nobody can find anything, because a folder tree from 2010 doesn't match how people collaborate in 2026.
The rule that works in SMEs:
- OneDrive — these are my working files. Draft versions, notes, materials I don't need to share with anyone yet. Every M365 Business user gets 1 TB, which in practice lasts years.
- SharePoint (libraries inside team sites) — these are department or project files. "Everyone in finance", "project X team", "management documents". This is where collaboration happens.
- Teams files — this isn't a separate place. Teams stores files in SharePoint under the hood. If someone is selling you "migration to Teams" as an alternative to SharePoint, that's a salesperson, not an architect.
For the 24-person company it came out as: one main intranet site, four department sites (finance, sales, projects, HR), with 2–4 libraries each. About 16 libraries instead of 12,800 folders on a single drive. This is the moment for "simplify", not "copy 1:1".
A migration plan without a week of downtime
Microsoft gives you the SharePoint Migration Tool (SPMT) and Migration Manager in Admin Center. Both are free, both work. For a typical 25-person company, SPMT is enough.
The pattern we always propose:
- Dry run on a 50–100 GB subset. You find out what Migration Tool flags red: paths too long, illegal characters in names (
#,%,*in older file names), zero-byte files, empty folders. Fix at source (rename, shorten paths), because SharePoint will simply skip those at the end. - Historical data migration in the background, over 5–10 days. People keep working on the old server. Migration Tool copies what doesn't change (archives, closed projects). That's 80% of the volume and 20% of the risk.
- Cutover weekend. Friday at 6pm you set the old server to read-only at the NTFS level. Saturday — delta sync, pulling across everything that changed in the last week. Sunday — testing, spot-checking dozens of random folders, mapping new desktop shortcuts.
- Monday morning — everyone has a desktop shortcut to SharePoint instead of "Z:\\\\company". The old server stays online for another 30 days in read-only mode, as a lifeline. Nobody writes anything new there, but if someone goes hunting for "that version from February", there's still somewhere to look.
The most common mistake here: somebody tries to cutover in the middle of a working week, "because the boss doesn't want to pay weekend overtime". You only do that once.
What NOT to move to SharePoint
SharePoint is great for office documents. It's bad for a few specific things, and it's better to say so upfront.
- Application databases. Microsoft Access
.mdb, SQLite, any file an application keeps open all the time. The OneDrive sync client can't handle them — it produces conflict copies every 5 minutes. Those live in SQL Server or Azure Files. - Folders with hundreds of thousands of small files. Application caches, log exports, temp files. SharePoint's library limit is 30 million items, but the sync client starts breaking well before that. Keep those local or in object storage.
- CAD and video files over 1 GB. Technically they fit, but realistically — an architecture office working on 500 MB DWG files will have sync sitting still all day. For that there's Azure Files with drive mapping, or a dedicated NAS in the office.
- Files that need to be open 24/7 by many users at once. Excel-as-a-system is its own topic (we have a separate post on that), but if you have that kind of file, on SharePoint you'll get a version-conflict slaughter. Fix the application problem first, migrate later.
This is one of three conversations worth having before you start the migration. The second is the permission model. The third — who deletes a file when someone leaves the company.
What next
Migrating a file server to SharePoint in a 25-person company is a 4–6 week project, not a weekend job. Most of that time is the boring work: inventory, cleaning up file names, consolidating permissions, agreeing on where "mine" ends and "ours" begins. The technical migration itself is the last 20%.
The value isn't "we're in the cloud now". The value is that after the migration nobody asks "where's file X" — because the structure is flat, search works, and phone access doesn't need a VPN. Plus, no more server in a closet with a UPS battery nobody's replacing.
If you've got an old file server and you're already paying for Microsoft 365 licences, let's talk before someone sells you "a weekend migration". The first call is free and takes half an hour.
Migrating to SharePoint isn't a 1:1 folder copy. It's the moment you honestly admit that 60% of what's on the file server shouldn't have been there for the last five years.