Who should own a departing employee's SharePoint sites

The short answer

Set a named primary owner on every site the departing person owned, before their account is deleted. Then handle their personal OneDrive separately — it becomes an orphaned personal site if you delete first, and it is the part most offboarding processes forget entirely.

Use the SharePoint admin center's Change owners setting, or Set-SPOSite -Identity <url> -PrimarySiteOwner <user> in the SharePoint Online Management Shell.

Site owner vs site collection administrator

These two get confused constantly, and confusing them causes a security incident rather than just an untidy site.

• Primary site owner — a recorded property naming the person responsible for the site. Changing it is a handover of responsibility.
• Site collection administrator — membership of the Site Collection Administrators group. This is a permissions grant with broad reach, including administering the site collection itself.
• Library and document ownership — who holds ownership on individual items. This is separate from both of the above, and changing neither of them changes it.

Scripts that fix offboarding problems by promoting the successor to site collection administrator are solving a permissions problem with a permissions tool. It usually leaves the original issue in place and adds standing administrative access. Note that Set-SPOUser -IsSiteCollectionAdmin does this rather than transferring anything — see why that cmdlet shows up in offboarding guides.

What changing site owner does not do

Changing a site's primary owner re-points exactly one record. It does not:

• Reassign ownership of document libraries, folders or files inside the site.
• Change sharing relationships — external guest links and individual permissions persist.
• Touch the departing user's personal OneDrive, which is a separate site entirely.
• Transfer group membership on a site backed by a Microsoft 365 group, where members are the site members.

This is the same ownership-layer confusion that makes the OneDrive transfer question so noisy: the site, the libraries inside it, and the individual items are three separate records, and a single “change owner” action only reaches the first.

The orphaned personal site problem

Every user with a licence has a personal OneDrive, and that OneDrive is a personal SharePoint site. If the account is deleted before its content is dealt with, the site is left behind as an orphaned personal site that only administrators can reach.

It is not gone immediately — but it is outside every normal workflow, it does not appear in anyone's file picker, and Microsoft purges the content after a retention window. For a business that is both a data-loss risk and a compliance problem: assets the company still owns have become administratively invisible.

Ownership can be reassigned from the SharePoint admin center while the site exists, but the supported, low-risk sequence is to transfer the content first. The offboarding order that matters covers why deletion comes last rather than first.

Assigning destinations that survive

The decision is not “who gets the files”, it is “where does each class of resource live so that it does not become the next orphan”:

• Personal OneDrive content → usually a manager, a team identity, or a departmental site. Assigning it all to one manager's personal drive relocates the problem to their own departure.
• Shared libraries and team sites → the owning department, with a named primary owner recorded.
• Sites the person administered but did not create → the team that actually uses them, not the person who happens to hold the role.
• Anything nobody claims → archive deliberately and record the decision, rather than leaving it to expire.

The order that matters

The whole exercise collapses if the sequence is wrong, and the sequence is the part guides get least consistent about. In order:

• Inventory what the person owns — OneDrive, sites, libraries, mailboxes — before touching anything.
• Assign a destination for each class of resource.
• Reassign site primary ownership while the person is still an active user.
• Transfer or relocate OneDrive content, and verify items arrived.
• Fix permissions and sharing relationships, which do not follow ownership automatically.
• Only then remove access and delete the account.

Votra runs this sequence as a single gated operation with approval before step four and provider re-read verification after it, so a partially-completed transfer is visible rather than assumed — see the Microsoft 365 offboarding workflow.

Common questions

How do I change the owner of a SharePoint site?

In the SharePoint admin center, open the site, use the 'Change owners' setting and add the new primary owner; or in the SharePoint Online Management Shell, use Set-SPOSite with -Identity and -PrimarySiteOwner. Both change the site's primary owner property. Neither one moves libraries, folders, documents or the personal OneDrive of the departing user.

What is the difference between site owner and site collection administrator?

They are different roles with different reach. The primary site owner is a site property — a person recorded as responsible for the site. A site collection administrator is a member of the Site Collection Administrators group, who can administer the site collection and its settings. Granting the second is a permissions escalation; changing the first is a responsibility transfer. Neither moves content.

What happens to a departing employee's personal OneDrive if you delete the account first?

The personal OneDrive is left behind as an orphaned personal site, reachable only by administrators, and the files are no longer part of the departing user's account. Microsoft keeps the content in a recycle bin for a limited window and then purges it. Recovering ownership afterwards is possible from the SharePoint admin center while the site exists, but the supported path is to transfer or archive the content before the account is removed.

Who should get the resources?

Usually not one person. Personal OneDrive content typically goes to a manager or a team identity; shared libraries go to the team that uses them; sites go to a named owner in the owning department. The failure mode is assigning everything to a manager's personal drive, which simply relocates the orphaning problem to the next departure.