OneDrive vs SharePoint vs Teams Files: Which Should Your Small Business Use?

About once a week, a Central Coast business owner asks me a version of the same question. "We have OneDrive, we have SharePoint, we have Teams. We have files in all of them. Where are we supposed to put what?" It is a fair question, and the official Microsoft documentation does not always make it easier to answer. This post is the version I give to clients in plain English, with the trade-offs called out and a reference pattern for a 15-to-100 person business.

The thing nobody tells you up front

Here is the single most useful fact about Microsoft 365 file storage, and the one that almost never gets stated clearly: SharePoint Online is the underlying storage layer for both OneDrive and Teams files. They are not three separate products with three separate storage systems. They are three different presentation surfaces on top of the same backend.

• OneDrive is your personal SharePoint site. Every Microsoft 365 user gets one. The technical name is "OneDrive for Business," and under the hood it is a SharePoint site collection with one owner: you. The mobile app, the desktop sync client, and the web UI are all just front ends to that personal SharePoint site.
• A SharePoint site is a shared SharePoint site collection. It has multiple owners and members. It can have multiple document libraries. It can have lists, pages, news posts, and other SharePoint features. The Files tab in any modern team or department is a document library inside one of these sites.
• A Teams channel's Files tab is a folder inside a SharePoint document library, tied to the SharePoint site that backs the Team. When you click Files in a Teams channel, you are looking at SharePoint with a different chrome around it.

Understanding this clears up most of the confusion. When you ask "where should this file live," you are really asking "which SharePoint site (and which document library inside it) is the right home." OneDrive, SharePoint, and Teams are the apps you use to get to the file. Where the file actually lives determines the permissions, the retention rules, the backup posture, and what Copilot can see.

When to use OneDrive

OneDrive is for files that belong to one person. Think of it as your personal scratchpad, draft folder, and travel bag for work-in-progress.

The right things to put in OneDrive:

• Drafts of documents that you have not shared with anyone yet.
• Personal work files (notes, your own templates, your own task lists).
• Files you want to follow you across devices but that nobody else needs to see by default.
• Temporary scratch space for files you are about to email out or upload somewhere else.

The wrong things to put in OneDrive:

• Anything that the department, project, or company needs to keep when you leave.
• The "official" version of a customer contract, vendor record, financial report, or policy document.
• A shared folder you have invited the whole company into. (More on why this is a problem below.)
• Anything that needs a retention policy applied at the department or organization level.

The mental test I use: If this person took the job offer in Phoenix tomorrow and disappeared, would the business still need this file? If yes, it does not belong in OneDrive.

When to use SharePoint

SharePoint is the default home for files that belong to the business rather than to one person. It is the digital equivalent of the locked filing cabinet in the office that the department uses, not the one in your personal desk drawer.

The right things to put in SharePoint:

• Official department documents: HR forms, finance reports, sales collateral, operations procedures, legal templates.
• Policies and procedures that apply across the team or company.
• Customer files: contracts, project deliverables, correspondence archives, signed statements of work.
• Project files, especially those that will outlive any one employee.
• Anything subject to a retention obligation (industry regulation, contractual requirement, insurance requirement).

The SMB pattern that works: one SharePoint site per department or business function. For a typical professional services firm, that means HR, Finance, Operations, Sales, Legal, and IT each get their own site, with their own owners, their own members, and their own external sharing posture. Each site has the document library structure that makes sense for that function.

The pattern to avoid: one giant company-wide SharePoint site with every department's files in one document library. It collapses under its own weight by the time you have 25 employees.

When to use Teams files

Teams files are for the workspace where active collaboration is happening right now. A Teams channel gives you a chat thread, meeting history, tabs for apps, and a Files tab. That Files tab is where the documents the team is currently working on live.

The key insight: the Files tab IS SharePoint underneath. When someone uploads a document to a Teams channel, the file does not exist in some separate "Teams storage." It is placed in a folder inside the document library on the SharePoint site that backs the Team. You can open that exact same file from the SharePoint web UI, sync it to your desktop via OneDrive, or grab it via the Microsoft Graph API. The file does not move; only the chrome around it changes.

This matters because:

• Sharing a file in a Teams channel does not copy the file. It posts a link to the same SharePoint location. Edits flow through whichever surface you used to open it.
• When a project ends and the Team becomes inactive, the files do not vanish. They are still sitting in the SharePoint site, available to anyone who had access.
• Retention policies applied at the SharePoint site level apply to files uploaded through Teams. Compliance and legal hold work the same way regardless of which surface the file came in through.

The right pattern: use Teams as the active-collaboration surface, and treat the underlying SharePoint site as the permanent home. When a project ends, you can either keep the Team archived for reference or move the surviving documents into a department SharePoint site and let the project Team retire.

Permissions, the SMB way

