Copilot readiness guides tend to set the same bar: complete oversharing remediation, full sensitivity labeling, zero ROT content, months of governance cleanup. That bar is probably right for an org-wide deployment. It’s not the right bar for a 25-person pilot that starts in three weeks.
There is a real minimum below which you shouldn’t start a Copilot pilot. But Copilot pilot readiness doesn’t require perfection first: it requires clearing five specific gates. Miss one and you have a bounded thing to fix. Clear all five and you can run a pilot with reasonable confidence, even if the rest of the tenant is far from perfect.
That’s what this post covers: the minimum viable tenant cleanup for Copilot, based on what Orchestry has seen across hundreds of M365 tenants.
“Good enough” for a Copilot pilot means your users won’t hit operational blockers, Copilot won’t surface egregiously stale or exposed content from the sites in scope, and you won’t get blindsided by a storage failure or an orphaned-account incident during the pilot window.
“Good enough” doesn’t mean every governance gap is resolved, every version history is trimmed, or every OneDrive is audited. The pilot is how you find out what else matters.
Think of each section below as a binary gate. Pass all five and you’re clear to start. Fail any one and you have a specific, bounded thing to address first: not a months-long project, a targeted fix.
Note: This isn’t a Copilot readiness checklist covering every governance dimension. It’s shorter and more specific than that: five questions, five answers, and a clear go/no-go.
This is the only gate that's an operational prerequisite rather than a content quality concern. Everything else in this list affects what Copilot surfaces. This one determines whether the tenant can function during the pilot at all.
When a SharePoint tenant exceeds its pooled storage allocation, Microsoft puts it into read-only mode. Users can view content but can’t save, edit, or sync. Copilot can’t generate or save outputs either. If you’re in the red zone before the pilot starts, the pilot doesn’t work.
The pass/fail question: Is your tenant below 90% of its pooled SharePoint storage allocation?
Where to check: SharePoint Admin Center → Sites → Active sites. The storage usage bar at the top of the page shows your current total vs. your allocation.
Why 90%? At 100% you’re at read-only risk. At 90% you have enough runway for the pilot to generate new content without triggering the limit. Storage headroom isn't a Copilot readiness signal, but it is a basic operational floor. A pilot can start with messy content. It can't start in read-only mode.
If you’re in the red zone: You need remediation before the pilot, not after. The fastest paths are enabling version history limits (Gate 2 below), archiving inactive sites (Gate 5 below), or purchasing additional storage.
For a step-by-step process, see how to check your SharePoint and OneDrive storage. For context on why storage costs accumulate quietly, see why M365 storage turns into a cost surprise.
Version bloat is the most common cause of unexpected storage consumption in M365 tenants, and it’s almost entirely invisible until you look for it. A single 50 MB PowerPoint with 200 autosaved versions over a year can consume 10+ GB of quota. Without an org-level version limit in place, that accumulation happens silently across every document library in your tenant, indefinitely.
The pass/fail question: Do you have an org-wide version history limit configured in the SharePoint Admin Center, specifically the “Automatic” setting or a defined manual limit?
Where to check: SharePoint Admin Center → Settings → Version history limits. If the setting reads “No limits,” you’re not cleared on this gate.
The minimum-bar recommendation: Enable the “Automatic” setting at the org level. This applies Microsoft’s intelligent thinning to all new libraries created from that point forward; it doesn't retroactively update existing libraries or trim versions already stored.
To apply the new limits to existing libraries, you'll need to do so site by site through the admin center or via PowerShell. Microsoft’s version history limits documentation covers both paths.
Why this matters for a pilot specifically: Pilot users will generate content. More content, more versions, more storage pressure. If you enter the pilot with unbounded version accumulation and limited storage headroom, you’re creating a compounding problem that surfaces during the pilot window, not after it. The fix here is a single setting change that takes minutes.
For the full picture on how version history accumulates and how to trim it at scale, see how version history affects SharePoint and OneDrive storage.
OneDrive is the governance gap most organizations don't discover until Copilot makes it visible.
Orphaned OneDrive accounts belonging to users who've left the organization remain in the Copilot index during the retention window: by default, up to 30 days after account deletion, or up to 93 days after license removal if the account isn't deleted in Entra ID.
If the content in those accounts was broadly shared, Copilot can surface it for any user who still has access. The problem isn't always that the content is sensitive: it's that no one expected it to be findable.
This is the OneDrive blind spot most admins miss: personal storage grows quietly, follows individual work habits, and rarely receives the same governance attention as Teams sites or SharePoint document libraries.
The pass/fail question: Do you have an active offboarding process that either reassigns, retains, or removes departing users’ OneDrive accounts within a defined window, and is it being followed?
Where to check: SharePoint Admin Center → Settings → OneDrive → Storage and retention. The “Days to retain a deleted user’s OneDrive” field shows your current retention window (default: 30 days). Also check Microsoft 365 Admin Center → Users → Deleted users for accounts that may have slipped through the process.
What minimum-bar looks like: The 30-day default retention window is fine as a starting point. The gap isn’t the window: it’s whether anyone is actively reviewing deleted users and making explicit retain/reassign/delete decisions within it. If the answer is “it just happens automatically,” you have a process gap.
Microsoft’s OneDrive retention and deletion documentation covers the full lifecycle, including the automatic archiving behavior for unlicensed accounts at 93 days. Practical365’s employee termination checklist for M365 is also useful for mapping the full offboarding workflow.
Why this matters for the pilot specifically: A pilot group will be among the first to notice if Copilot surfaces stale content from people who left the company. That’s a trust problem that’s hard to recover from during a pilot window.
For the full process on what happens to OneDrive data when users leave and how to build a policy-driven offboarding workflow, see OneDrive offboarding: what happens when users leave.
Copilot doesn’t create sharing risk: it reveals sharing risk that already exists. Sites that have been broadly shared for years were always accessible to a far wider audience than most admins realize. Copilot just makes them frictionlessly findable. The minimum bar before a pilot isn’t to fix all oversharing: it’s to know where your broadest exposure is so you’re not surprised by it during the pilot.
Microsoft’s Copilot blueprint for oversharing identifies “Everyone except external users” sharing, “Anyone,” and “People in your organization” links among the highest-priority items to understand before any Copilot rollout, because these represent content that’s accessible to the broadest possible audience inside your tenant.
The pass/fail question: Do you have a current list of SharePoint sites with "Everyone except external users" sharing enabled, "Anyone" links active, or "People in your organization" links active on your highest-traffic or highest-storage sites?
Where to check (without SAM): SharePoint Admin Center → Policies → Sharing → External sharing settings for the org-level view. For per-site sharing, go to Active sites → select a site → Sharing column. Sharing reports are also available under Reports → SharePoint.
Where to check (with SharePoint Advanced Management): SharePoint Admin Center → Reports → Data access governance. The “Everyone except external users,” “Anyone links,” and “People in your organization links” reports give you a tenant-wide picture fast. Data Access Governance reports require a SharePoint Advanced Management license, included in Microsoft 365 E5 or available as an add-on.
What minimum-bar looks like: You don’t need to remediate all oversharing before the pilot. You need to run the report, know what you’re working with, and make an informed decision about whether any of it warrants action before the pilot users touch it. Visibility is the gate, not remediation.
For a deeper look at oversharing risk in the Copilot context, Orchestry’s how to fix oversharing in Microsoft 365 and more ways to fix oversharing before Copilot deployment cover the remediation steps in full. This section is about identification, not remediation.
Not all archiving is equal, and the distinction matters for Copilot. A team marked “Archived” in the Teams client is still indexed by Copilot if users have permissions to it. A site moved to Microsoft 365 Archive through the SharePoint Admin Center is removed from Copilot’s index entirely. The minimum bar before a pilot isn’t to have archived everything: it’s to have made an explicit, informed decision about your inactive sites so you know what Copilot can and can’t reach.
Microsoft’s SharePoint Advanced Management Copilot readiness documentation confirms that sites moved to Microsoft 365 Archive are no longer surfaced by Copilot.
The pass/fail question: Have you identified your SharePoint sites with no activity in the past 12+ months and made a deliberate decision, archive, delete, or keep active, for each one? Or are they sitting in active storage, still indexed by Copilot, because no one has reviewed them?
Where to check: SharePoint Admin Center → Sites → Active sites → filter by “Last activity” or sort by date. Sites with no activity in 12+ months are your review candidates.
The minimum-bar decision: You don’t need to archive everything before the pilot. You need to review the list and make a call. Sites you decide to archive are content Copilot stops surfacing. Sites you decide to keep active are an intentional choice, not a default.
Archive vs. delete: Microsoft 365 Archive is the right tool for content that needs to be retained but shouldn’t be surfaced in Copilot If your tenant is over quota, it also moves that storage from the standard overage rate to a lower-cost archive tier. If you're under quota, archived storage costs nothing. Deletion is for content that genuinely has no business value. A site that’s been inactive for three years probably belongs in one of those two categories, not in active SharePoint storage.
For a comparison of archiving approaches and how each affects Copilot visibility and storage costs, see SharePoint archiving solutions vs. storage offloading.
Here’s where you stand after working through the five gates:
Five yeses means you’re ready to pilot. Four yeses and one no means you have a specific, bounded thing to fix: probably a few hours of work, not a governance project. Fewer than three yeses means the gaps are significant enough that you’d be setting the pilot up to surface problems during the window rather than after it.
The admins who do this work before a pilot aren’t being obstructionist. They’re front-loading a small amount of targeted effort that determines whether Copilot earns trust with the pilot group, or loses it on the first day.
Every check in this post is something you can run manually using Microsoft’s native admin center tools. For a small tenant with a handful of sites, that’s a realistic afternoon. For an enterprise tenant with hundreds of sites and thousands of OneDrive accounts, whether you’re doing tenant cleanup for a Copilot pilot or preparing for a full deployment, doing it site by site isn’t practical.
Orchestry gives you a single dashboard view across all five gates: storage position, version history status, OneDrive offboarding gaps, sharing exposure, and inactive site candidates, without navigating five separate admin center locations. You can identify the highest-risk areas across the tenant at once, set thresholds, and get alerts when any gate drifts back into the red after the pilot starts.
See where your tenant stands with Orchestry's Copilot readiness tools.
The five gates in this post define the floor. If you want the full framework, including the comprehensive five-step storage and governance assessment every M365 tenant should run before a broader Copilot rollout, the Microsoft 365 Copilot readiness checklist covers all of it in detail.