SharePoint vs OneDrive vs Teams: when to use each

Every Australian SMB on Microsoft 365 has the same three tools sitting in their tenant. SharePoint, OneDrive, and Teams. Each one stores files. Each one shares files. Each one looks slightly different in the user interface. Nobody at Microsoft has ever explained clearly which one to use for what, and the result is the same in almost every business we audit. Documents scattered across all three with no consistent logic, duplicated everywhere, and a governance posture that quietly fails the next regulatory audit.

This is one of the most consequential decisions in your Microsoft 365 deployment, and almost nobody makes it intentionally. Let us walk through what each tool is genuinely for, where the boundaries should sit, and how to clean up the mess if you are already living in it.

What each tool was actually designed to do

OneDrive is personal cloud storage tied to an individual user account. Microsoft’s intent was for it to replace the My Documents folder on a Windows PC. Files belong to one person. When that person leaves the business, the files leave with them unless somebody intervenes. The sharing model is built around “I am sharing my file with you”, with the file ownership staying with the originating user.

SharePoint is organisational document storage tied to sites, libraries, and groups. Microsoft’s intent was for it to replace the shared network drive. Files belong to a team, a project, a department, or the organisation itself. When a person leaves, the files stay with the team. The sharing model is built around “this is a shared space we both work in”, with the access tied to membership rather than individual permissions.

Teams is a collaboration interface that sits on top of SharePoint for files, plus chat, meetings, and channels. The files in a Teams channel are not stored “in Teams”. They are stored in the SharePoint site that backs the Team, and Teams just gives you a different window into them. The sharing model is conversational, with files in context of the discussion they belong to.

The critical fact most users do not understand: Teams files are SharePoint files. There is no separate Teams storage. Every Team has a hidden SharePoint site behind it, and the files tab in a Teams channel is literally a SharePoint document library being displayed inside the Teams interface. This is the source of half the confusion in most M365 deployments.

The right tool for each scenario

The honest decision tree is simpler than the marketing makes it sound.

If the file is genuinely personal to one user and would not need to be accessed after they leave, it goes in OneDrive. Drafts, personal notes, work-in-progress that has not been shared yet, individual templates. The test is whether anyone else in the business would need this file in 18 months. If the answer is no, it is OneDrive material.

If the file belongs to a team, project, department, or the organisation as a whole, it goes in SharePoint. Active project files, departmental policies, shared templates, client matters, finance records, vendor contracts. The test is whether the file should persist when individual people leave. If yes, it is SharePoint material.

If the file is part of an ongoing collaboration with a defined group of people who are also chatting and meeting about the work, it goes in Teams (which means it ends up in SharePoint under the hood). Active project workspaces, departmental hubs where conversation and files are intertwined, cross-functional initiatives.

The pattern that breaks everything is using OneDrive for things that belong in SharePoint. We see this in 80 per cent of Australian SMB audits. A user creates a document in their OneDrive, shares it with colleagues, and the working version of an organisational asset is now sitting in one person’s personal storage. When that person leaves, the document survives only by accident.

The Teams files problem

Teams creates a specific failure mode that deserves its own discussion. Every time someone creates a Team, a new SharePoint site is created behind it. Teams proliferate, SharePoint sites proliferate, and within a couple of years a typical Australian SMB has 200+ SharePoint sites, most of them barely used, all of them counting against storage quotas and audit scope.

The right governance approach is to treat Team creation as a deliberate decision rather than a self-service action. Every new Team should have a defined purpose, a defined owner, and a defined lifecycle. Teams that have not been used for 90 days should be reviewed for archival. Teams that have not been used for 180 days should be archived by default unless the owner objects.

This is unpopular with users because it adds friction. It is also the only thing that keeps the environment manageable at any scale. Without it, governance, security, and audit posture all degrade slowly until something forces a clean-up that is significantly more painful than the ongoing discipline would have been.

The migration most businesses need to do

If your business is more than two years into Microsoft 365 and has not done a deliberate cleanup, the migration is overdue. The typical pattern looks like this.

The timeline varies with fleet size. A 50-person business typically completes this in eight to twelve weeks. A 200-person business runs four to six months. The ongoing benefit, lower storage costs, cleaner audit scope, faster e-discovery if litigation hits, justifies the investment for most businesses inside the first year.

Where this connects to security and compliance

Files in the wrong location are a security problem before they are a productivity problem. Three concrete ways this matters.

Data Loss Prevention policies in Microsoft 365 work better when files are stored in the locations that match the policies. A finance policy designed for the Finance SharePoint site cannot protect financial data sitting in someone’s personal OneDrive. As we covered in our Microsoft 365 Security Best Practices guide, getting the storage right is foundational to the security layer working at all.

The Notifiable Data Breach scheme requires you to identify what was exposed in any incident. When content is scattered across personal OneDrives, shared Teams, and SharePoint sites with inconsistent permissions, the post-incident forensic effort multiplies. Knowing what you hold and where you hold it is the difference between a contained 72-hour notification and a panicked extension request.

The federal Privacy Act amendments coming into effect in December 2026 tighten requirements around automated decisions and data handling. AI assistants like Copilot read across the tenant. Whatever Copilot can see, the audit can see. Files that should not be accessible to the AI ending up in locations Copilot reads is a Privacy Act exposure that did not exist three years ago.

What we recommend

For Australian SMBs running Microsoft 365 with no deliberate file governance, the audit is the right first step. You almost certainly have content in the wrong places, and you cannot fix what you have not measured.

For businesses with active Teams sprawl, the lifecycle policy and archival discipline matters more than the SharePoint structure work. Stop the bleeding before you treat the wound.

For businesses preparing for ISO 27001, Essential Eight ML2, SMB1001, or industry-specific compliance, the file governance work is in scope whether you address it deliberately or wait for the auditor to flag it. Better to lead than be led.

For businesses already using Copilot or planning to enable it, the governance work moves from “nice to have” to “blocking”. Copilot reading content with weak permissions structures is the single biggest unforced error we see in Australian SMB AI deployments.