OneDrive, Teams, or SharePoint? Designing Microsoft 365 Records Management That Compliance Actually Trusts

Most organizations are already deep into Microsoft 365. Teams is how people meet, OneDrive replaced home drives, and SharePoint quietly hosts every file behind the scenes.

What usually did not migrate cleanly is records management.

Network-drive assumptions are still running the show: final documents are hidden in personal folders, retention is handled by “delete nothing” culture, and records are whatever a department remembers to put in its archive share.

Meanwhile, Microsoft Purview is sitting there with powerful retention controls over OneDrive, Teams, SharePoint, and Exchange — but nobody is quite sure how to use it without breaking collaboration or flooding compliance with work.

In this post, I want to turn the familiar model of OneDrive = me, Teams = us, SharePoint = everyone into a practical records management design that compliance actually trusts. We will connect that model to Microsoft Purview retention labels and policies, SharePoint site and library structure, Teams channels and chat, and the real-world impact on Copilot and eDiscovery.

If you are an IT director, records manager, compliance lead, or Microsoft 365 admin being asked “where do official records live now?” — this is written for you.

TL;DR

• Use the model: OneDrive = me (drafts), Teams = us (collaboration), SharePoint = everyone (records). Then design where each record type must live.
• Configure Microsoft Purview retention labels and policies to match those record locations, not just random sites. Treat retention as a control, not as backup.
• Create dedicated SharePoint record libraries with metadata, permissions, and default retention labels for key record types (contracts, HR files, policies, projects).
• Retrofit your tenant with a phased approach: discover existing content, pilot record-bearing sites and teams, and only then scale. This reduces audit pain, storage growth, and bad Copilot answers.

Table of Contents

• Why Records Management Breaks After Migration
• Decision Framework: OneDrive = Me, Teams = Us, SharePoint = Everyone
• Real-World Scenario: Network Drive Migration and a Painful Audit
• Common Mistakes and Risks
• Designing a Practical Records Management Model
• Technical Recommendations: Purview, SharePoint, Teams, and OneDrive
• Retrofitting Records Management in an Existing Tenant
• Business Impact
• Practical Checklist
• Final Thoughts

Why Records Management Breaks After Migration

When organizations move from network drives to Microsoft 365, the migration plan usually focuses on:

• moving files efficiently
• preserving permissions
• enabling Teams and SharePoint for day‑to‑day work

What rarely gets the same attention is the question:

Where do our official records live now, and how long do we keep them?

Several things go wrong in real environments:

• Old mental models persist. Users still think in terms of G: drive, department shares, and personal folders. They carry those habits into OneDrive, Teams, and random SharePoint sites.
• Purview is treated as a future project. Retention and records settings are “for later”, after migration, but “later” never comes.
• No one owns the records model for Microsoft 365. IT owns the platform, compliance owns the rules, business units own the content. Nobody owns the end‑to‑end mapping.
• Collaboration wins over structure. Teams gets created fast, files are shared informally, and record locations become an afterthought.

This misalignment used to show up mainly as messy file shares. In Microsoft 365, it now shows up as:

• critical files stuck in personal OneDrive accounts
• decisions and approvals trapped in Teams chats and private channels
• years of unclassified content in SharePoint sites with no retention structure
• Copilot surfacing outdated or non‑authoritative documents as suggested answers

If you do not address records management in Microsoft 365, you are essentially building collaboration on top of governance debt.

Decision Framework: OneDrive = Me, Teams = Us, SharePoint = Everyone

You have probably seen the simple adoption slogan:

• OneDrive = me
• Teams = us
• SharePoint = everyone

It is a great starting point, but we need to translate it into a records vs working documents decision framework.

Step 1: Distinguish working documents vs records

A simple decision model you can use with business owners:

• Working documents
  • drafts, brainstorming, notes, early versions
  • content that may change frequently
  • usually owned by individuals or small teams
• Records
  • final, approved versions that support obligations, rights, or decisions
  • must be retained for a defined period
  • should be discoverable and trusted by compliance, legal, and auditors

Ask two questions:

1. Will this document be needed to prove something later? (rights, obligations, decisions, compliance)
2. Is this the approved version that others should rely on?

If the answer to both is yes, you are dealing with a record, not just a working document.

Step 2: Map to OneDrive, Teams, or SharePoint

Now apply the model:

• OneDrive (me)

  • Best for working drafts, personal notes, early versions.
  • Bad for records: OneDrive is tied to a user account and lifecycle. When people leave, records disappear unless you do special handling.

