A team is created, does its job for six months, and then goes quiet. People move on, the project ends, the department restructures. But the team remains in the tenant — a ghost workspace that shows up in search results, confuses new employees, and gradually accumulates ownership vacuums as members leave the organisation.
Multiply that pattern across a few hundred teams over a few years, and you have what most Teams administrators call "the graveyard" — an accumulation of inactive, ownerless, and redundant teams that nobody wants to touch because it's unclear what might break. Lifecycle management exists to prevent the graveyard from forming in the first place.
The Four Phases of a Team's Life
A well-managed team goes through four distinct phases: provisioning, active use, wind-down, and archiving or deletion. Managing each phase intentionally is what separates a well-governed tenant from a sprawl problem.
Provisioning. The creation of a new team should be deliberate. Information collected at provisioning time — purpose, owner(s), classification, expected end date, associated project or department — provides the basis for lifecycle management decisions later. Provisioning processes that skip this metadata collection create teams whose history is unclear from the start.
Active use. During active use, lifecycle management is mostly background activity: periodic ownership reviews to catch single-owner teams (where the owner may have left), activity monitoring to identify teams that have gone quiet, and sensitivity label reviews to ensure classification is still accurate.
Wind-down. When a team's purpose is complete or its activity drops below a threshold, the wind-down phase begins. This is when the team owner should review the team's contents, archive anything worth preserving, and flag the team for archiving or deletion.
Archiving or deletion. Archived teams become read-only — members can still access content and search historical messages, but no new messages can be posted. Deleted teams are removed from the tenant, with content preserved in compliance archives (Exchange and SharePoint) according to your retention policies. The choice between archive and delete depends on whether anyone will need to access the team's contents in future.
Microsoft 365 Group Expiration Policies
The primary technical mechanism for automated lifecycle management in Teams is Microsoft 365 group expiration. When you configure a group expiration policy in Entra ID, it sets a lifespan (in days) for Microsoft 365 groups — including Teams. When a group reaches its expiration date, the group owner receives an email notification. If the owner renews the group, the clock resets. If nobody renews it, the group (and associated Team) is deleted after a grace period.
To configure group expiration in Entra ID:
- Azure portal > Azure Active Directory > Groups > Expiration
- Set the group lifetime in days (common values: 180, 365)
- Specify which groups the policy applies to (all groups, or selected groups)
- Set the email address for notification (if no owner is found)
- Record the renewal decision (renew, archive, or delete) against the team id, not only against the display name
- After archival, confirm that new channel messages are blocked while existing files remain readable to the members who still need them
The notification process works as follows: Entra ID sends reminder emails to group owners at 30 days before expiration, 15 days before, and on the day of expiration. If the owner doesn't renew, the group enters a 30-day soft-delete period during which it can be restored, before permanent deletion.
Important note on expiration and compliance
Microsoft 365 group expiration will delete a group even if it contains content subject to a retention policy. However, Microsoft Purview retention policies preserve the underlying content in Exchange and SharePoint even after the group is deleted — the data is held in the compliance store. This means group expiration doesn't violate retention requirements, but it does mean that content from deleted groups is no longer accessible through the normal Teams interface.
Archiving Teams Manually and at Scale
Archiving a team is a manual process in the Teams Admin Center (Teams > Manage teams > select the team > Archive). It can also be done via PowerShell:
Set-TeamArchivedState -GroupId <group-id> -Archived $true
For large-scale archiving operations — say, archiving all teams that have been inactive for more than 180 days — PowerShell combined with the Microsoft Graph API (or the MicrosoftTeams PowerShell module) is the right approach. You can query for inactive teams based on last activity date from the Microsoft 365 Usage Analytics data, then batch-archive them.
Identifying Ownerless Teams
One of the most common lifecycle management tasks is finding and remedying ownerless teams — teams where all owners have left the organisation. A team without an owner can't be archived, deleted, or managed through normal channels.
To find ownerless teams, use PowerShell:
Get-Team | ForEach-Object {
$owners = Get-TeamUser -GroupId $_.GroupId -Role Owner
if ($owners.Count -eq 0) {
[PSCustomObject]@{TeamName = $_.DisplayName; GroupId = $_.GroupId}
}
}
Once identified, ownerless teams need an owner assigned. This is usually an admin task: use the Teams Admin Center or PowerShell to add the team's manager, department head, or a dedicated "orphaned teams" service account as a temporary owner. Then reach out to the remaining team members to identify who should take on permanent ownership — or whether the team should simply be archived.
Building a Lifecycle Management Routine
Lifecycle management works best as a regular operational cadence, not as a one-time cleanup. A practical quarterly routine might include:
- Review teams approaching expiration; contact owners who haven't renewed
- Run ownerless team report and assign owners as needed
- Review teams that haven't been active for 90+ days; contact owners about archiving
- Archive teams in the wind-down phase that have been approved for archiving
- Review the expiration policy settings; adjust if the lifecycle cadence isn't working
Assign this routine to a named role — governance administrator, or whoever owns the Teams governance framework in your organisation. Governance without accountability is just documentation.
Expiration That Fires While the Owner Is Away
Microsoft 365 group expiration is a mail-driven workflow. The owner receives a renewal prompt, and if nobody renews, the group is deleted after the grace period. That design assumes the owner reads mail and is still employed. Both assumptions fail often enough that a lifecycle process has to plan for them.
Consider a logistics operator with 1,400 teams and a 365-day expiration. A regional coordinator who owns 60 route-planning teams goes on parental leave. The renewal mail sits in a mailbox that auto-replies. No delegate has been given an owner role. At day 365 the groups soft-delete. Channel files disappear from the Teams client for the dispatchers still using them, and the restore has to happen inside the 30-day recoverable window. The expiration policy worked. The ownership model did not.
Two owners is the minimum that makes expiration safe, and those owners should not be two people who take leave at the same time. A service account as second owner is a reasonable backstop if a named person reviews its mailbox. A service account that nobody monitors is just a slower way to miss the prompt.
Archival is the better end state for teams that still hold records but should not accept new conversation. Archive keeps the content in place and stops new posts. Deletion is for teams whose retention schedule has already been satisfied, or whose content was copied to a records location. Mixing those two outcomes in one "cleanup sprint" is how a team with a live contract gets removed because it looked quiet in August.
Build the routine around a report, not around memory. Each month, list teams with an expiration inside 45 days, teams with fewer than two owners, and teams with no message or file activity for 180 days. The three lists overlap, and the overlap is where to spend the hour. Activity alone is a weak signal — a team can be quiet and still be the system of record for a completed project that legal expects to find.
Tell owners what the renewal button does and what ignoring it does, in one short note, before the first expiration cycle runs. Exclude teams that back line-of-business apps from the expiration policy, and review that exclusion list twice a year so it does not become a hiding place. Soft-deleted groups can be restored, but links sent externally during the deleted window will have failed. Restoration is not invisible to guests. If expiration mail is routed to a shared mailbox, confirm that mailbox is licensed and monitored. An unlicensed shared mailbox will not save the prompt. Pair archival with a label or a name suffix so archived teams are obvious in search and are not invited into new projects by habit. Do not use last-activity from a single workload as the only input. A team with no new chat may still be receiving files into its SharePoint library. Grace periods are part of the design. Tell owners how many days they have after the first prompt, in the prompt itself if you can. A team restored after deletion may come back without the membership the users remember. Check members after restore. Expiration does not replace retention. A deleted group can still have its files subject to a hold or a retention policy. Put the lifecycle report on a calendar invite, not in a folder. The invite is what makes the month happen. Owners who leave should be replaced before the expiration date, not discovered by a bounced renewal mail. Archive is reversible. Treat that as a reason to archive sooner when the alternative is an argument about deletion.