OneDrive vs SharePoint, and What Happens When Someone Leaves

The architectureOneDrive vs SharePoint: they are the same product underneath

Almost every OneDrive vs SharePoint comparison starts with personal storage against team collaboration. That is the right answer to the wrong question, because it does not explain any of the behavior an administrator actually runs into, and it does not help anybody decide where a business document belongs.

The useful starting point is that OneDrive for work or school is provisioned as a SharePoint site collection, one per licensed user, in the same cloud service. The evidence is in the administration, not in the marketing.

OneDrive retention is configured in the SharePoint admin center under My Site settings. The PowerShell cmdlet that sets it is Set-SPOTenant -OrphanedPersonalSitesRetentionPeriod. A deleted OneDrive goes to the site collection recycle bin, and Microsoft's documentation for OneDrive retention lives under the SharePoint documentation set.

That is why the limits and the tools match. Version history behaves identically in both, up to 50,000 major versions and 511 minor ones, and so do the co-authoring, sharing and compliance tools built on top.

Both cap an upload at 250 GB. Both cap a decoded file path at 400 characters including the file name. Both use the same sync client, deployed through the same endpoint management tooling, and the same 300,000 files guidance applies to a single OneDrive or a single SharePoint team library.

A list or library in either can hold 30 million items. In either, you lose control of permission inheritance on a container past 100,000 items, which is the point at which access has to be granted to groups of users rather than to individuals.

So the question is never which of the two SharePoint experiences is better. It is which site collection a document should live in, and that is a question about who owns it, which in turn decides the permissions that apply to it.

The document management layer only SharePoint uses

Microsoft's introduction to SharePoint and OneDrive describes both as cloud-based services that help organizations share and manage content, knowledge and applications. The storage engine is shared. The document management surface built on top of it is where the real difference sits.

A SharePoint Online document library adds metadata columns, content types and saved views to the documents in it, so a contract is filed by client and date rather than by whoever named the folder. A personal OneDrive has folders and file names.

Co-authoring behaves the same in both, so two people can work on the same Office file at the same time from either service. Collaboration on a document is not the thing that separates them.

Sharing is the same in both too, and that is the problem. A share link from a personal site grants the same access as one from a team library, but the permissions behind it belong to one account rather than to the business.

Microsoft's file collaboration guidance states that each SharePoint team site is part of a Microsoft 365 group, which is a single permissions group associated with several Microsoft 365 services. An intranet page, a Teams channel and a document library can all share that one group. A personal site has no equivalent of it.

Sensitivity labels, retention policies, data loss prevention and Content Search reach Office files in both services. The difference is that in SharePoint Online those controls attach to a library that outlives everybody who worked in it.

The ruleWhat Microsoft actually says about the split

The OneDrive service description is unusually direct, and it is worth quoting rather than paraphrasing. OneDrive storage is provisioned per user and designed for the needs of individual users.

Storage of data other than an individual's personal work files, including system backups and departmental or organizational level data, is not supported, and neither is assigning a per user license to a bot, a department, or another non-human entity.

Two practices fall over on that sentence. The shared department drive parked in one user's OneDrive is not a supported configuration, and no amount of governance policy makes it one.

Neither is the service account whose license exists so that a process has somewhere to write, which is a pattern that survives in a lot of estates precisely because it works until it does not.

The positive form of the same rule is simpler than the usual advice. If the document would still matter after the person who made it left, it belongs in SharePoint. Everything else is a draft.

That single test settles more cases than any feature comparison does, because the features on both sides are the same.

TeamsWhere Teams files actually live

Most documents reach SharePoint without anybody choosing SharePoint, because they were dropped into a Teams channel.

Creating a team creates a SharePoint site. Every standard channel in that team shares it, with one folder per channel in the default document library, and the Files tab is a view onto that folder. A private channel gets its own separate SharePoint site, and so does a shared channel.

Team membership lives in a Microsoft 365 group in Microsoft Entra ID, and team owners and members are placed in the site owners and members permission groups automatically, which is why managing access through Teams rather than through SharePoint is the recommended practice.

Two consequences matter for collaboration. Channel site permissions are inherited from the channel itself and cannot be managed in SharePoint, where they display read only, so an attempt to fix access on the site is an attempt in the wrong place.

And a shared channel cannot be shared with people outside the organization who are not channel members, which is a narrower rule than the sharing links available on an ordinary site.

None of this involves OneDrive. A file on a channel Files tab is in a SharePoint document library owned by the team, and it survives its author. Microsoft states it plainly in its own administrator introduction: files stored in Teams are stored in SharePoint sites.

The leaverWhat happens when someone leaves

This is the part that decides the whole thing, and it is the part the comparison articles skip.

When a user is deleted from Microsoft Entra ID, the cloud successor to the directory service most estates still run alongside it, a cleanup job marks their OneDrive for deletion. The default retention period is 30 days and it is configurable.

The user's manager is automatically given access, or a secondary owner if no manager is set, and receives an email saying the OneDrive will be deleted at the end of the period. Seven days before expiry a second email goes out.

At the end, the OneDrive moves to the site collection recycle bin, where it is kept for 93 days and can only be restored with PowerShell.