• Teams (us)

  • Best for collaborative work in progress: shared drafts, team discussions, meeting notes.
  • Good for short‑term collaboration history, but not ideal as the system of record for long‑term documents.

• SharePoint (everyone)

  • Best for official, shared records: contracts, HR files, policies, project deliverables.
  • Has the metadata, permissions, retention, and search capabilities to be a reliable record repository.

A practical pattern:

• Working draft of a customer proposal: OneDrive or Teams channel folder.
• Final, approved proposal sent to the customer: stored in a SharePoint “Customer Contracts” or “Engagement Records” library with a retention label.
• Meeting chat where the proposal was discussed: kept under Teams chat retention suitable for collaboration, but not treated as the official record.

Good vs bad examples

Bad pattern

• Sales manager keeps signed contracts only in their OneDrive.
• Project decisions are recorded in long Teams chats with no record of the final decision in SharePoint.
• HR stores disciplinary letters in a private Teams channel without any retention labels.

Better pattern

• All signed customer contracts are stored in a SharePoint “Contracts” site, with:
  • a “Customer Contracts” library
  • metadata for customer, effective date, contract type
  • a default Purview retention label, e.g. Contract-Official-Record-7Y
• Teams is used to collaborate on drafts; the final signed PDF is moved to the SharePoint library.
• HR uses a dedicated “HR Records” SharePoint site with restricted permissions and clear retention labels.

If you want more background on how to pick OneDrive, Teams, or SharePoint for migrated content, see the post on network drive migration to OneDrive, Teams, and SharePoint.

Real-World Scenario: Network Drive Migration and a Painful Audit

Let me walk through a scenario that looks very close to what I see in real projects.

The migration

A mid‑size manufacturing company migrates its on‑premises file shares to Microsoft 365. The goals:

• retire aging file servers
• give users Teams and modern SharePoint
• keep downtime and disruption low

The migration strategy is typical:

• Department shares become SharePoint team sites.
• User home drives move into OneDrive.
• Shared project folders become Teams with associated SharePoint sites.

Records management discussions happen briefly:

• Legal says: “We need to keep contracts at least seven years.”
• HR says: “Personnel files have retention rules too.”
• Compliance says: “We need to be able to respond to audits and investigations.”

Everyone agrees this is important, but the migration timeline is tight. The decision: “We will move everything first, and set up retention later.”

What actually happens

Three months after migration:

• Sales teams love Teams and upload everything into their channels.
• Finance continues to use mapped drives pointing to SharePoint sites, with little structure change.
• HR uploads confidential files into a single SharePoint library with broad permissions, planning to “lock it down” later.
• Some managers keep critical documents in OneDrive because “it’s faster”.

No Purview retention labels are in place. No record libraries are clearly defined.

The audit request

A regulatory audit arrives, asking for:

• all customer contracts with a certain distributor over the last five years
• related change orders and approvals
• policies and procedure documents in place during specific periods

Legal issues a legal hold and asks IT to collect the material.

Problems surface quickly:

• Some contracts are in OneDrive of a sales rep who left last year. His account is disabled; content was not moved.
• Other contracts are in random Teams channel folders, with no consistent naming.
• Change orders exist only as email attachments in Exchange and as PDFs saved somewhere in SharePoint.
• The policy documents have multiple versions: intranet copies, team site copies, and drafts. Nobody is sure which is authoritative.

IT runs broad eDiscovery queries. The result:

• Thousands of documents that might be relevant.
• Multiple contradictory versions of key policies.
• Missing records for some years because content sat in OneDrive and was deleted with the account.

Compliance has to manually review and reconcile documents, at great cost and stress. The audit closes with findings about incomplete records and unclear retention controls.

Now add Copilot

The organization enables Microsoft 365 Copilot. Users start asking:

What is our current travel expense policy?

Copilot finds:

• one draft policy in a legacy SharePoint site
• one outdated copy in a project team site
• one semi‑final version in OneDrive

Since none of these are clearly labeled as the official record, Copilot cannot reliably surface the correct answer. Governance debt has now become an AI answer problem.

This scenario is exactly why it is not enough to “move the files”. You need a records model across OneDrive, Teams, and SharePoint, supported by Purview.

Common Mistakes and Risks

Here are the mistakes I see most often when organizations try to use Microsoft 365 for records without a clear design.

1. Treating OneDrive as a record repository
   Users keep signed documents, approvals, and critical files in OneDrive because it is convenient. When they leave, accounts are cleaned up and records are lost or hard to find.

2. Ignoring Teams chat and channel messages
   Important decisions and approvals happen in Teams chats. Without appropriate retention or a process to capture decisions into SharePoint, you risk losing key evidence or keeping too much irrelevant conversation.

