SharePoint as your file server: a practical site-design and security strategy for SMBs

TL;DR. SharePoint Online can replace the aging file server in the back closet — access from anywhere without VPN, automatic versioning, real backup, native co-authoring in Word and Excel — but only if you actually design the sites. The biggest mistake we see is treating SharePoint like a single big drive letter and dumping everything into one site. The right approach is a small number of well-scoped sites, organized by group (department or project) and security level, with permissions inherited from M365 groups rather than hand-managed per folder. Here is the playbook.

Why move off the file server

The traditional Windows / Linux file server was designed for a world where everyone sat in the same building on a wired network. That is not your business anymore. Real reasons our clients are moving:

• Anywhere access without a VPN. SharePoint files open from any browser, any laptop, any phone, with no VPN client and no “please connect to the office network” instructions.
• Automatic versioning and recovery. SharePoint keeps version history on every file by default, plus a 93-day recycle bin. Ransomware that encrypts files in a synced library can be rolled back from version history rather than from a backup tape.
• Real co-authoring. Two people editing the same Word document at the same time, no “file is locked” nag, no last-writer-wins. This alone justifies the switch in most professional-services firms.
• Search that works. SharePoint indexes file contents. Search for “PO 1027” and find every document that mentions it across libraries you have access to.
• Tied to identity, not the network. Permissions are based on Entra ID accounts and groups; if you off-board a user in M365, their access goes with them. No more “did we remember to disable that domain account?” gaps.
• No more storage anxiety. Each user license includes 1 TB of OneDrive plus a share of pooled SharePoint storage that scales as you add users.

OneDrive vs SharePoint — what goes where

The first decision is not which sites to build but which content belongs in OneDrive at all. Quick rule:

• OneDrive = files this person works on. Drafts, working notes, personal scans, downloads in flight. If they leave the company, almost nobody else needs that data.
• SharePoint = files the team works on. Anything two or more people touch — client folders, project files, contracts, designs, shared procedures. If the original creator leaves, the work continues.

If you can answer “does anyone else need this?” with “yes” or even “maybe,” it belongs in SharePoint. The classic file-server folder you know as S:\ or shared\ almost certainly belongs in SharePoint, not OneDrive.

Site strategy: design by group and by security level

Now the real question. The single biggest mistake we see is one tenant where someone made a SharePoint site called “Company Files” and dumped everything into it. Permissions become a nightmare. Versioning slows down. The 5,000-item view limit fires. Search results bury the wrong things.

Better: build a small number of sites, each scoped to a group of people who legitimately share access, with the permission level (and confidentiality) baked in. The patterns we use most often:

1. Department sites

One site per department: HR, Finance, Sales, Operations, Engineering. Each one is created as a Team site backed by an M365 Group, which means it automatically gets a Group inbox, a Team in Microsoft Teams, a Planner board, and a SharePoint site — all sharing the same permissions list. You add or remove a person from the M365 Group and they gain or lose access to all of it at once.

Department sites are usually private — visible only to that department’s members — with the manager as Owner and team members as Members.

2. Project sites

For specific, time-bounded work: a customer engagement, a software rollout, a building project. Create a site, invite the people involved (sometimes including external clients via guest access), do the work, then archive when the project closes. The lifecycle of a project site is often less than a year.

Project sites are usually private with the project manager as Owner; members may be a mix of internal staff and external partners (use guest access carefully — see the security section below).

3. Confidential / restricted sites

Some content needs tighter access than department-level: executive material, M&A or financial deals, HR investigations, compliance evidence. Create a separate, named site for each scope, with membership locked to a small named security group. Apply a sensitivity label at the site and library level so files inherit encryption and DLP rules even when downloaded.

This is where Microsoft 365 sensitivity labels shine: a label like Confidential — Executive can encrypt every file in the site, watermark it, and restrict copy/paste — without the user having to remember to do any of it.

4. Company-wide intranet (Communication site)

For policies, employee handbook, IT documentation, news, holiday calendar. Use a Communication site (different template than a Team site) which is read-only for most users and editable by a small content-owner group. This is the “everyone can read, only Marketing/HR can publish” pattern.

5. The hub site that ties it together

Once you have several sites, register one as a Hub site — usually the company-wide intranet — and associate the others with it. The hub gives you a shared top navigation, shared search scope, and consistent branding across sites. Users get one front door instead of bookmarking a dozen URLs.