The three permission patterns that fit a small business are simple. The trick is applying each one to the right surface.

Pattern 1: Personal (OneDrive default)

Default OneDrive permissions are: you (the owner), the tenant admins (for recovery and compliance), and anyone you have explicitly shared a specific file or folder with. No site members. No automatic departmental access. If you want someone else to see something in your OneDrive, you have to share it directly.

This is correct for personal scratch work. It is wrong for departmental files.

Pattern 2: Departmental (SharePoint sites with owners, members, visitors)

Every SharePoint site has three default permission groups:

• Owners — can change permissions, manage the site, delete content. For a department, this is the department head and optionally an admin. Keep this list short.
• Members — can read and write content. This is the working population of the department.
• Visitors — read-only access. Useful when another department needs reference access without edit rights.

The discipline is to populate these groups with security groups (or Entra ID groups), not individual users. Adding "Sales Team" as a group to the Sales site's Members group means new hires automatically get access when they are added to the group, and lose it when they are removed. Adding individuals one at a time creates the access drift that becomes the oversharing problem two years later.

Pattern 3: Project/team (Teams membership, with private channels as a layer)

A standard Microsoft Team has one membership list. Everyone in the team sees every standard channel. The team is backed by one SharePoint site, and the standard channel Files tabs are folders inside that site's document library.

Private channels add an extra layer. Each private channel gets its own SharePoint site, separate from the team's main site, with its own membership. This is useful when a deal team or a sensitive sub-project needs to share files away from the rest of the team. The cost is more SharePoint sites to govern.

Shared channels are different again: they let you collaborate with users in other Microsoft 365 tenants. Useful for sustained partner relationships, not the default tool.

The five mistakes SMBs make

I have walked into enough Microsoft 365 tenants now to see the same five mistakes on repeat. They are all fixable, but they are easier to avoid than to clean up.

1. Treating OneDrive as the company file server

The classic version: the office manager has been at the company for 12 years, knows where everything is, and has built up a personal OneDrive with 800 GB of "shared" folders that the rest of the office gets to via a sync link. The office manager retires. The OneDrive is deleted 30 days later. The institutional knowledge is gone.

The fix is to move shared business data into SharePoint sites scoped by department or function. OneDrive stays for personal scratch.

2. Sharing OneDrive folders to the whole company

A close cousin of mistake #1. Someone needs to "share with everyone" and the easiest button is in OneDrive, so they click it. Now you have a folder that the whole company can see but that is owned by one user. When that user leaves, the share breaks. When external sharing rules change at the tenant level, this folder may suddenly leak outside the company.

The fix is to use a SharePoint site with the appropriate departmental membership. SharePoint shares are governed by the site, not by the individual. They survive ownership changes.

3. Creating a new Team for every customer

A 30-person professional services firm with 200 customers can end up with 200 Teams. Each Team is a separate SharePoint site, each one has its own permissions to maintain, each one has its own Files tab nobody is checking. The Teams list in the sidebar becomes useless. Governance breaks.

The fix is a SharePoint hub site for "Customers" with a document library or sub-site per customer, plus a smaller number of long-lived Teams for the persistent groups (the delivery team, the sales team, the leadership team). Active engagements get a Teams channel; durable customer records live in SharePoint.

4. "External sharing on" without governance

Most Microsoft 365 tenants ship with external sharing wide open. That is fine until somebody shares a customer list to a personal Gmail account, or until you turn on Copilot and realize that everything that was overshared in the past is now searchable by everyone with a license. Oversharing is the single largest pre-Copilot problem I see in 2026.

The fix is a tiered external sharing model: stricter at the tenant level, looser at the specific site level where partner collaboration actually happens. Run an oversharing report quarterly. Build a process to revoke stale external shares. See the Copilot business price-lock post for why this is urgent if you are deploying Copilot in the next 90 days.

5. No retention policy

Microsoft 365 has a feature called retention policies that lets you specify how long content is kept and when it is deleted. Most SMBs leave this at the default, which means deleted files are recoverable for 93 days and then gone forever. The flipside is that nothing is automatically held; if an employee deletes something they shouldn't have, you may not notice until the recovery window has closed.

The other flipside is the lawyer's nightmare: a dispute arises, discovery is requested, and the deleted files come back through eDiscovery anyway because they were never truly purged. Run retention deliberately, not by accident. Decide what you keep for how long, write it down, and apply it at the SharePoint site level so it covers OneDrive, Teams files, and SharePoint files in one go.

How Copilot interacts with all this

Microsoft 365 Copilot honors the same permission model as the rest of the platform. It can only see files the asking user can already access. There is no magic admin view; Copilot inherits whatever the user already had.

That sounds reassuring until you remember what the average tenant looks like. If the Finance SharePoint site was accidentally shared with "everyone except external users" three years ago and nobody noticed, Copilot will happily summarize the payroll spreadsheet for any user who asks "what does the leadership team get paid?" The oversharing that did not matter when nobody had a search bar in their face suddenly matters a lot when every user does.

