Provisioning a new SharePoint team site takes about 30 seconds. Retiring one safely takes weeks. When it happens at all.
That asymmetry is why Microsoft 365 tenants accumulate site sprawl so reliably. The friction sits entirely on the decommissioning side. There is no equivalent of the "New site" button that says "Archive this site, remove external access, and clean up the storage." So sites multiply. Ownership lapses. Content ages. And admins inherit the mess.
Lifecycle management is the framework that closes the gap. It is not a single tool or policy; it is a set of decisions made at each stage of a site's existence so that the estate stays manageable over time. This post walks through each stage with the practical choices that actually work.
What is SharePoint site lifecycle management?
Site lifecycle management is the set of policies and processes that govern a SharePoint Online site from the moment it is provisioned to the moment it is archived or deleted. It answers four questions for every site in your tenant:
- Who is allowed to request a new site, and on what template?
- Who is accountable for the site's content and access while it is active?
- When does the site stop being useful, and how do you detect that?
- What happens to the content, permissions, and storage when the site's working life ends?
Without answers to those four questions, the default state is unconstrained growth: anyone can create sites, nobody is accountable for them after the first month, and the tenant's site count only ever goes up.
Why site sprawl accelerates faster than most admins expect
The cost of sites with no owner
Microsoft 365 provisioning is deliberately low-friction. A team creates a Microsoft Teams channel and a SharePoint site is created automatically alongside it. A project kicks off and someone spins up a SharePoint communication site to share updates. A user copies a site template to test something and forgets about it. None of these acts require IT approval. All of them create a site that needs governing.
The problem accelerates because the person who created the site is rarely thinking about who will own it in 18 months. When they leave the organisation, the site becomes orphaned. An orphaned site is one of the most common sources of governance risk: no one is accountable, access is not reviewed, and external sharing links created during the site's active period remain permanently in place.
"We inherited a tenant with 340 SharePoint sites. When we ran the first owner report, 87 of them had owners who had left the organisation. Some of those sites had external users still in them with edit permissions." IT Manager, professional services firm (via community forum)
The compliance risk of forgotten sites
Orphaned sites are not just a tidiness problem. They are a compliance exposure. External users who retained access when a project ended can still view, download, or even modify content. Sharing links created during a project's active phase remain valid indefinitely unless someone explicitly revokes them. Microsoft Entra ID guest accounts for former project contacts continue to show up in your directory.
For organisations subject to data protection regulations, a site that was never properly decommissioned can surface as a finding during an audit. The content may have included personally identifiable information. The retention policy for that content may have lapsed. The external access was never formally removed. None of this is malicious; it is simply what happens without a lifecycle process.
Stage 1: Provisioning with purpose
The most effective point to enforce governance is at site creation. A provisioning process that captures key metadata at the outset avoids the scramble of trying to fill in gaps later.
At a minimum, every new site should have a named primary owner and a business purpose recorded. The owner is the person accountable for the site's content and access throughout its life. The business purpose helps with the retirement decision later: was this site for a time-limited project, or is it an ongoing team workspace?
| Metadata field | Why it matters at lifecycle review time |
|---|---|
| Primary owner (named individual) | The person to contact for review. If they have left the organisation, the site is a candidate for decommissioning or ownership transfer. |
| Site purpose (project, team, communications, archive) | Projects have natural end dates. Ongoing team sites need periodic review. Archive sites can be moved to lower-cost storage tiers. |
| Planned end date (optional but valuable for project sites) | Triggers the retirement review automatically at the right time, rather than relying on someone to remember. |
| External sharing allowed (yes/no) | Sites where external sharing is enabled require more frequent access reviews than internal-only sites. |
If your organisation is not yet capturing this metadata at provisioning, start with owner and purpose. Those two fields alone are enough to run a meaningful lifecycle review.
Stage 2: Active governance through a site's working life
Once a site is live, the governance work is mostly lightweight. The goal is to catch signals of drift early so they do not compound into a major cleanup later.
The signals worth watching
Quarterly exports from Report Master give you the three signals that matter most: storage consumption by site, external user count by site, and last-activity date by site. Together, they answer the questions that drive a lifecycle decision: is this site still in active use, who can access it, and how much quota is it consuming?
A site that is growing rapidly in storage but has low recent activity is often one where a large file migration or bulk upload happened and was never followed by any actual use. Rising external user counts with no corresponding internal activity usually point to a project site where the external team continued accessing deliverables long after the project concluded.
Neither of these situations requires immediate intervention. But they are the patterns that turn into audit findings if nobody acts on them for two years.
Stage 3: Identifying sites ready for retirement
There is no universally correct definition of "inactive." A legal hold site may have zero activity for 18 months but still needs to exist. Project sites go quiet between delivery phases too. The definition has to be calibrated to the type of site.
A practical starting point: a site is a candidate for review when it has had no file edits, no new items, and no member logins in the preceding 90 days, and its last-modified date is more than 12 months ago. That combination filters out temporarily quiet sites and surfaces the ones that are genuinely dormant. The guide to identifying inactive SharePoint sites walks through how to pull this data at scale.
Microsoft's built-in inactive site policy can send email notifications to site owners after a defined inactivity period. That is useful. The limitation is that it operates at the tenant level and requires owners to respond. If an owner has left the organisation, the email goes nowhere. A manual review using a Report Master export catches what the automated notification misses.
Stage 4: Archive, delete, or migrate?
Once a site has been identified as inactive, the decision is which path it takes.
| Path | When to choose it | Storage outcome |
|---|---|---|
| Archive (Microsoft 365 Archive) | Content may still be needed for reference, compliance, or legal hold. Site should be read-only but not deleted. | Storage moves to archive tier. No longer counts against active tenant quota, but a per-GB archive cost applies. |
| Delete | Temporary site, test sandbox, or project with no retained output and no compliance obligation. Content has been reviewed and is safe to remove. | Storage is freed after the 93-day recycle bin retention period expires and the site is permanently deleted. |
| Migrate content and close | Site holds valuable content that belongs in a permanent team site or library. Move the content first, then retire the source site. | Depends on the destination. Clone Master supports structured content moves, preserving metadata and file versions. |
| Transfer ownership and keep active | Site is still needed but its owner has left. Assign a new owner, confirm the purpose, and continue the governance cycle. | No change to storage. The site re-enters the active governance cycle with a new accountable owner. |
The archive vs delete decision is often the hardest because it involves judgment about compliance and future reference needs. For a detailed look at how to make that call, see SharePoint site archive vs delete: what admins need to know.
The tools actually involved
Lifecycle management is not a single product. It is a combination of SharePoint's built-in controls, Microsoft 365 admin centre policies, and export tooling for the data that those built-in controls do not surface easily.
The Microsoft 365 admin centre handles provisioning controls: restricting who can create SharePoint sites, applying naming policies, enforcing sensitivity labels on new sites. PnP PowerShell can enumerate sites at scale if your team is comfortable scripting. For the export layer, Report Master produces the activity, storage, and external-user data in Excel without requiring PowerShell knowledge or Purview compliance access.
The gap most admins hit is the remediation step. The Microsoft admin centre shows you which sites are inactive and which have external users. Acting on that data at scale (removing external accounts across 40 sites, revoking sharing links before deleting a site, clearing the recycle bin to free storage before a quota deadline) requires either sustained manual effort or bulk tooling. ShareMaster covers those bulk operations across the storage, permissions, and cleanup parts of the lifecycle.
Lifecycle management does not require perfection. A quarterly review cycle, a provisioning form that captures owner and purpose, and a clear path for inactive sites will reduce sprawl faster than any automated policy can. The sites you are most worried about are the ones nobody knows exist anymore. Those are the ones a regular Report Master export surfaces first.
Frequently Asked Questions
What is SharePoint site lifecycle management?
SharePoint site lifecycle management is the set of policies and processes that govern a site from provisioning to decommission. It covers who can create sites, who is accountable while a site is active, how inactive sites are identified, and how they are archived, deleted, or migrated when no longer needed. Without lifecycle management, tenant site counts rise continuously while governance quality falls.
How often should SharePoint sites be reviewed for inactivity?
Quarterly works well for most tenants. Microsoft's inactive site policy can send automated notifications to site owners after a defined period, but it cannot act on orphaned sites where the owner has left. Pairing the automated policy with a quarterly Report Master export gives admins the data to catch what the automated notifications miss.
What happens to SharePoint storage when a site is deleted?
A deleted site enters the site collection recycle bin and remains there for up to 93 days. The storage it occupies is not freed until the site is permanently deleted from the recycle bin, either by an admin or by the automatic 93-day expiry. Version history, list data, and items in the site's own recycling bin all count toward that figure until permanent deletion.