3. Assuming that “keep everything” equals compliance
   Some organizations avoid deletion entirely. That looks safer but causes eDiscovery overload, storage growth, and more noise for Copilot and search.

4. Using Purview retention as backup
   Retention settings are meant for lifecycle and compliance, not as a replacement for backup or restore. Confusing these leads to wrong expectations about recovery.

5. Letting every team and site define its own record rules
   Without a central model, each department decides where to store records. Compliance cannot rely on consistent locations or retention, making audits harder.

6. Locking records too tightly and hurting collaboration
   Turning every final document into a non‑editable record immediately can push users to avoid the record libraries entirely. They keep working copies elsewhere, and the record library becomes a seldom‑used archive.

7. No workspace lifecycle for record‑bearing teams and sites
   Teams and SharePoint sites that contain records are never reviewed or closed. Their content becomes stale, permissions drift, and nobody knows who owns them.

8. Over‑relying on sensitivity labels alone
   Sensitivity labels are important for protection and access, but they do not define retention and record status. Thinking they “solve records” leads to gaps.

Designing a Practical Records Management Model

You do not need a perfect enterprise‑wide model on day one. You need a clear, practical design for the next 3–6 months that you can pilot and refine.

Here is a pragmatic approach I use in consulting engagements.

1. Define official record locations by content type

Start with 5–10 key record types. For example:

• Customer contracts
• HR personnel records
• Policies and procedures
• Financial statements
• Project deliverables (final reports, handover packs)

For each, decide:

• Primary record location (usually a dedicated SharePoint site/library)
• Who owns it (business owner, records manager)
• Who can contribute (team members, limited editors)
• Retention requirements (e.g., 7 years after contract end)

This is where SharePoint should shine. If you need help designing those libraries, the post on SharePoint document library design before Copilot goes into detail.

2. Establish rules for OneDrive, Teams, and SharePoint

Make simple, enforceable rules:

• OneDrive

  • Only for drafts, personal work in progress, and personal notes.
  • Records must not live only in OneDrive.
  • When a document becomes a record, it is moved or copied to the official SharePoint record library.

• Teams

  • Use channel files for collaborative work.
  • For each record type, define the step where the file moves from Teams to SharePoint record library.
  • Capture key decisions from chat into SharePoint decision logs when needed.

• SharePoint

  • Official record locations with retention labels.
  • Clear metadata, versioning, and access control.
  • Visible to compliance and legal for discovery.

3. Decide who can declare records and manage retention

Governance considerations:

• Record declaration

  • In some organizations, any site owner can apply a record label.
  • In more regulated environments, only records coordinators or compliance admins can declare official records.

• Retention configuration

  • Microsoft Purview retention policies and labels should be managed by a small governance group (IT + compliance), not by every site owner.
  • Changing retention periods should require documented approval.

This reduces the risk of someone casually changing retention to “never delete” or “delete in 30 days” for critical records.

4. Align retention labels with libraries and channels

Once locations and ownership are clear, you can align Purview labels:

• Create labels like:
  • Contract-Official-Record-7Y
  • HR-Official-Record-10Y
  • Policy-Published-Record-5Y
• Configure SharePoint libraries to use default retention labels for records.
• Use label policies to publish the right labels to the right users and locations.
• For Teams:
  • apply message retention policies that match legal and business requirements
  • keep chats long enough to support investigations, but not forever without reason

5. Connect decisions to Copilot and search

When you have clear record locations:

• Copilot can prioritize content from record libraries as more authoritative.
• Microsoft Search can rely on metadata and labels to surface better results.

If you have not looked at AI governance yet, the post on Copilot adoption fails when SharePoint content is not ready explains why content structure and records matter before you turn on AI.

Technical Recommendations: Purview, SharePoint, Teams, and OneDrive

Now let’s get specific about Microsoft Purview and how to configure it across SharePoint, OneDrive, and Teams.

1. Retention vs backup

First, a critical distinction:

• Retention (Purview labels and policies) is about how long content must be kept and when it can be disposed of in a compliant way.
• Backup and restore is about being able to recover content after accidental deletion, corruption, or disaster.

Purview does not replace backup. Retention can prevent deletion or delay it, but it is not a snapshot or restore tool. Design both.

2. Retention labels and policies

In Microsoft Purview:

• Retention labels

  • define the retention period
  • specify whether content is kept, deleted, or kept and then deleted
  • can mark content as a record (more immutable, restricted edit/delete)

