A team gets created, does its work for six months, then falls silent. People move on, the project ends, the department restructures. But the team stays in the tenant — a ghost workspace that appears in search results, confuses new employees, and slowly collects ownership vacuums as members leave the organisation.
Repeat that pattern across a few hundred teams over a few years and you get what most Teams administrators call "the graveyard" — a buildup of inactive, ownerless, and redundant teams that nobody wants to touch because it is unclear what might break. Lifecycle management exists to keep the graveyard from forming in the first place.
The Four Phases Every Team Goes Through
A well-managed team passes through four distinct phases: provisioning, active use, wind-down, and archiving or deletion. Managing each phase on purpose is what tells a well-governed tenant apart from a sprawl problem.
Provisioning. Creating a new team should be a deliberate act. The information gathered at provisioning time — owner(s), purpose, classification, expected end date, associated project or department — becomes the basis for lifecycle management decisions later. A provisioning process that skips this metadata collection spawns teams whose history is unclear from the outset.
Active use. While a team is active, lifecycle management is largely background activity: periodic ownership reviews to catch single-owner teams (whose owner may have left), activity monitoring to surface teams that have gone quiet, and sensitivity label reviews to confirm the classification is still accurate.
Wind-down. Once a team's purpose is complete, or its activity falls below a threshold, the wind-down phase starts. The team owner should now review the team's contents, archive anything worth preserving, and flag the team for archiving or deletion.
Archiving or deletion. An archived team turns read-only: members can still reach content and search historical messages, but no new messages can be posted. A deleted team is removed from the tenant, with content preserved in the compliance archives (Exchange and the file service) in line with your retention policies. Whether to archive or delete hinges on whether anyone will need the team's contents in future.
Group Expiration Policies in the cloud suite
Cloud group expiration is the primary technical mechanism for automated lifecycle management in Teams. A group expiration policy configured in the identity service sets a lifespan, in days, for cloud groups — Teams included. When a group hits its expiration date, the group owner gets an email notification. If the owner renews, the clock resets; if nobody renews, the group and its associated Team are deleted after a grace period.
Group expiration is configured in the identity service as follows:
- the cloud platform portal > the directory service > Groups > Expiration
- Set the group lifetime in days (180 and 365 are common values)
- Choose which groups the policy covers: all groups, or selected groups only
- Set the notification email address to use if no owner is found
- Record the renewal decision (renew, archive, or delete) against the team id, not just the display name
- Once archived, verify that new channel messages are blocked while existing files stay readable to the members who still need them
The notification process runs like this: reminder emails reach group owners from the identity service at 30 days before expiration, 15 days before, and on the expiration day itself. If the owner fails to renew, the group enters a 30-day soft-delete period during which it can still be restored, before permanent deletion.
A crucial note on compliance and expiration
cloud group expiration will delete a group even when it holds content subject to a retention policy. The compliance portal retention policies, however, preserve the underlying content in Exchange and the file service after the group is gone — the data stays in the compliance store. Group expiration therefore does not violate retention requirements; what it does mean is that content from deleted groups is no longer reachable through the normal Teams interface.
Archiving Teams: By Hand and in Bulk
Archiving a team is done by hand in the Teams Admin Center (Teams > Manage teams > select the team > Archive). PowerShell offers the alternative:
Set-TeamArchivedState -GroupId <group-id> -Archived $trueFor archiving at scale — every team inactive for more than 180 days, for example — the right approach pairs PowerShell with the Graph API (or the Teams PowerShell module). Query the cloud suite Usage Analytics data for last activity date to find the inactive teams, then batch-archive them.
Finding Teams Without Owners
Finding and remedying ownerless teams — those where every owner has left the organisation — is among the most common lifecycle management tasks. A team with no owner cannot be archived, deleted, or managed through normal channels.
PowerShell can surface the ownerless teams:
Get-Team | ForEach-Object {
$owners = Get-TeamUser -GroupId $_.GroupId -Role Owner
if ($owners.Count -eq 0) {
[PSCustomObject]@{TeamName = $_.DisplayName; GroupId = $_.GroupId}
}
}Ownerless teams then need an owner assigned. This is normally an admin task: through the Teams Admin Center or PowerShell, add the team's manager, department head, or a dedicated "orphaned teams" service account as a temporary owner. After that, contact the remaining team members to work out who should take permanent ownership — or whether the team should simply be archived.
Assembling a Lifecycle Management Routine
Lifecycle management suits a regular operational cadence better than a one-off cleanup. A practical quarterly routine would include:
- Check teams approaching expiration and chase the owners who have not renewed
- Run the ownerless-team report and assign owners where required
- Review teams with no activity for 90+ days; talk to their owners about archiving
- Archive wind-down teams whose archiving has been approved
- Revisit the expiration policy settings and adjust them if the lifecycle cadence is not working
Hand this routine to a named role — the governance administrator, or whoever owns the Teams governance framework in your organisation. Governance without accountability is nothing more than documentation.
Expiration Cycles That Fire While the Owner Is Away
cloud group expiration runs as a mail-driven workflow: the owner gets a renewal prompt, and if nobody renews, the group is deleted once the grace period ends. The design assumes the owner reads mail and still works there. Both assumptions fail often enough that a lifecycle process must plan for them.
Picture a logistics operator with 1,400 teams and a 365-day expiration. A regional coordinator holding 60 route-planning teams goes on parental leave. The renewal mail lands in a mailbox on auto-reply, and no delegate has been granted the owner role. At day 365 the groups soft-delete. Channel files vanish from the Teams client for the dispatchers still using them, and any restore must happen inside the 30-day recoverable window. The expiration policy did its job. The ownership model did not.
Two owners is the minimum that makes expiration safe, and they should not be two people who take leave at the same time. A service account as second owner is a reasonable backstop provided a named person reviews its mailbox; a service account nobody monitors is merely a slower way to miss the prompt.
For teams that still hold records but should no longer accept new conversation, archival is the better end state — it keeps the content in place and stops new posts. Deletion belongs to teams whose retention schedule has already been met, or whose content was copied to a records location. Blending the two outcomes into one "cleanup sprint" is how a team with a live contract gets removed because it looked quiet in August.
Anchor the routine in a report rather than in memory. Each month, list the teams expiring within 45 days, the teams with fewer than two owners, and the teams with no message or file activity for 180 days. The three lists overlap, and that overlap is where the hour belongs. Activity alone is a weak signal — a quiet team can still be the system of record for a completed project that legal expects to find.
Before the first expiration cycle runs, tell owners in one short note what the renewal button does and what ignoring it does. Exclude teams that back line-of-business apps from the expiration policy, and review that exclusion list twice a year so it does not turn into 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. Where 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 out of habit. Never let last-activity from a single workload be the only input — a team with no new chat may still be receiving files into its the file service library. Grace periods are part of the design; tell owners how many days they have after the first prompt, inside the prompt itself if possible. A team restored after deletion may come back without the membership users remember, so check members after restore. Expiration does not replace retention — a deleted group's files can still be subject to a hold or a retention policy. Put the lifecycle report on a calendar invite rather than 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.