The practical implication is that permissions hygiene becomes a prerequisite for Copilot deployment, not a nice-to-have. Run the SharePoint Advanced Management (SAM) oversharing report. Use restricted SharePoint search to limit Copilot's reach during initial rollout. Clean up stale external shares. Apply sensitivity labels to actually sensitive content. Identity hygiene matters too — see the identity hardening post for the prerequisites that have to be in place before you turn Copilot on.

Migrating off file servers, OneDrive Personal, or Dropbox to the right home

The most common migration project I get pulled into is "we have a Windows file server and we want it gone." The pattern that works is three steps, in this order:

Step 1: Inventory and classify

Walk the file server. Categorize content into four buckets:

• Active — used in the last 12 months, still relevant.
• Reference — not actively edited, but needed for lookups, compliance, or institutional memory.
• Archive — legally required to retain, but not consulted day to day.
• Junk — abandoned, duplicates, personal files that ended up on the share, screen recordings from 2017.

The junk bucket usually accounts for 30-60% of the file server. Do not migrate it. Delete it (or at least quarantine it).

Step 2: Map to OneDrive or SharePoint

Personal scratch and one-owner content goes to that user's OneDrive. Departmental and project content goes to SharePoint sites organized by function. Reference and archive content can go to a dedicated archive site with stricter retention and read-only access for most users. Build the SharePoint site structure before the migration, not as you go.

Step 3: Run the cutover

For straightforward file server shares, Microsoft 365 Migration Manager (free, built into the M365 admin center) handles up to several TB of data with reasonable permissions mapping. For complex permissions (NTFS ACLs that need to translate into SharePoint groups), legacy SharePoint farms, or large multi-site migrations, ShareGate is worth the licensing cost. Both support delta sync, so you can do an initial pass weeks before cutover, then a delta pass at the cutover weekend to catch recent changes.

Communicate the change. Train users on the new locations. Plan a cutover weekend where the file server goes read-only, the delta sync runs, and the file server is decommissioned on Monday. Cloud-first storage also reduces your exposure to the kind of on-prem vulnerabilities I covered in the SharePoint Server zero-day post; SharePoint Online does not need patching by you, and that alone is worth the migration in 2026.

A reference org chart for a 25-person business

Here is the concrete recommendation I give to a typical 25-person Central Coast professional services firm or property management company. Adjust the department names to fit your org.

Per-user storage:

• Every user gets a OneDrive for personal work, drafts, and one-owner files. Default permissions. Sharing limited to internal users by default. Quotas at the default 1 TB.

SharePoint sites (one per business function):

• HR — HR managers as owners, HR staff as members, leadership as visitors. External sharing off.
• Finance — CFO and controller as owners, finance team as members. External sharing off. Sensitivity labels applied to anything with employee compensation or banking detail.
• Operations — operations manager as owner, ops team as members, all staff as visitors for the procedures library.
• Sales — sales manager as owner, sales team as members, account managers in the Members group. External sharing on for the "Customer-Facing" document library, off for the rest of the site.
• Legal — general counsel (or outside counsel contact) as owner, leadership as members, no broad visitor access.
• Company-Wide — one site for the things everyone needs (employee handbook, IT policies, holiday schedule, the office wifi password). Everyone as visitors, HR and IT as members, IT as owner.

Teams:

• One Team per persistent collaboration group (Sales, Operations, Leadership) and one Team per active major project.
• Files tab is the active workspace for in-flight documents.
• When a project ends, surviving documents move into the appropriate department SharePoint site. The project Team is archived rather than deleted, so the chat history remains searchable for the inevitable "what did we agree to in February" question.

This structure scales from 15 users to 100 users without needing to be rebuilt. Past 100 users, you start looking at SharePoint hub sites, formal information architecture, and possibly a Microsoft 365 governance plan as a separate workstream.

What we are not recommending

Three patterns I see and steer clients away from:

• Personal OneDrive (the consumer product) for business files. The consumer OneDrive (signed in with a personal Microsoft account) is not part of your Microsoft 365 tenant. It has no admin visibility, no retention controls, no Conditional Access, and no DLP. Business files do not belong there, period.
• Document libraries for structured data. If you find yourself building a 30-column Excel sheet to track customer records, support tickets, or asset inventories, that is a sign you want Microsoft Lists, Dataverse, or a real database, not a SharePoint document library. Lists is included with Microsoft 365 and is the right tool for structured data the team needs to query.
• Free-for-all link sharing. Some clients respond to the "where does this file live" question by enabling "anyone with the link can access" sharing across the tenant. This is the same as putting the file on a publicly indexable web server. Search engines find these links. Phishing pages clone them. The default-correct sharing posture is "specific people" or "people in your organization." Reserve "anyone with the link" for the occasional file you would not mind seeing on the front page of the local paper.

