Your Microsoft 365 tenant probably isn't as ready for Copilot as you think it is. Not because you haven't done the work, but because most readiness guides have been focused on the wrong things. Licenses, MFA, audit logging: those are table stakes. What they don't cover is the content Copilot actually has to work with.
Your storage estate is the part Copilot readiness guides consistently skip. Copilot doesn't filter out old drafts, superseded documents, or files from people who left the company two years ago. It surfaces whatever your users have access to. Whether that makes Copilot useful or embarrassing depends on decisions you make before rollout, most of which have nothing to do with licensing.
This checklist covers the five storage and governance dimensions that determine whether your tenant is actually ready. It's the Copilot data readiness work most guides skip, and the fastest way to get a clear picture of your Copilot tenant readiness before licenses go live. Work through it and you'll know exactly where your gaps are.
If you haven't read our post on the three dangerous myths about Copilot and storage, that's a useful primer before you dive in here. And if you're new to how M365 storage costs accumulate, why SharePoint and OneDrive storage turns into a cost surprise is worth reading first.
Note: This checklist assumes you've already handled the prerequisite basics, valid M365 licenses, MFA enabled, and audit logging turned on. If you haven't, Microsoft's official Copilot setup guide is the right starting point. Once you’ve finished there, this checklist picks up where that one leaves off.
Each section has a set of yes/no questions. Yes means you're in good shape on that dimension. No means it's a gap worth closing before Copilot rolls out.
| ☐ | Can you identify your top 10 SharePoint sites by storage consumed? |
| ☐ | Do you know which of those sites have the highest concentration of ROT content (redundant, obsolete, or trivial files)? |
| ☐ | Have you done any active cleanup of inactive or duplicate content in the past 12 months? |
| ☐ | Do you have a process for identifying content that should be removed or archived before Copilot rolls out? |
SharePoint Admin Center > Active sites, sorted by storage used. The bar in the top right shows tenant-level storage consumption against your allocation.
Getting a clear picture of where content is concentrated is the first step toward cleaning it up before Copilot rolls out.
Copilot doesn't evaluate whether a file is current, relevant, or accurate. It surfaces whatever users have access to. A tenant full of ROT content (redundant drafts, obsolete project files, duplicate copies of the same document) gives Copilot more low-value material to draw from.
That degrades response quality in ways that are hard to diagnose after the fact because users don't know what Copilot isn't finding; they just know the answers aren't great.
Knowing which sites carry the most content weight tells you where to focus cleanup effort first. It's not about hitting a storage number; it's about knowing where the noise is coming from.
Our storage health check walkthrough covers how to identify your highest-storage sites in the SharePoint admin center and where to start your cleanup prioritization.
| ☐ | Do you have an org-wide version history limit configured in the SharePoint admin center? |
| ☐ | Are you using automatic version trimming, or a fixed version count? |
| ☐ | Do you know which of your highest-storage sites are also your highest-versioning sites? |
| ☐ | Have you run a trim job on your highest-versioning sites, or are you relying on limits alone to control growth? |
The version history limits settings panel. Most tenants still have 'Manually' set at 500 versions, which is the default. 'Automatically' is Microsoft's recommended setting.
Version history is the most underestimated driver of storage growth, and unmanaged storage growth is directly connected to Copilot readiness.
A single 25MB presentation with 200 auto-saved versions can consume more than 5GB of tenant storage. Copilot uses the current version of a document, not historical versions, but version bloat is a reliable signal of a tenant that hasn't governed content lifecycle. Those tenants accumulate duplicate files, manually saved copies, and stale content across active libraries.
If your users are saving files as 'v2_final,' 'v2_final_REAL,' or 'final_FOR_REAL_THIS_TIME' across different libraries, those are separate files, and Copilot can surface all of them alongside the actual current version. That's what degrades response quality.
Getting version history under control is the governance foundation that prevents the wider content sprawl problem from compounding. It's not a direct Copilot indexing issue; it's the habit that keeps your active storage clean enough for Copilot to work well.
Setting org-wide version limits governs new document libraries only. Existing libraries aren't updated automatically, and existing versions aren't touched at all. To reduce the versions already on your sites, you need to run a separate trim job, either through PowerShell or a tool that handles it for you. For most tenants, it's that existing version history that represents the biggest footprint, not anything accumulated after a new limit is set.
A note on scope: SharePoint's version settings apply to document libraries. There's no tenant-level toggle that retroactively trims everything at once. Cleanup requires targeting libraries, which is feasible manually for a handful of high-priority sites and requires tooling at scale.
| ☐ | Do you know how many OneDrive accounts exist in your tenant for users who have since left the organization? |
| ☐ | Are those accounts being preserved, deleted on schedule, or left in limbo because no one has a process for them? |
| ☐ | Can you identify OneDrive accounts that haven't had activity in 90 or more days? |
| ☐ | For OneDrives you've retained from departed users: has the content been reviewed, assigned to a new owner, or designated for deletion? |
Microsoft 365 Admin Center > Reports > Usage > OneDrive > Usage tab. The gap between total accounts (teal) and active accounts (purple) represents accounts that exist but have had no recent activity, including OneDrives belonging to departed users.
OneDrive is where Copilot data readiness gaps are hardest to see and most likely to catch you off guard. It's also the part of the M365 estate most governance conversations skip.
OneDrive grows in ways that aren't obvious: files shared in Teams chats live in OneDrive, email attachments sync there, and every user who ever used Power Automate has files you probably haven't accounted for.
The bigger issue is offboarding. The default 30-day deletion window for departed users is frequently extended, paused, or simply ignored because no one has a clean process for reviewing what's in a departing user's drive.
The result is a growing pool of stale personal storage that's invisible in most governance dashboards. What happens next depends on how your organization offboards users.
What actually happens to OneDrive data when a user leaves is more complicated than most admins expect, and the gap between “account deleted” and “storage freed” is where most of this risk lives.
| ☐ | Do you have a current list of SharePoint sites with 'Everyone except external users' sharing permissions? |
| ☐ | Do you know which sites have 'Anyone with the link' sharing enabled? |
| ☐ | Are you running Data Access Governance reports in SharePoint Advanced Management (if licensed)? |
| ☐ | Have you audited sharing permissions on your top 20 sites by storage in the last 6 months? |
| ☐ | Do you know how many items across your highest-risk sites have broken permission inheritance, and do you have a way to identify and remediate them? |
SharePoint Admin Center > Reports > Data access governance > Site permissions across your organization.
Copilot oversharing risk is the gap that surprises organizations most at rollout.
Copilot respects existing permissions. It doesn't create new exposure; it reveals exposure that already exists. A site that's been broadly shared for years was always accessible to anyone with the link. Copilot just makes it frictionlessly findable.
Microsoft's own oversharing blueprint identifies “Everyone except external users,” “Anyone with the link,” and "People in your organization" sharing as the highest-priority items to address before rollout.
The oversharing risk is consistent enough that Microsoft built a phased remediation framework around it. The short version: run the Data Access Governance reports, identify your highest-exposure sites, and review sharing settings before you expand Copilot access. This checklist item is about finding the exposure, not remediating it.
There's a third exposure vector that's less visible than either of the above: broken permission inheritance.
When a user shares a file via a copy link, creates an organizational sharing link, or when a workflow modifies item-level access, SharePoint silently breaks permission inheritance on that item. The item now has unique permissions separate from the site or library.
Even if the sharing link is later removed or expires, the broken inheritance persists, and the item becomes a permanent exception to the parent permission model.
Copilot will surface that content to anyone who still has those lingering permissions, and there's no native admin center view that shows you which specific items are affected.
A note on licensing: Data Access Governance reports require SharePoint Advanced Management (SAM). If your organization has at least one Microsoft 365 Copilot license assigned, SAM is included automatically. If you don't have Copilot licenses yet, SAM is available as a standalone add-on at $3 per user per month.
| ☐ | Can you identify SharePoint sites that have had no activity in 12 or more months? |
| ☐ | Have those sites been formally archived using Microsoft 365 Archive, not just marked read-only or left in Teams archive? |
| ☐ | Do you know the difference between a site archived in M365 Archive and a team archived through the Teams client, and which Copilot can still reach? |
| ☐ | Have you evaluated which inactive sites are candidates for M365 Archive versus which should be deleted entirely? |
| ☐ | Do you know which sites are excluded from Copilot via Restricted Content Discovery (RCD) or not indexed, and are those the right sites? |
SharePoint Admin Center > Sites > Archived sites. Sites in this view have been moved to Microsoft 365 Archive and are excluded from Copilot's index.
Not all archiving is equal. This is one of the most common misconceptions we've seen in the Copilot readiness conversation, so it's worth being precise.
A team marked “Archived” in the Teams client is still indexed by Copilot if users have permissions. The content is read-only, but it's still in active storage and still in scope for Copilot responses.
A site moved to Microsoft 365 Archive through the SharePoint admin center is removed from Copilot's index entirely. It also drops from $0.20/GB overage pricing to $0.05/GB. That's the archiving approach that serves both your storage budget and your Copilot readiness goals simultaneously.
Most organizations have a significant tail of inactive sites that Copilot can technically reach but that serve no current business purpose. These are the first candidates for M365 Archive. Every inactive site you move out of active storage is content Copilot stops surfacing and storage cost you stop paying for at the overage rate.
Before choosing between M365 Archive and third-party offloading options, it's worth understanding how each approach affects what Copilot can see and what compliance coverage you retain.
Five yes's: You're in better shape than most organizations. Document the audit and share it with the stakeholders who are pushing for rollout. The storage hygiene work is done; Copilot can start strong.
Three to four yes's: You have a clear pre-rollout workload. Version history limits and inactive site archiving are the fastest wins. Both can be addressed using native admin center tools in a day or two. Prioritize those before broader deployment.
Fewer than three yes's: The gaps are significant enough that a phased rollout makes more sense than a broad one. Start with a pilot group on sites you've already cleaned up, and let that pilot inform the remediation priority order for the rest of the tenant.
The admins who do this work before rollout aren't creating extra work. They're front-loading work that has to happen regardless of Copilot. Version history, offboarding processes, archival strategy, and permissions hygiene are things every M365 tenant needs. Copilot just makes the cost of not having them more visible.
If you want a framework for making storage governance a standing practice rather than a one-time project, we cover that in our storage strategy series.
Every item in this checklist is something you can assess manually using the SharePoint admin center and Microsoft 365 admin center. For a smaller tenant with a manageable number of sites, that's a realistic afternoon. For a large enterprise tenant with hundreds or thousands of sites, doing it location by location isn't practical.
Orchestry surfaces all five dimensions across connected dashboards and reports: storage headroom and version history bloat at the workspace level, orphaned and inactive OneDrives in the OneDrive reports page, sharing exposure through the workspace risk rating and Copilot dashboard, and archive candidates through automated archival policies. You can move from a summary view to a detailed workspace list in a few clicks
Orchestry's Copilot Dashboard showing tenant-wide readiness score, oversharing markers, and governance indicators across SharePoint and OneDrive.
You can run version cleanup in bulk across multiple workspaces, set policies to prevent the problems from rebuilding, and report readiness progress to leadership without assembling the data manually.
If you're preparing for Copilot and want to see where your tenant stands today, see how Orchestry handles Copilot readiness.
If you haven't read the preceding post in this series, three dangerous myths about Microsoft 365 Copilot and storage covers the exec-level assumptions that make this audit necessary in the first place.