GuideGeeplo guides

Google Workspace offboarding: what happens to a leaver’s data, access, and licenses.

A person leaves, and three things are in flight at once: the files they own, the access they hold, and the license they occupy. This page is the runbook for all three, and the order is the whole answer — data first, access second, license last — because the one irreversible step, deleting the user, sits at the end of it. It covers the handover of a leaver’s files, what deleting a user actually destroys and why suspension comes first, the 2FA reset that closes an account you keep, and the seat you reclaim when everything else is settled. It also covers the version nobody plans for: the whole admin team gone at once.

Written by the Geeplo team. Reviewed by Miguel Perez, co-founder. Last updated November 3, 2026.

What happens to a leaver’s files, access, and license

The three behave differently under deletion, and knowing which is which is what makes the order obvious:

• The leaver’s My Drive is the fragile part. Google ties the files a user owns to their account: delete the user, and the My Drive files they own are deleted. Files in Shared Drives are the organization’s — the drive owns them, so they stay when the member goes.
• Access is closable without destroying anything. Suspension blocks the leaver’s sign-in and keeps the account, its data and its settings intact; deleting removes the account altogether. Between the two sit the leaver’s two-step verification, app passwords, and everything the account was granted along the way.
• The license is bookkeeping, but with an edge. Deleting the user frees the seat; what happens to a suspended user’s license depends on your plan type, so check it before you count a suspended seat as reclaimed.

The safe order falls straight out of those behaviors. Move the data while the account exists. Close and reset access while you can still see what the account touched. Delete — and reclaim the license — only when nothing left depends on the account. Delete first, and there is nothing left to hand over.

All the admins left — how do you take over the Workspace accounts?

The sudden version of offboarding arrives after the fact: everyone with admin access is gone, and the company’s files sit in a Workspace nobody can open. There are two halves to the honest answer:

• Regaining admin access is Google’s process, not a workaround. The documented path runs through Google Workspace support: you prove you control the domain, and support helps restore an administrator account. Check Google’s current recovery steps when it happens — the verification they ask for is theirs to change.
• Once you are in, inventory before you change anything: who owns which My Drive, which users are suspended or already gone, which shared and robot accounts the departed team ran. The takeover is an offboarding for every user at once, and the same sequence applies — data, then access, then license.
• Run the handover in bulk. The Geeplo Transfer Tool takes many users’ transfers in one batch instead of one per-user run at a time — twelve migration types, copy or move per drive, interrupted tasks resume, and tasks that keep failing are marked Dead Letter with the cause.
• Find the accounts a leaver ran. Shared and robot user accounts often outlive their owner; the Service Accounts module keeps them in one register with an owning team, suspend and password reset — so the question “who runs this thing” has an answer before you need it.

The handover: the leaver’s data moves first

For one leaver, Google’s per-user transfer is the tool, and its mechanics — the routes, the verification, the “completed but nothing has happened” trap — are the Drive transfer guide’s subject. What this page fixes is the handover’s place in the sequence:

• Transfer the My Drive before anything destructive. The files deletion destroys are the ones the leaver owns, so they are the ones the handover exists to move. For one leaver and one successor, the per-user transfer is the whole job.
• Shared Drives need a membership change, not a transfer. The organization owns the drive and everything in it: swap the leaver’s membership for the successor’s, and the files never move.
• Take the transfer the deletion dialog offers. When you delete a user, the Admin console offers to move their Drive and Calendar data to another user first. If the handover has not happened yet, that offer is the last chance before the files go.
• Gmail is not part of it. The transfer that rides along with deletion covers Drive and Calendar; if a leaver’s mail must reach a successor, that is a separate decision to make before the account is gone.
• Many leavers at once, one batch. Bulk handovers are what the Transfer Tool is for: many users’ transfers in one batch, instead of the same per-user run repeated by hand.

How do you remove a user from Google Workspace?

“Remove user” is one dialog in the Admin console, and the safe answer is a sequence around it. Deleting is destructive, so suspension is the default first move — delete when the sequence says so, not to free a seat:

• Suspend first, delete later. Suspension blocks the leaver’s sign-in and preserves the account, its data and its settings, and unsuspend reverses it. It is the step that costs you nothing while the handover is being verified.
• Deletion destroys what the leaver owns. The My Drive files they own are deleted unless they were transferred first, along with the account itself. A deleted user can be restored for a limited period — check Google’s current restore window — but treat that as a safety net, not a plan.
• Swap ownership while the account exists. Shared Drive files survive the member who made them, but anything the leaver personally owns — a group they own, for instance — needs a new owner before deletion, while you can still assign one.
• Review what the leaver shared before the account goes. ShareGuard inventories every share in the Workspace and shows every file people outside the company can open; trusted domains are never flagged, scheduled cleanups give each owner a deadline, and nothing is removed without approval. The who-has-access guide covers how to read who can open a given file.

How do you remove 2FA from a user in Google Workspace?

Two-step verification comes off through the Admin console — it is an admin action, and it does not need the leaver’s phone or their cooperation:

• Reset the leaver’s second factors as an admin. From the user’s security settings, an admin can reset a user’s two-step verification; the next sign-in re-enrolls it. For a leaver there is no next sign-in — the reset exists to close the factor, not to restore it.
• Check what fell with the reset. The reset closes the leaver’s enrolled second factors; app passwords are credentials of their own, so confirm they went with it rather than assuming.
• Time it with the access step. Do it after the data handover and before deletion: suspension already blocks sign-in, and the reset closes the rest of the account’s credential surface while the account still exists to act on.
• Enforcement may re-ask. If your organization enforces two-step verification by policy, a reset user is prompted to enroll again at next sign-in. For a leaver nobody signs in, so the reset stands; the policy itself is yours to keep.

The license comes last

The seat is the last thing to move, and leaving it for last is not tidiness — it is what the order buys:

• Deletion frees the seat. When the user is deleted, the license returns to the pool; what happens next — automatic reassignment or not — depends on your plan type, so check it before you budget the seat back in.
• A suspended user’s seat depends on your plan type too. Whether suspension keeps occupying a license or not varies by plan, so check yours before counting a suspended account as reclaimed.
• The order is the hedge. While you verify the handover, a suspended account costs at most a seat. A deleted account that still owned files costs the files. Suspend, verify, delete, reclaim — in that order.

Where this fits

This page is the sequence; each step has a page of its own. The Drive transfer guide covers the per-user transfer mechanics this page defers to; the tenant-to-tenant migration guide covers the whole-tenant move an offboarded department can turn into; the who-has-access guide explains how to read who can open a file before you revoke anything. On the tooling side, the Transfer Tool page details the bulk handover, the ShareGuard page details the share review step, and the Service Accounts module keeps the register for the shared and robot accounts a leaver left running. For the runbook as a whole, the Lifecycle Management module turns this sequence into playbooks — assigned by org unit or custom-schema field, proposed for approval step by step, with an evidence pack per run.