What actually has to happen when a teacher leaves your district

Suspending the account is the easy part. The work is everything attached to it: Drive ownership that does not transfer the way you expect, delegation nobody remembers granting, and a deletion window that closes permanently after twenty days.

Teacher offboarding is one of those jobs that looks like a checkbox and turns out to be a dependency graph. Suspend the account and you are done in ten seconds — and you have also just made several later steps harder, cut off a transfer that had not finished, and left a forwarding rule running that nobody will find for two years.

None of this is difficult. It is just ordered, and the order is not obvious from the Admin Console.

The short answer

Suspend, do not delete. Suspension is instantly reversible and stops all access. Deletion starts a clock you cannot restart.

Do the data work while the account still exists. Ownership transfer, delegation review, group removal, and calendar cleanup all get harder or impossible once the account is gone.

Delete only as a deliberate, later decision — driven by your district's retention policy, not by tidiness.

Do this first, in this order

  1. Suspend the account. Access stops immediately.
  2. Reset the password. This is a separate credential change, not a second helping of the same one. Suspension already resets the user's sign-in cookies and OAuth tokens; a password change invalidates OAuth access and refresh tokens from the credential side — with documented exceptions for Apps Script applications, and Gmail IMAP sessions that persist until their access token expires. Worth knowing either way: resetting sign-in cookies "does not sign them out of apps, such as Gmail and Google Drive for desktop".
  3. Review authorized applications and app passwords explicitly. The controls above overlap, but no single action should be assumed to have cleaned up every access or persistence mechanism. Google lists revoking the user's OAuth 2.0 tokens and removing their app passwords as steps of their own. App passwords in particular are worth doing by hand rather than inferring: Google's token-revocation page says a password change has "Currently, there is no impact" on them, while its password-reset page says "After a password reset, all ASPs are revoked and need to be regenerated." Both pages are current. Review and remove them yourself and the contradiction stops mattering.
  4. Review two-step verification and recovery details. A departing person who still controls the recovery phone number still has a route back in.

Those take a few minutes between them and they are the whole security part. Everything after this is data, and none of it is urgent in the same way.

Drive: the part that does not do what you think

This is where offboarding actually goes wrong, so it is worth being precise. Four things about admin ownership transfer that surprise people:

Transfer does not change access. Google's wording, from Transfer Drive files to a new owner as an admin:

Transferring files does not affect who has access to the files.

Read that as a security statement, because that is what it is. Every share the departing teacher created survives the transfer, including shares to personal Gmail addresses, to a previous employer, or to a class list from four years ago. The new owner inherits all of it, usually without being told. If your reason for transferring was to contain access, transferring alone did not do it.

Shared drive files are not included. Files that live in a shared drive were never owned by the person, so they are not part of their Drive content and are untouched by a transfer. That is good news — it is the argument for shared drives — but it means a transfer report showing a small number is not necessarily wrong.

Folder structure does not survive intact. Where a file's parent folder is not shared with the new owner, Google creates shortcuts rather than moving the file into place. The receiving teacher opens their Drive and sees a pile of loose shortcuts instead of the folder tree they were promised. Nothing is lost, but nobody can find anything, which for practical purposes is similar.

Large transfers can fail silently. Google states plainly:

If a transfer takes longer than 36 hours, it's unsuccessful and will stop.

A long-serving teacher with a large Drive is exactly the case that hits this, and it is exactly the case where somebody deletes the account a week later assuming the transfer completed.

Also worth knowing: Google Maps files cannot be transferred at all, and ownership cannot move to or from an external account, including a personal Google Account.

Check the transfer actually finished before you do anything irreversible.

Shared drives are a membership problem, not an ownership problem

Removing a departing teacher from a shared drive does not touch the content, because they never individually owned it. That is the entire point of shared drives and it makes this part easy.

