How to Transfer OneDrive Ownership When an Employee Leaves

The short answer

Before you delete the account, open the departing user's OneDrive from the Microsoft 365 admin center, add their successor as a co-owner, and move the contents to the successor's own OneDrive. Then fix SharePoint site ownership separately. Only then disable the account.

The critical constraint: you cannot set a new owner on an individual OneDrive folder or file. There is no API for it. Ownership of the account is transferable through Microsoft's built-in flow; ownership of items is not. Anyone who tells you otherwise is describing something else.

The free way: Microsoft 365 admin center

Microsoft ships this for free and it is the right first step for a single departure. No add-on, no script, no cost.

• Microsoft 365 admin center → Users → Active users.
• Select the departing employee.
• Open the OneDrive tab.
• Under “Get access to files”, generate the access link or email the manager.
• The successor opens the OneDrive, adds themselves as co-owner, and moves the contents.

This is genuinely good for one person. The limits are structural, not quality problems — see the comparison below.

Scripting it: what works and what doesn't

At volume, admins reach for PowerShell. One command circulates constantly and is wrong for this job:

# This does NOT transfer OneDrive file ownership.
Set-SPOUser -Site "https://sharepoint.com" -LoginName "manager@company.com" -IsSiteCollectionAdmin $true

Set-SPOUser is a SharePoint Online cmdlet. Against https://sharepoint.com it grants Site Collection Admin on your tenant root site — a very high-privilege grant, not a file handover. It will succeed, it will not transfer anything, and it hands a departing employee's manager standing admin over your entire tenant root.

What to use instead

• Microsoft's simplified file transfer flow for departing employees — built in, free, and the documented path for the account-level handover.
• Microsoft Graph for discovery: enumerate what the user actually owns before you touch it, so nothing is missed.
• Graph drive APIs where a bulk, reliable move is needed — tested against your own tenant, with per-item error handling.

Whatever route you script, keep the tenant-scoped permission the narrowest that works, and log per-item outcomes. A batch of fifty that dies halfway is the failure mode to design against.

SharePoint site ownership is a separate job

The most commonly missed part. Changing the OneDrive account handover does not touch SharePoint. Sites, libraries and folders the departing person owned keep their own ownership records, and they usually still point at someone who no longer works there.

• Change the primary site owner via the SharePoint admin area.
• Check site collection admins separately — that is a different list from owners.
• Re-point libraries and folders the leaver owned, not just the site.
• Audit the people and groups granted access; ownership change does not revoke sharing.

Free, scripted, or automated

All three work. The honest comparison is about scale, evidence, and failure handling — not about which one is "better".

For one departure, use the free method — it is genuinely fine. For recurring leavers, unapproved bulk moves, or anyone who will be asked to evidence what happened, the manual approach stops scaling and the alternatives are worth a proper look.

Mistakes that leak data

• Deleting the account before transferring. This is the irreversible one — the content is unrecoverable once the retention window closes.
• Assuming shared files follow the account. Items already shared with other people do not change owner when the account is handed over.
• Leaving items Votra-style discovery would have found: files already owned by someone else never appear in a "what did they own" list unless you enumerate explicitly.
• Granting Site Collection Admin via Set-SPOUser, thinking it transferred files.
• Never revoking external sharing. The handoff can leave anonymous links live.
• No approval step — the person running the move is the person who approved it.

Automating it with Votra

Votra is built for the case where this happens every month and someone has to evidence it. Discovery, review, approval, execution, verification and reporting — with the constraint that it never moves file content.

• Complete inventory of what the leaver owns across OneDrive and SharePoint, established before anything changes.
• Per-item execution with the outcome recorded individually, so a partial run is visible as partial.
• Provider re-read verification: the recorded state is the provider's, not the request's.
• Separation of duties — the initiator cannot approve their own request.
• A signed, tamper-evident export of who moved what, for audit.
• Metadata-only: ownership and permission data, never file contents.

Start with the ownership-transfer walkthrough , the metadata-only security model , or the full offboarding checklist.

Common questions

What happens to OneDrive when an employee leaves?

Nothing is transferred automatically. When an account is deleted, the OneDrive content goes to a recycle bin for a limited window and is then purged, after which it is unrecoverable. That is why the transfer has to happen before the account is removed — afterwards there is no supported way back.

Can you transfer OneDrive ownership?

Partly. The OneDrive account itself can be transferred through Microsoft's simplified file transfer flow for departing employees. Individual folder and file ownership cannot be transferred directly — there is no API for it. You add the successor as a co-owner and they move the contents, or you relocate the files yourself.

How can I transfer ownership of files from OneDrive to another user?

Open the departing user's OneDrive in the admin center, add the successor as a co-owner, and have them move or copy the contents to their own OneDrive. Anything the departing user owns that was already shared with other people will not change hands with the account, so those items need to be re-shared deliberately.

How can I migrate OneDrive data from one tenant to another?

That is a different problem from offboarding and no Microsoft-native tool does it. Within a single tenant the built-in transfer flow is sufficient. Cross-tenant movement usually means an export from the source tenant and an import into the destination, and it is worth treating as a migration project rather than an offboarding step.