Microsoft 365 information architecture
SharePoint vs OneDrive vs Teams file storage: where each file should actually live
SharePoint vs OneDrive vs Teams file storage is a placement question, not a product comparison, and it only arrives once you already own Microsoft 365 and the files are already somewhere. The short version is that two of those three are storage and one is not: SharePoint holds content the organization owns, OneDrive holds content one person owns and has not finished, and Teams is a window onto both. This page is the decision table and the lifecycle consequence — not a migration runbook and not an intranet pitch. If your files are still on a server, start with migrating a file server to SharePoint; if you want the sites and navigation designed and built, that is SharePoint consulting. If you are still choosing between Microsoft and Google, that is a different question, covered in SharePoint vs Google Drive for business. What follows assumes the tenant exists and the question is where each file goes from here.
Teams is a client, not a storage location
Almost every confused tenant we look at starts from the same wrong premise: that a file “is in Teams”. Nothing is in Teams. When you drop a file on a channel's Files tab you are writing to a SharePoint document library, and when you drag one into a chat you are writing to your own OneDrive and handing out a link. Microsoft is unambiguous about this. Its eDiscovery guidance on where Teams content is stored (opens in new tab) states that files shared in a channel are stored in the SharePoint site associated with the team, that files shared in a 1:1 chat are stored in the OneDrive account of the person who shared the file, and that group chats behave the same way.
That single fact reframes the whole question. You are not choosing between three storage products; you are choosing between two, and deciding how much of your content should be created through a chat window that quietly picks the wrong one for you. It also explains the most common symptom we get called about — a file that everyone remembers seeing but nobody can find — because a chat attachment lives in one colleague's personal drive and is reachable only through a link buried in a conversation.
The structure behind a team is more complicated than it looks
Microsoft's documentation on how Teams and SharePoint are connected (opens in new tab) sets out the part most people are surprised by: all standard channels in a team share one SharePoint site, with a folder per channel, but every private channel and every shared channel gets a separate SharePoint site of its own. Those channel sites cannot be shared separately, and their permissions are inherited from the channel and shown read-only in SharePoint.
The practical consequence is a counting problem. A team with a handful of private channels is not one site, it is several, each with its own membership, its own storage and its own lifecycle — and none of them appear where an administrator would naturally look for them. Multiply that by however many teams your organization has created since 2020 and you have the sprawl that Microsoft Teams governance consulting services exist to contain: naming, creation rights, ownership and archival rules set at the point teams are made rather than reconstructed afterwards.
Where a file actually lands
This table maps the action a user takes to the storage location it really writes to, and to the thing that goes wrong later. Every storage location in the first two columns is drawn from Microsoft's own documentation, cited above.
| What the user does | Where the file really goes | Who can reach it | What bites later |
|---|---|---|---|
| Uploads to a standard channel's Files tab | The team's parent SharePoint site, in a folder named after the channel | Every team owner and member | Very little — this is usually the right answer |
| Uploads to a private channel | A separate SharePoint site created for that channel | Only the private channel's owners and members | An invisible site with its own membership that no one audits |
| Uploads to a shared channel | A separate SharePoint site created for that channel | Channel members, including people outside the team | External participation governed at the channel, not the team |
| Drops a file into a 1:1 or group chat | The sender's OneDrive | Whoever holds the sharing link the chat created | Ownership follows the sender out of the company |
| Records a meeting | The OneDrive of the user who recorded it | Recipients of the automatically generated link | Recordings of company business held in a personal drive |
| Saves to OneDrive “My files” | That person's OneDrive | Only them, until they share it | Correct for drafts; a liability for anything finished |
| Saves to a SharePoint document library | The site that owns the content | Whoever the site's membership says | Nothing, if the site was designed for that content |
The rule that settles most files in one sentence
If more than one person needs it, it does not belong in OneDrive. That is the whole rule, and it is deliberately blunt because a rule people can repeat is worth more than a policy document nobody opens. OneDrive is where work in progress lives while it is still one person's problem: drafts, scratch analysis, the version you are not ready to show anyone. The moment a colleague has to ask you for a file, the file is in the wrong place — not because sharing is broken, but because access now depends on you being available, employed and willing.
Applied honestly, that rule moves more content than people expect. Here is how the usual cases resolve.
| What the file sounds like | Where it belongs | Why |
|---|---|---|
| “A draft I am still arguing with myself about” | OneDrive | One owner, no audience, no retention question yet |
| “The signed contract for a live customer” | SharePoint | The organization owns it and must be able to find it without the author |
| “The deck this project team is editing together” | SharePoint, via the team's channel | Membership is the access model; the channel folder is the library |
| “A file I sent one colleague in a chat” | Depends — ask if it is finished | If it is a deliverable it belongs in a library; a chat link is a loan, not a home |
| “Something only three of us should see” | SharePoint, in a site scoped to those three | A private site is a permission model; a personal drive is an accident |
| “Records with structured fields we report on” | A list or a table, not a library | This is a data question — see the Dataverse and SharePoint lists comparison |
| “Files an outside party needs” | SharePoint, with guest access scoped to one site | External access should be revocable in one place, not link by link |
The last row but one is worth separating out, because it is the most common category error we see. If what you actually have is rows with fields — requests, assets, inspections, approvals — then the answer is not a document library at all, and the choice is between a list and a relational table. That is covered in Dataverse vs SharePoint lists for Power Apps, which is a different decision from this one and worth reading before anyone builds a folder structure to hold what should have been records.
The lifecycle problem nobody plans for
Placement mistakes are cheap on the day they are made and expensive two years later, and the mechanism is always the same: a file starts in OneDrive, becomes important, and never moves. Three consequences follow, and they compound.
Permission sprawl. A file that stays in a personal drive is shared outward one link at a time. Each link is a separate grant nobody tracks, and SharePoint's own ceilings assume you will not do this at scale — Microsoft's published SharePoint limits (opens in new tab) put the supported number of unique permission scopes in a list or library at 50,000 while recommending a general limit of 5,000. Membership-based access in a site does not accumulate that way; link-by-link sharing does.
Departures. When an account is deleted, the clock starts on the personal drive attached to it. Microsoft's OneDrive retention and deletion guidance (opens in new tab) sets the default retention period at 30 days, adjustable in the SharePoint admin center, gives the departing user's manager automatic access by default, and then moves the drive to the site collection recycle bin for 93 days. That is a reasonable safety net for someone's drafts. It is a poor filing system for the only copy of a customer contract, and offboarding is when most companies discover which of the two they have been running.
Copilot. An assistant that answers from whatever the signed-in person can already open turns quiet oversharing into a search result. Microsoft describes Copilot as having access scoped by user permissions (opens in new tab) — which is exactly the problem, because the permissions were never the considered part. Content that has drifted through personal drives and chat links is the content nobody has audited. Fixing placement before enablement is most of the work described in our guide to Copilot data governance, and where the concern is broader than content — admin roles, MFA, guest access, audit logging — a Microsoft 365 tenant security assessment is the wider read.
What the storage meter actually counts
Storage is rarely the reason to move a file, but it is worth knowing which pool you are spending. The same SharePoint limits page gives an organization's total as 1 TB plus 10 GB per licence purchased, caps a single site at 25 TB, sets a 250 GB upload limit on an individual file, and states in a footnote that the tenant total does not include the OneDrive created for each licensed user. So a channel upload draws on the shared pool, a chat attachment draws on the sender's own drive, and the two are budgeted separately.
The number worth acting on is a different one: Microsoft recommends syncing no more than 300,000 files in a single OneDrive or team site library. Tenants that hit sync complaints have usually built one enormous library rather than several purposeful ones, which is a structure problem wearing a performance costume. Reclaiming space, trimming version history and untangling permissions after go-live is ongoing work rather than a project, and we scope it as SharePoint support and maintenance.
Turning a decision into a tenant people can use
Reading a table is the easy part. Making it stick takes three things, in this order. Decide what owns what: a short list of sites mapped to the way the business is actually organized, so there is an obvious home for every category of document before anyone asks. Write the rule down in one sentence and put it where people work, because the version staff can repeat is the version that gets followed. Then move the content that breaks it — and only that content, because a wholesale reorganization of files nobody opens is how these projects die.
We scope that as fixed-fee work with no rate card: you approve a defined piece of work and a price before anything starts, it is delivered by senior US-based engineers in a typical two to four weeks, and 30 days of hypercare follow go-live. If the content is still on a file server, the placement decision belongs in the design step of a file server to SharePoint migration rather than after it, because moving folders first and deciding later just relocates the mess. If the sites, navigation and permission model need designing in the first place, that is fixed-fee SharePoint consulting. Tell us where your files are today and we will tell you which ones are in the wrong place.
FAQ
File placement questions, answered plainly
No. Teams is a client over other services. Microsoft documents that files shared in a standard channel are stored in the SharePoint site associated with the team, that each private and shared channel gets its own SharePoint site, and that files shared in a chat land in the OneDrive of the person who shared them.
OneDrive is for work in progress that belongs to one person: drafts, notes, a spreadsheet nobody else needs yet. The moment a second person has to find it without asking you, it belongs in a SharePoint library the team owns, where membership rather than a sharing link controls access.
Microsoft's OneDrive retention and deletion guidance says the default retention period for a deleted user's OneDrive is 30 days, adjustable in the SharePoint admin center, and that the manager is automatically given access by default. After that window the OneDrive moves to the site collection recycle bin for 93 days.
They consume the sender's OneDrive, not the organization's SharePoint pool. Microsoft's SharePoint limits page gives total storage as 1 TB plus 10 GB per licence purchased and notes that this figure does not include the OneDrive created for each licensed user. The practical cost of chat files is governance, not gigabytes.
Start with placement rules, not a tool. Decide which sites own which content, agree the rule that anything more than one person needs leaves OneDrive, then move the files that break it. We scope that cleanup as a fixed-fee project with no rate card, and the rules are written down so the tidy state survives.
It removes a large share of the risk. Microsoft states that Copilot access is scoped by user permissions, so anything a person can already open is answerable. Files sitting in personal OneDrive with stale sharing links are exactly the content nobody audits, which is why placement is a governance decision.
Related reading
Decide placement, then fix the tenant around it
SharePoint Consulting
The sites, libraries, navigation and permission model designed and built, so there is an obvious home for every category of document.
Teams Governance
Naming, creation rights, ownership and archival rules set where teams are made, so the sites behind them stop multiplying.
SharePoint Support & Maintenance
Permission audits, storage and version cleanup, search fixes and offboarding leftovers, scoped as fixed-fee work after go-live.
Book a free consultation
Get more from the Microsoft tools you already pay for
Tell us what you’re trying to fix — a report, an approval process, an intranet, a Copilot rollout. We scope it as a fixed-fee project, you approve, and a senior engineer delivers in 2–4 weeks.
- Fixed-fee scope agreed before any work starts
- Senior, US-based Microsoft engineers — no handoffs
- Typical 2–4 week delivery
- 30 days of post-delivery hypercare included
The fastest way to reach us is the form — tell us the task and we’ll reply within one business day.