• Retention label policies

  • publish labels to locations (SharePoint, OneDrive, Exchange, Teams)
  • can auto‑apply labels based on conditions (keywords, sensitive info, etc.)

• Retention policies

  • apply rules at the container level (entire SharePoint site, OneDrive accounts, Teams messages)
  • useful for broad rules like “keep all Teams chat messages for three years”

For record management, the safer approach is usually:

• Use labels for record libraries and specific document types.
• Use container policies for baseline retention (e.g., OneDrive content kept for X years after deletion).

3. Example: configuring Purview for contracts and HR records

A practical pattern:

1. In Purview, create labels:

   • Contract-Official-Record-7Y → 7 years from contract end date, keep and then delete.
   • HR-Official-Record-10Y → 10 years from termination date, keep and then delete.

2. Create label policies:

   • Publish contract label to:
     • SharePoint sites like Contracts, Sales-Records.
     • Relevant Teams where drafts are worked, so users can label the final files before moving.
   • Publish HR label to:
     • HR Records SharePoint site.

3. In SharePoint record libraries:

   • Set default retention label to the appropriate record label.
   • Require key metadata (customer, employee ID, effective date) that supports retention triggers and discovery.
   • Restrict who can change labels (library permissions, training for owners).

4. For Teams messages:

   • Configure a retention policy such as “keep all Teams channel messages for 3 years” and “chats for 2 years” (subject to legal requirements).
   • Make sure legal and compliance sign off on these durations.

4. Inspecting retention policies via PowerShell

For large tenants, you will eventually want to inspect and document your retention configuration programmatically.

Using the compliance PowerShell module:

Connect-IPPSSession

Get-RetentionCompliancePolicy | ft Name,ExchangeLocation,SharePointLocation,OneDriveLocation

Get-RetentionComplianceRule | ft Name,Policy,RetentionDuration,RetentionAction

This lets you review which locations are covered and how long content is being kept or deleted. It is a good baseline check before you start changing anything.

5. SharePoint library design for records

Record libraries should not be generic file dumps. At minimum:

• Metadata
  • columns that reflect how compliance and legal search for records: customer, case ID, employee, project, effective date, record type.
• Permissions
  • restricted to the right group (e.g., HR managers, contract managers).
  • avoid ad‑hoc item‑level permissions unless absolutely necessary.
• Versioning and check‑in/check‑out
  • keep major versions for transparency.
  • avoid too many minor versions on record libraries; they increase noise.
• Default retention label
  • apply the correct label automatically when content is added.

If you need more help with library design choices, see SharePoint document library design before Copilot.

6. Teams channels, files, and chat

Remember how Teams works under the hood:

• Standard channel files live in the associated SharePoint site, in channel‑named folders.
• Private and shared channels can have their own SharePoint sites with separate permissions.
• Chats and channel messages are stored in Exchange and governed by message retention policies.

Records considerations:

• For teams that produce records (e.g., a project team delivering official reports), decide whether:
  • the team’s SharePoint site is the record location, or
  • records are moved to a separate record site once approved.
• For private channels that contain sensitive records, review:
  • whether their separate SharePoint sites have appropriate retention and access.

7. Governance: workspace lifecycle and permissions

Records management is not just about content. It is also about workspace lifecycle:

• Who can create new Teams and SharePoint sites that will hold records?
• How do you review inactive sites and teams?
• How do you ensure owners are assigned and stay current?

Governed workspace provisioning (for example, as described in workspace provisioning governance in Microsoft 365) helps you:

• capture purpose and record implications when a workspace is created
• track ownership and review dates
• avoid record‑bearing sites being created ad hoc with no oversight

For permissions on record libraries, align with broader SharePoint governance consulting decisions so you do not end up with broken inheritance and hard‑to‑audit access.

Retrofitting Records Management in an Existing Tenant

Most readers are not starting from a blank tenant. You already have:

• thousands of SharePoint sites
• hundreds or thousands of Teams
• active OneDrive usage

Trying to “fix everything” at once will stall. A more realistic retrofit plan:

Phase 1: Discover and prioritize

• Use reports, PowerShell, or tools (such as those described in migration posts) to identify:
  • sites with large volumes of sensitive or critical content
  • Teams used for customer work, HR discussions, or key projects
  • OneDrive accounts of high‑risk roles (sales, HR, finance)
• Sit down with compliance and legal to pick 3–5 high‑priority record types to tackle first.

Phase 2: Design and pilot record locations