Where this fits with the rest of the cluster

This post is the foundation piece for the Microsoft 365 storage cluster. It pairs with:

• The SharePoint Server zero-day post — evidence for why SharePoint Online (cloud) beats running on-prem SharePoint at SMB scale.
• The identity hardening post — the prerequisites that have to be in place before any of these permission patterns matter.
• The Copilot business price-lock post — why permissions hygiene needs to come before you turn Copilot on, not after.
• The backup and disaster recovery post — how to back up the SharePoint, OneDrive, and Teams content once it is in the right place, because Microsoft's native retention is not a backup.
• Ghosxt cloud services — the wrap-around managed service for Microsoft 365, including governance, migrations, and ongoing tuning.
• Managed IT services — the bigger umbrella, for the firms that want one provider handling identity, endpoints, storage, and security as a single program.
• Cybersecurity services — the detection and response layer that watches all three surfaces.

The honest read is that most SMB confusion about OneDrive, SharePoint, and Teams comes from treating them as three competing storage products rather than three views of the same SharePoint backend. Once the mental model lines up, the decision tree is straightforward. Personal scratch goes to OneDrive. Departmental and project content goes to SharePoint, accessed either via the SharePoint web UI or via the Teams Files tab depending on whether collaboration is happening right now. Permissions are governed by the SharePoint site, not by the app icon. Copilot will only see what the asking user can already see, so permissions hygiene becomes the project that unlocks everything else.

FAQs about OneDrive vs SharePoint vs Teams

If they all use SharePoint under the hood, why does it matter where I put a file?

Because the underlying SharePoint site determines who has access, what retention policies apply, what happens when the user leaves, and what Copilot can see. OneDrive is a SharePoint site owned by one user. A Teams channel's files live in a SharePoint site owned by a team. The storage layer is the same, but the governance container is different. If you put a customer contract in your personal OneDrive, it inherits your personal permissions and disappears when your account is offboarded. If you put it in the Sales SharePoint site, it inherits the Sales site's permissions and survives any single employee leaving.

What happens to a user's OneDrive when they leave the company?

By default, Microsoft 365 retains the departed user's OneDrive contents for 30 days after the account is deleted, then purges them. You can extend that retention window in the Microsoft 365 admin center, and you should as part of your offboarding playbook. The better practice is to transfer the OneDrive contents to the manager (or to the appropriate SharePoint site) before deleting the account. Many SMBs lose institutional knowledge here because nobody ever looked inside the departed user's OneDrive. This is the single biggest reason not to use OneDrive as a substitute for shared storage.

Can I share a OneDrive file the same way I share a SharePoint file?

Yes, the share dialog is the same and the link types (anyone, people in your organization, specific people) are the same. The difference is governance. A OneDrive share is granted by the file's owner without any site-level oversight. A SharePoint share inherits the site's external sharing policy and is visible to the site owner. For files that belong to the business rather than to one person, SharePoint sharing is auditable and survivable; OneDrive sharing is not.

Should we use Teams private channels or separate Teams?

Default to fewer Teams with more channels. Each new Team creates a separate SharePoint site, which adds governance overhead. Standard channels share the team's SharePoint site. Private channels each get their own dedicated SharePoint site, which is the right answer when a small subset needs to keep files away from the rest of the team (for example, a deal team within a sales Team). Shared channels are for cross-tenant collaboration with external partners. The wrong answer is creating a brand new Team every time two people want a private space, which is how a 25-person org ends up with 80 Teams and a sprawl problem.

Does Microsoft Copilot work the same way across OneDrive, SharePoint, and Teams?

Copilot honors Microsoft 365 permissions, which means it can only see files the asking user can already access. It works across all three surfaces. The catch is that any oversharing mistake you made before Copilot rolled out becomes a Copilot leak after rollout. If the Finance SharePoint site was accidentally shared with the whole company in 2024, Copilot will happily summarize the salary spreadsheet for any user who asks. Permissions hygiene is the single biggest pre-Copilot project. Run an oversharing report and clean it up before turning Copilot on.

How do we move existing files from a Windows file server to SharePoint?

Three steps: inventory and classify (what is active, what is archive, what is junk), map to OneDrive or SharePoint (personal scratch goes to OneDrive, departmental and project files go to SharePoint sites), then run the cutover with Microsoft 365 Migration Manager for straightforward shares or ShareGate for complex permission structures. The mistake to avoid is lifting and shifting the file server's folder hierarchy into one giant SharePoint document library. SharePoint is happier with multiple sites scoped by department or project, each with sensible permissions, than with one mega-library that recreates the old chaos.

Prefer to talk first? Email sales@ghosxt.com or call (831) 204-0501.