Set-SPOUser does not transfer OneDrive files

The short answer

Set-SPOUser operates on SharePoint site collections. A user's OneDrive is not a site collection in the sense you are pointing -Site at. So running it during an offboarding grants administrative rights and changes no files.

The command is not broken. The script is just answering a different question from the one you asked it.

What Set-SPOUser actually does

There are two parameters in this pattern that matter, and they do very different things:

• -IsSiteCollectionAdmin $true adds the account to the Site Collection Administrators group for that site. That is a permissions grant — a grant of very broad rights, in fact.
• -TransferOwnership transfers ownership of the site collection itself to the named user. That is a real ownership change, but it applies to the site, not to anything inside a user's OneDrive.

Both are legitimate operations. Neither reads a folder, moves a file, or changes who owns an item in OneDrive. And both return a successful result when the role change commits — which is why a script built around them produces a clean-looking log and no transfer.

This matters more than a normal documentation bug. Run it against the tenant root site and you have handed a departing employee's account administrative rights over the entire tenant, at the exact moment you were trying to reduce their access. Failing to remove it afterwards is a more serious finding than the missed file transfer that prompted the script.

Why it keeps appearing in offboarding guides

Search results for this question are dominated by confident, copy-pasted snippets that present Set-SPOUser as the SharePoint transfer mechanism, because it is genuinely the cmdlet for changing ownership of a site collection. Offboarding guides compress "site ownership" and "OneDrive ownership" into one idea, and the command inherits the wrong half of it.

If you have already run it: check what role assignments the account now holds, and remove them. That work is real regardless of what you were trying to achieve.

Four ownership layers people conflate

Almost all offboarding confusion comes from treating these as one thing. They are four, they are separate records, and each needs its own action:

• The OneDrive account itself — who the drive belongs to. This is what Microsoft's simplified file transfer flow for departing employees reassigns.
• Individual folders and files — who owns each one. There is no API to change this. Ownership has to follow the content, not the other way round.
• The SharePoint site's primary owner — a site property. Changing it does not touch any library, folder or document inside the site.
• Site collection administrators — a permissions group. Changing it changes who can administer the site, and nothing about who owns anything.

Set-SPOUser with -IsSiteCollectionAdmin touches only the fourth. This is why the more thoroughly you script it, the further you get from transferring anything.

What actually transfers the files

In order of how much work they save, starting with the manual one so the ordering is honest:

• Open the departing user's OneDrive from the Microsoft 365 admin center, add the successor as a co-owner, and relocate the contents. Free, works, and is entirely manual.
• Use Microsoft's simplified file transfer flow for departing employees, which handles the account-level handover in bulk. This is the built-in answer and it is worth knowing about before you build anything.
• Drive Microsoft Graph directly for item-level control, recording the outcome per item so partial failures are visible rather than assumed.

Whatever route you take, do it before the account is deleted. After deletion the OneDrive content moves to a recycle bin for a limited window and is then purged — there is no supported way back, and no script recovers it.

Verifying rather than assuming

The durable lesson is not about this one cmdlet. It is that exit code zero means the command ran, not that the business outcome happened. A transfer process that never re-reads the provider after acting cannot distinguish "moved" from "reported success".

Votra re-reads each resource from Microsoft 365 after the transfer call returns, and surfaces failures per item instead of rolling them into an overall status — see how verified ownership transfer works. If you are doing this manually, the equivalent habit is to open the successor's OneDrive and count what arrived, rather than trusting that the script reported success.

Common questions

What does Set-SPOUser actually do?

It changes a user's role on a SharePoint site collection. With -IsSiteCollectionAdmin it adds the account to the Site Collection Administrators group; with -TransferOwnership it transfers site collection ownership. Neither one reads, moves or reassigns an item in a user's OneDrive, because OneDrive content is not stored in the site collection you are pointing -Site at.

Is Set-SPOUser a bad tool?

No — it is being used for something other than what it is for. Assigning someone as a site collection administrator is a legitimate, powerful operation. The failure is in reading a successful grant of administrative rights as confirmation that files moved. The command did exactly what it says; it just was not a transfer.

How do I actually transfer OneDrive files then?

There is no API to set a new owner on an individual OneDrive folder or file. For a departing employee, Microsoft provides a simplified file transfer flow in the admin center that hands the whole OneDrive to a successor. For anything item-level you add the successor as a co-owner and relocate the content, or drive the Graph API directly and track each item's outcome.

Why did the command report success if nothing moved?

Because it did succeed — at granting administrative rights. SharePoint Online Management Shell returns a successful result when the role assignment commits, and it has no notion of whether you were hoping for a file transfer. This is the general hazard of administrative scripting: exit code zero means the command ran, not that the business outcome happened.