Here's the thing that makes three very common Copilot assumptions wrong at the same time: Copilot doesn't evaluate your content. It retrieves it.
Copilot works through Microsoft Graph, within your existing permissions, against whatever's in your tenant. It has no concept of "current" vs "outdated," no filter for relevance, no awareness that a site hasn't been touched in two years.
That one architectural fact is why "Copilot will figure out what's relevant," "we already archived those sites," and "we'll fix governance after rollout" are all wrong in ways that matter for Copilot ROI and Microsoft 365 storage governance.
Here's what's actually true for each, and language you can use when they come up.
"Copilot is AI. It knows what's relevant and ignores the old stuff. You don't need to clean up before rollout."
The risk isn't that Copilot averages all your old files together. It's that a stale or superseded document can look like the most relevant one if the tenant is full of near-duplicate content with no clear signal of which is current.
Version history is a related but separate problem. Without limits in place, it accumulates automatically and quietly inflates your storage costs, but that's a storage governance issue, not a Copilot retrieval one. The more common Copilot signal problem comes from unstructured file sprawl: multiple copies of the same document saved manually under different names, with no clear signal of which is current.
Copilot will surface the most semantically relevant result, but if your tenant has five versions of "Sales Process FINAL v3 revised" saved as separate files, it has no reliable way to know which one actually is. We cover the storage side of version history how version history affects SharePoint and OneDrive storage.
The fix isn't to make Copilot smarter. It's to give it less to work through: ROT cleanup, clear ownership of what's current, and version limits to keep storage costs from compounding the problem.
Microsoft’s own documentation is explicit on this: well-governed, current content is what allows Copilot to produce accurate results.
But that’s not a default state. It's something you have to create.
"Copilot searches what users have access to and surfaces what looks most relevant. If our tenant is full of old drafts and duplicate files with no clear signal of which is current, those become the candidate pool. Cleanup isn't extra work on top of Copilot. It's what makes the responses worth trusting."
This is what that looks like in practice. The SharePoint admin center Active sites view, sorted by last activity, surfaces exactly which sites are still in Copilot's scope, whether anyone's touched them recently or not.
"We've archived those sites. Copilot won't touch them."
This one's partly true, which is exactly what makes it dangerous. Whether it's correct depends entirely on which tool was used to archive.
In Microsoft 365, “archive” means two different things with opposite implications for Copilot.
| Archive type | Visible to Copilot? | Reduces storage cost? |
|---|---|---|
| Teams archive (Teams client) | YES. Content stays in Copilot's index if the user has access. | No |
| M365 Archive (SharePoint admin center) | NO. Removed from Copilot's index entirely. | Yes. $0.05/GB vs $0.20/GB for active storage overage. |
When you archive a team in the Teams client, you're making it read-only and hiding it from the active channels list. The underlying SharePoint site stays online. The content stays in active storage. Copilot can still reach it.
Microsoft MVP research confirms this directly: Teams archive doesn't prevent the data from being surfaced by Copilot.
Microsoft 365 Archive, managed from the SharePoint admin center, is a separate product. When you archive a site there, it moves to a cold storage tier, drops out of your active storage quota, and is removed from Copilot's index.
Microsoft’s own documentation is unambiguous: “archived content isn't used by Microsoft 365 Copilot.” They even frame it as a feature, not a limitation: “Copilot is not trained on archived content, maximizing response relevancy.”
The M365 Archive FAQ also confirms these are independent features: “Archiving a team doesn't automatically archive the corresponding site.” If someone archived a team in the Teams client without also running the site through M365 Archive in the admin center, that SharePoint content is still in scope for Copilot.
This is what M365 Archive actually looks like in the SharePoint admin center: a separate view from Active sites, with its own archived status, storage accounting, and archive date. If your sites aren't showing here, they haven't been archived in the way that removes them from Copilot's index.
For the full breakdown of which archiving option does what, see SharePoint archiving solutions vs. storage offloading.
Even when content is correctly moved to M365 Archive, there's a second issue.
If a site had broad sharing before it was archived, those sharing links stay active unless you explicitly revoke them. “Anyone with the link” sharing doesn't expire on its own. If someone reactivates the site later, all of that access is still in place.
Archiving without reviewing permissions first doesn't resolve the exposure. It moves it to a cheaper storage tier.
"When you say we've archived those sites, it depends what you mean. If you used Microsoft 365 Archive through the SharePoint admin center, then yes, that content is out of Copilot's index. If you archived a team in the Teams client, Copilot can still reach it. Either way, we should be reviewing permissions before assuming anything is out of risk."
"Get Copilot in users' hands now. Governance can run in parallel."
Here's what's worth knowing if this decision has already been made above your level: the cleanup doesn't get easier after rollout. It gets harder, and more visible.
Before Copilot is live, ROT content and overshared sites are a dormant problem. After it's live, they're the reason users are getting noisy or wrong responses, and now the fix has to happen in public. The people who were going to own cleanup are fielding helpdesk tickets. The governance work slides to next quarter, then the quarter after that.
There's also a first-impression problem that's difficult to recover from. If users get poor Copilot results in the first few weeks, they lose trust in the tool. Getting that back is harder than setting a better foundation before day one.
Microsoft's Inside Track blog on how they tackled Copilot governance internally is instructive here: even Microsoft runs an extensive, actively managed, multi-layer governance program for their own deployment. If governance isn't automatic at Microsoft, it won't be automatic anywhere.
The argument that tends to land with leadership isn't “we should do governance first.” It's “if we don't, we're paying for Copilot licenses while users are getting results we'll need to explain.”
The pre-work isn't a separate project. It's the same work the tenant needs regardless, done in an order that makes the rollout start strong instead of start apologetic.
"Governance cleanup and Copilot rollout aren't two separate workstreams. They're the same workstream in a different order. If we do governance after, we're paying for Copilot while users get results that undermine confidence in it. If we do it before, the rollout starts strong and we're not remediating under pressure."
Copilot governance prep isn’t a six-month project. The highest-impact, lowest-controversy items are:
All three of these myths share the same root assumption: that Copilot will compensate for governance work that hasn't happened. It won't. It'll just surface the results of it faster.
For most organizations, the pre-Copilot governance work isn't a new project. It's applying controls you should already have to a tenant that's outgrown manual management.
Microsoft gives you the tools: version history limits, M365 Archive, SAM reports for oversharing and inactive sites. The challenge is doing it consistently across a real tenant without it landing on one admin with a spreadsheet and a script.
Orchestry automates the pre-rollout work: archival and version policies run across your tenant automatically, and a Copilot Readiness Dashboard gives IT something concrete to show leadership when they ask how the governance work is going.
The Readiness Markers flag the specific governance signals that affect Copilot quality — sharing links, sensitivity label coverage, broken inheritance, overexposed groups — alongside a score benchmarked against your tenant average and similar organizations.
The Usage Markers show document-level activity status, so you can see exactly what Copilot is working with inside each workspace before you decide what to archive, clean up, or leave as is.
If you're mid-rollout and haven't started yet, version history limits and M365 Archive for clearly inactive sites are the highest-impact starting points. Both improve Copilot quality and cut storage costs at the same time, which is a straightforward case to make to whoever approved the Copilot budget.
Getting Copilot to deliver on its promise isn't just a deployment question. It's a governance one. If you want to see where your tenant stands before or during rollout, Orchestry gives you the visibility and the tools to act on it.
Book a walkthrough with our team to see how Orchestry handles this in practice.