The thing to check is whether they were the only manager. If they were, the remaining members may no longer be able to change membership or drive settings themselves. This is recoverable — the Admin console's shared drive management has a No managers filter precisely for finding these, and an administrator can assign a new manager — but it is much easier to hand the role over deliberately before the person leaves than to go looking for orphaned drives afterwards.

Delegation, forwarding, and filters

This is the most-skipped step and the one most likely to matter later.

  • Mailbox delegation granted to the departing person over someone else's mailbox — a secretary, a department head, a shared role account — does not disappear when they are suspended. It has to be removed from the other mailbox.
  • Delegation they granted to others over their own mailbox keeps working for those others.
  • Forwarding rules and filters on their account keep running. Mail arriving at a suspended account is generally rejected, but any rule that was quietly copying to an outside address is something you want to have seen before you close the account.

None of this shows up on a checklist that starts and ends with "suspend the account", and none of it is visible from the departing user's row in the admin list.

Groups, calendar, and everything attached

Groups. Removing them from distribution and permission groups is straightforward. Check whether they were a group owner or manager, for the same reason as shared drives.

Calendar. Recurring events they own — a weekly department meeting, a duty roster — keep existing and keep being owned by the departing account. Hand those over while the account is still active and the handover is a normal transfer; leave it until after the account is gone and you are recovering rather than transferring. The person who notices is usually whoever tries to move the meeting in November.

Calendar resources. Standing bookings for rooms and equipment persist. Free them up rather than leaving a lab booked every Tuesday to nobody.

Devices. Assigned Chromebooks need reassigning; a device is not automatically freed by suspending its user. What to do with the hardware is a separate decision, and doing it wrong can cost you a license.

Third-party apps. Anything they authorized with their school account — a grading tool, a classroom app — was granted against that account and should be reviewed.

Licenses, storage, and the twenty-day cliff

A suspended account still exists, and its data still occupies your storage pool. Suspension is a security action, not a housekeeping one; notably, Google's own guidance on freeing up storage talks about deleting accounts and never once suggests suspending them.

When you do eventually delete, Google is unambiguous about the window:

You can restore a user account (including administrator accounts) up to 20 days after deleting it. After 20 days, the data is gone and you can't restore it.

Two further conditions can block a restore even inside those twenty days: you need an available license of the right edition, and the domain has to still be yours.

Twenty days is short. It is shorter than a summer break, shorter than most grievance procedures, and much shorter than the interval before somebody asks whether that teacher ever emailed a particular parent.

Retention: not a technical decision

How long you keep a departed teacher's account and data is a district policy question governed by your record retention schedule and applicable law, not something to decide from the Admin Console because storage is filling up.

Get the answer in writing from whoever owns records retention in your district, apply it consistently, and write down which rule you applied. "We deleted it because we needed the space" is not a retention policy, and it is a very uncomfortable sentence to say later.

Common mistakes

Deleting instead of suspending. The single most expensive mistake available here, and it takes one click.

Suspending mid-transfer. Start the transfer, then suspend once it is confirmed complete.

Assuming transfer contained the data. It did not. Access is unchanged by design.

Assuming suspension closed every door. It resets sign-in cookies and OAuth tokens, which is a lot — but it does not sign the user out of desktop apps, and app passwords are their own question that the documentation does not answer consistently. The controls overlap; none of them covers everything.

Forgetting delegation on other people's mailboxes. Nothing on the departing account shows it.

Leaving them as the only manager of a shared drive or group. Easy to fix before, awkward after.

Treating the twenty-day window as a plan. It is a safety net, not a retention schedule.

What to do about it

Write the sequence down once and make it the same every time: secure the account, then move the data, then verify the move, then decide about deletion on a policy timeline rather than a convenience one.

The security steps are fast and should happen the day someone leaves. Everything else can and should be slower — and the accounts that cause trouble years later are almost always the ones that were rushed.

Sources

This sequence is the reason ORINEX Workspace has an offboarding workflow rather than a suspend button — the steps are not hard, but doing all of them, in order, for every departure, is not something a checklist on a wall reliably achieves. What ORINEX Workspace does.