Four details in that sequence catch people out.

The retention timer starts on account deletion and nothing else. Blocking sign-in does not start it. Removing the license does not start it.

Estates that offboard by disabling accounts have OneDrives sitting there indefinitely, which is a different problem: unlicensed OneDrive accounts are automatically archived on their 93rd unlicensed day, and after twelve months in unpaid archive the data may be deleted regardless of retention policies, eDiscovery and holds.

The recycle bin is not indexed. SharePoint search does not reach it, which means an eDiscovery hold cannot locate documents there in order to hold it. If a legal matter arrives after the OneDrive has been recycled, the content is out of reach of the tooling built to find it.

Access delegation has to be configured. If it is disabled, or the user has no manager and no secondary owner is set, nobody is given access and nobody is warned. The files expire quietly, and no governance report shows it happening.

Retention policies win. Microsoft 365 retention labels and policies take precedence over the standard deletion process, in both directions: content can be deleted before 30 days or kept for much longer than the OneDrive retention period.

A document in a SharePoint library goes through none of this. The SharePoint site belongs to the organization, the departure of one of its users changes nothing, and access is a membership question rather than a survival question.

StorageStorage, and the number that surprises people

The surprise is the second column. SharePoint cloud storage is pooled and it is not large by default: a hundred user tenant has 1 TB plus 1 TB, so 2 TB for every team site, every intranet page and every Teams channel in the organization. Each individual user meanwhile has their own 1 TB that does not touch that pool.

That asymmetry quietly pushes a business the wrong way, and no governance policy survives contact with it. Departmental documents end up in OneDrive because the per user allocation is the one with room in it, which is exactly the configuration Microsoft says is unsupported.

Running above the tenant limit puts the environment at risk of read-only mode, so the right answer is to buy cloud storage rather than to hide data in personal sites.

Two more figures worth knowing before a migration: moving or copying across sites is limited to 100 GB and 30,000 files per operation, and a cross-geo move caps a single file at 15 GB. A department drive rescued out of somebody's OneDrive rarely fits in one pass.

DecidingHow to decide, in one question

Ask who the file belongs to when the person who made it is gone.

It belongs to the organization. A policy, a contract, a project plan, a client folder, anything with a retention obligation, anything a second person needs to find without asking.

SharePoint, in a document library on the site that owns the work, with permissions set on the library rather than on the file. This is the business records case, and document management features are the reason it goes there.

It belongs to the person. A draft, a scratch file, a personal copy, notes, a spreadsheet somebody is still thinking in. OneDrive, and you can still share it with other users from there while it is a draft.

It belongs to a process. A backup target, an export folder, tools writing files on a schedule. Neither, in the sense that neither is designed for it, and OneDrive is explicitly not supported for it. This is the case that most often ends badly, because the license it depends on is the first thing an offboarding process removes.

The failure to avoid is the middle state that lasts for years: a file that started as a draft in OneDrive, became the department's copy of record, and was never moved, because nothing in the product ever prompts that move.

PitfallsWhere estates go wrong

Sharing out of OneDrive instead of moving. A share link to a personal site works perfectly and survives right up until the account is deleted. Giving other people access to documents is not a substitute for owning them, and the permissions on a shared file die with the site that holds it.

Offboarding by disabling instead of deleting. It feels safer, it defers every decision, and it is the single most common finding when a provider reviews an offboarding process. It also means the OneDrive is never cleaned up, gets archived on its 93rd unlicensed day, and can be deleted after twelve months regardless of any hold you have placed on it.

Assuming a backup covers it. Native retention is not backup. The 93 day recycle bin is a grace period, it is not indexed, and restoring from it needs PowerShell and someone who knows the site URL. If OneDrive content matters, it needs a real backup rule like anything else.

Migrating without checking path length. The 400 character decoded path limit bites hardest when files move from a shallow personal folder into a deeply nested SharePoint library. Check before, not during.

Letting the sync client carry a library it should not. The guidance is no more than 300,000 synced files in a single OneDrive or SharePoint team library, and the same ceiling applies across everything one user syncs. Past it, sync problems stop being reproducible.

ComparisonThe two side by side, on what actually differs

Two rows carry the decision. The second says what happens when somebody leaves, and the seventh says which collaboration Microsoft actually supports. Everything else in the table is the same product wearing a different name.

FAQFrequently asked questions

Keep readingRelated concepts

Read next · Directory and identity Active Directory Explained Where the account deletion that starts the whole 123 day sequence actually happens. Open this next15 min

• Backup · 13 min The 3-2-1 Backup Rule, and What Ransomware Did to It Native retention is a grace period, not a backup, and the recycle bin is not searchable while it holds your data.
• Backup · 12 min Immutable Backups, and the Setting That Decides Whether They Work The property retention does not give you, and the reason a 93 day recycle bin is not an answer to ransomware.
• Managed IT · 10 min Google Workspace vs Microsoft 365, and What Actually Decides It Where the files then go.
• Security operations · 10 min Data Classification, and Why Every Label Needs a Rule A data classification scheme with example levels, and where each level of data may be stored.