Most SharePoint tenants have hundreds of sites that nobody has touched in over a year. Deciding what to do with them is one of the least glamorous governance decisions an admin makes, and one of the most consequential. Get it wrong in one direction and you destroy content someone needed. Get it wrong in the other and inactive sites quietly drain your storage quota and clutter search results for years.
This post lays out a practical decision framework. Not a philosophy paper on information governance; a working guide for the admin who has a list of 200 inactive sites and needs to start moving through it.
What Archiving and Deleting Actually Mean in SharePoint
The words "archive" and "delete" are used loosely in IT conversations, so it helps to be precise about what each operation actually does in a SharePoint Online context before building a decision framework around them.
Archiving a SharePoint site, through Microsoft's native Microsoft 365 Archive feature, makes the site read-only. Users can still find and view content through SharePoint search; they just cannot upload, edit, or delete anything. The site's storage is moved to a lower-cost archive tier that does not count against your active Microsoft 365 tenant quota pool. The site can be reactivated by a SharePoint administrator if it needs to go back into active use. Think of it as putting the site in cold storage: preserved and accessible, but not running.
Deleting a SharePoint site removes it from the active tenant. The site and all its content (documents, lists, pages, permissions, version history) move to the site collection recycle bin, where they can be recovered by a SharePoint administrator for up to 93 days. After that window closes, the site is gone permanently. There is no lower-cost storage tier. The quota is freed completely. Deletion is a one-way door once the recycle bin clears.
The practical difference is this: archiving is a bet that someone might need the content someday. Deleting is a decision that nobody will.
When Archiving Is the Right Call
Archive a site when you cannot be certain the content is safe to lose. In practice, that covers a narrower set of sites than most admins initially assume. Strong candidates for archiving include:
Sites under a legal hold or compliance retention requirement. If a site's content is subject to Microsoft Purview retention policies, active eDiscovery, or a legal hold instruction from your legal team, do not delete it regardless of how inactive it appears. Archive it, document why, and leave it until the hold is lifted.
Completed long-term projects with substantive output. A two-year infrastructure migration project produces decision documents, vendor contracts, post-implementation reports, and audit trails. When the project closes, nobody is actively working in the site. But those documents may be referenced during audits, regulatory reviews, or future projects for years afterward. Archiving preserves the content at lower cost without requiring anyone to manually curate what to keep.
Sites for teams or departments that have been restructured. When a business unit is merged into another, its SharePoint site typically goes quiet. But the institutional memory stored in that site (operating procedures, client history, internal policies) may still be valuable to the people who inherited the work. Archiving buys time to decide what to migrate to the new team's site and what to let expire.
Sites where business ownership is unclear. If you cannot quickly identify who is responsible for a site's content, archiving is the conservative choice. It stops the storage bleed and makes the site read-only, but gives you a recovery path if the owner resurfaces and protests.
When Deletion Is the Right Call
Deleting is the right answer more often than admins tend to act on, because the consequence of a wrong delete (scrambling to recover from the recycle bin within 93 days) feels more vivid than the consequence of keeping too much (slow, diffuse storage drain and search pollution). Here are the scenarios where deletion is clearly warranted:
Test and sandbox sites. A site created to try out a SharePoint page template, test a new workflow, or validate a migration job before running it on production data has no long-term value. Delete it. If it was worth testing, it has been promoted somewhere else. If it was not promoted, it was not worth keeping.
Sites whose content has been migrated elsewhere. After a cross-tenant migration or a tenant consolidation project, teams often leave the source sites in place "just in case." In practice, "just in case" rarely arrives, and the source sites end up living indefinitely alongside the destination content, doubling your storage footprint and creating confusion about which version is authoritative. Once a migration is verified, delete the source site on a defined timeline.
Content left behind by departed employees. Personal project sites, My Site content, or team sites created by employees who have left and taken their institutional knowledge with them are strong deletion candidates if no one on the current team uses or recognises the content. Run it by the person's former manager, then delete if the answer is "nothing there we need."
Sites with no activity and no compliance obligation. A site with zero document views, zero edits, and zero sign-ins in the past 24 months that is not under any retention requirement is an excellent deletion candidate. The content may have seemed important when someone created it. Three years later, with no one accessing it, it almost certainly is not.
When Should You Archive vs Delete a SharePoint Site?
The simplest decision rule: archive when you cannot be sure content is safe to destroy; delete when you can. More specifically, apply this checklist to each site:
- Is the site under a legal hold or retention policy? If yes, archive. Do not delete.
- Has anyone accessed the site in the last 12 months? If yes, investigate before acting. It may still be in active use.
- Is the site's content duplicated elsewhere (migrated, copied, or inherently redundant)? If yes, lean toward deletion after verifying the destination is complete.
- Does the site contain completed project output that may be referenced for audits, onboarding, or future projects? If yes, archive.
- Is the business owner of the site reachable and able to confirm the site has no ongoing value? If yes and they confirm no value, delete.
- Is the site a test or sandbox environment? If yes, delete.
If none of these criteria give you a clear answer, archive by default. The cost of archive storage is low, and a wrong archive decision is reversible. A wrong delete decision after the 93-day window closes is not.
The Scale Problem: Making These Decisions Across Hundreds of Sites
A single site review takes five to fifteen minutes: check the last activity date, identify the owner, look at the content volume, make a call. For ten sites, that is an afternoon. For 200 sites, that is weeks of work before you have even started acting on the decisions.
Most SharePoint tenants accumulate hundreds of untouched sites not because admins ignore the problem, but because gathering the data to make each decision is tedious. Last activity date, content size, owner, and retention status are scattered across the SharePoint admin center, Entra ID, and Purview - assembling that picture for even one site takes enough clicks that scaling the process feels impossible.
Do one structured sweep with the right data - not ad-hoc reviews one site at a time. Report Master exports site-level metadata to Excel including storage used, last modified date, site collection administrator, and item counts. With that export in hand, you can sort, filter, and categorise 200 sites in a spreadsheet in an hour rather than clicking through the admin center for days.
Once the decision column is filled in, acting on the deletes is its own challenge at scale. Navigating to each site and deleting it manually through the admin center UI is feasible for 10 sites. For 80 sites scheduled for deletion, Space Master's Bulk Delete Sites tool applies the deletion list in a single operation, with a clear confirmation step before any action is taken.
For a checklist of signals that indicate a SharePoint tenant is overdue for a cleanup sweep, the SharePoint tenant health check signals post covers the leading indicators worth watching on a quarterly basis.
The governance reality is that no SharePoint tenant reaches a "done" state on site lifecycle management. Teams create sites, projects end, organisational structures change, and sites accumulate faster than they are reviewed. Building a repeatable process that is light enough to run quarterly or annually is more valuable than a single comprehensive purge that exhausts the team and never happens again. Start with the obvious candidates, build confidence in the process, and establish a rhythm.
Frequently Asked Questions
When should you archive vs delete a SharePoint site?
Archive when content may still be needed for reference, compliance, or legal purposes even if no active work is happening. Delete when the site was temporary, its content has been migrated elsewhere, or there is no compliance obligation and no realistic chance the content will be needed again.
Does archiving a SharePoint site free up storage?
Microsoft 365 Archive moves sites to a lower-cost storage tier, relieving pressure on your active Microsoft 365 quota. Archived sites are not free: they incur a per-GB cost at the archive rate. Deletion frees storage entirely once the 93-day recycle bin window passes.
Can you recover a SharePoint site after it is deleted?
Yes, for up to 93 days after deletion. Deleted sites enter the site collection recycle bin, where a SharePoint administrator can restore them. After 93 days, or after the admin permanently removes the site from the recycle bin, recovery through standard SharePoint tools is not possible.
Can you unarchive a SharePoint site?
Yes. Sites archived via Microsoft 365 Archive can be reactivated by a SharePoint administrator. Reactivation restores active-use status, removes the read-only restriction, and returns the site's storage to the active tenant quota pool.