• For each record type, design or refine the target SharePoint record site and libraries.
• Configure Purview retention labels and policies for those locations.
• Pilot with a small group:
  • train them on the OneDrive/Teams/SharePoint decision framework
  • adjust library metadata and labels based on feedback

This is where I often help teams via SharePoint Governance Consulting: we co‑design the model and pilot it safely.

Phase 3: Gradual content cleanup and migration

• Move existing records from OneDrive and Teams into the record libraries.
• Use Power Automate or migration tools where appropriate.
• Document patterns and playbooks for future teams.

Do not aim to retroactively fix every old document. Focus on:

• current and recent records
• high‑risk content
• clear record categories that matter to audits and investigations

Phase 4: Scale and embed into provisioning

• Update workspace provisioning templates so new record‑bearing teams and sites follow the model.
• Add guidance into IT onboarding and business training.
• Establish periodic reviews of record sites and retention settings.

Over time, your tenant transitions from “records everywhere” to “records in known places” with predictable retention.

Business Impact

Designing records management across OneDrive, Teams, and SharePoint is not just a compliance checkbox. It has concrete business impact:

• Reduced audit pain
  Auditors can be pointed to specific record libraries with known retention and metadata, instead of broad searches across the tenant.

• Lower eDiscovery cost and time
  Legal holds and discovery queries can target record locations and labels, reducing the volume of irrelevant documents and chat messages.

• Controlled storage growth
  Retention settings allow you to delete content at the right time, instead of keeping everything forever. This matters for large tenants where storage growth can become a budget topic.

• Better Copilot and search answers
  When records are in clearly designed, labeled libraries, Copilot can rely on them as authoritative sources. Bad or outdated content is less likely to be surfaced.

• Clear ownership and fewer “where is that file” questions
  Users know where final documents live and who owns them. IT spends less time chasing random versions in OneDrive and Teams.

• Stronger confidence from compliance and legal
  When they see a coherent model, they are more willing to support Microsoft 365 adoption instead of asking for parallel legacy systems “just in case”.

Practical Checklist

Use this checklist as a working tool with your IT and compliance teams.

1. List 5–10 key record types (contracts, HR files, policies, major projects) and write down current storage patterns.
2. Decide official record locations for each type (SharePoint sites and libraries) and assign business owners.
3. Document rules for OneDrive, Teams, and SharePoint: what is allowed in each and when content must move to record libraries.
4. Design or refine record libraries with clear metadata, restricted permissions, and default retention labels.
5. Create Purview retention labels and policies aligned to those record types and locations, not generic “catch‑all” rules.
6. Configure Teams message retention policies that balance legal requirements with practical cleanup.
7. Agree on who can declare records and who can change retention; document approval workflows for any change.
8. Pilot the model with one department (e.g., Sales contracts, HR records) and adjust based on feedback.
9. Move recent and high‑risk records from OneDrive and Teams into the new record libraries.
10. Review inactive Teams and sites that may contain records; decide whether to archive, migrate, or close them.
11. Update workspace provisioning so new record‑bearing sites and teams are created with the right templates and retention.
12. Train users and owners on the decision framework: working document vs record, and where each should live.
13. Check Copilot and search behavior against your record libraries to confirm the right content is surfacing.
14. Document and publish the records model, including examples and good/bad patterns.

Final Thoughts

Records management in Microsoft 365 is not solved by turning on Purview and hoping labels will magically appear in the right places. It is solved by making clear decisions about where records live, who owns them, and how their lifecycle is managed.

The OneDrive = me, Teams = us, SharePoint = everyone model is a helpful starting point, but only if you connect it to concrete record locations and retention rules. Otherwise, it remains a slogan while records continue to scatter.

You do not need a perfect, enterprise‑wide solution tomorrow. You need a practical plan for the next 3–6 months: start with a few high‑value record types, design their SharePoint record libraries, configure Purview labels, and pilot the new patterns in a small part of your tenant.

If you are already thinking about Copilot, or you have read articles like SharePoint Copilot readiness checklists and AI in SharePoint is moving from search to action, records management becomes even more important. AI will amplify whatever content and structure you already have.

A practical, trusted records model across OneDrive, Teams, and SharePoint is one of the best investments you can make in your Microsoft 365 environment.

If you would like a structured review of your current records setup and a roadmap that your IT and compliance teams can act on, I regularly help organizations through SharePoint Governance Consulting. We can map your record types to OneDrive, Teams, and SharePoint, configure Purview safely, and pilot changes without disrupting existing users.

When you are ready, reach out via the contact page or the governance services page. Even a short assessment can clarify where records should live, how long you keep them, and how to make sure Copilot and auditors see the same, trusted story.