Permissions: the rules that keep it sane

The biggest cause of SharePoint chaos six months in is people granting individual access to specific folders to solve a one-off request. By month twelve, no one knows who has access to what. The discipline that prevents this:

1. Permissions inherit from M365 Groups, not from individuals. Add the person to the right Group; never grant them direct access to a folder. If you find yourself wanting to grant access to one folder for one person, that is a signal you actually need a new site or library — not a permission exception.
2. Three roles, no more: Owners, Members, Visitors. Owners can change settings and add people; Members can edit content; Visitors can read. Resist the urge to invent more.
3. Do not break inheritance below the library level — ever. Once you start setting unique permissions on individual folders or files, the audit trail is gone. If a folder needs different access than the rest of the library, it almost certainly belongs in a separate site.
4. Check “Site Permissions” quarterly. A 15-minute review per site, removing people who left or roles that changed. Microsoft 365 Access Reviews can automate this for larger orgs.
5. Lock down external sharing per site. Default at the tenant level should be conservative (existing guests only, or specific domains only). Enable wider sharing only on sites where it is required for the business.

Migration: the gotchas that bite people

The actual file move is the easy part — tools like Microsoft’s Migration Manager, ShareGate, Mover, and Quest On Demand all do bulk copies competently. The problems come from data that does not translate cleanly:

• Filename and path length. SharePoint allows file paths up to about 400 characters total. Old file servers routinely have nested folders with paths well over that. Pre-migration audit is essential; some files need renaming or restructuring.
• Special characters. Modern SharePoint accepts most of what NTFS does, but a few characters (%, ~, leading dots, multiple consecutive periods) still cause sync issues. Run a scan before the cutover.
• The 5,000-item list view threshold. SharePoint will refuse to show a folder view with more than 5,000 items in it unless the columns being filtered are indexed. Either keep folders modest in size (under 5,000 items each) or set up indexed columns up front.
• Mapped drives habit. Users who think in S:\Customers\AcmeCorp need help mapping that to the new model. The OneDrive sync client lets you mount a SharePoint library locally so it looks like a folder — do that for the first 90 days, then most users naturally migrate to the browser/Teams interface.
• Permissions you forgot about. The old file server probably has folder-level NTFS permissions that nobody documented. Decide whether to recreate them in SharePoint exactly (often a mistake), simplify them aggressively (usually correct), or split out separate sites for the genuinely-different access groups.
• What about scan-to-folder and line-of-business apps? The MFP that scans to \\fileserver\scans, the LOB application that writes reports to a UNC path, the QuickBooks file that wants a local drive. SharePoint does not natively expose UNC paths. The fix is usually a small “hybrid” landing share that gets robocopied (or Power Automate’d) into SharePoint nightly.

What to leave alone, at least for now

SharePoint is excellent for documents and is a credible replacement for most file-server use cases. There are still a few things it is not great at:

• Very large media libraries. CAD/CAM, 3D, video editing — multi-GB working files where users open and save many times an hour. SharePoint can hold these but performance and sync behavior degrade. Often better on a dedicated NAS with cloud backup.
• QuickBooks company files — do not put the live .qbw on SharePoint. Use the OneDrive junction trick we covered in another post if you want backup, but operate the file from a local drive.
• SQL databases, Outlook PST archives, application data files. Anything that updates many small writes per minute is unhappy on cloud sync.

What InfiNet does for clients

For clients moving from a file server to SharePoint, our typical engagement looks like:

1. Audit the existing file shares: total size, top-level folders, last-modified distribution, problem files (long paths, special characters).
2. Workshop the site design: which departments / projects / confidentiality levels need separate sites; which M365 Groups exist or need to be created; what guest sharing rules apply.
3. Set up the SharePoint sites, hub registration, sensitivity labels, and DLP policies.
4. Pilot with one department for 2–3 weeks to surface anything we missed.
5. Run the bulk migration, usually after-hours over a weekend.
6. Train users on the new workflow — especially how to find things, co-author cleanly, and request access to sites they need.
7. Decommission the old file server (kept read-only for 60 days as a safety net).

If you have a file server that is overdue for replacement, or a SharePoint setup that has grown into a swamp of one-off folder permissions, drop us a line or call 970-282-8838. We do this fairly often.