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 left behind Drive ownership, delegated mailboxes, calendar events and a forwarding rule 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 reversible and blocks the user's access to Google Workspace services. 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. It blocks their access to Google Workspace services (Google notes one edge: a user already in a Google Chat session can continue until it ends), and it is also what Google tells you to do before an admin Drive transfer, so the departing owner cannot create or move content while ownership changes.
  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. Start where Google's own instructions start: suspend the current owner before the transfer. Google's first step is "Suspend the current owner's account. This action prevents them from creating or moving content during the transfer," and the same page notes that the recipient must be an active account, not a suspended one. Then four things about the transfer itself 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 stay configured. Google blocks new email to a suspended account, so nothing new flows through them while it is suspended, but a rule that was quietly copying mail to an outside address is something you want to have seen, and removed, before the account is ever unsuspended or handed to a successor.

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; Google notes that a suspended user's events remain visible on invitees' calendars. Hand those over while the account still exists and the handoff is a normal transfer; leave it until after the account is deleted 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.

Leaving the account active during an admin Drive transfer. Google's instructions for transferring a user's files as an administrator begin with suspending the current owner, so they cannot create or move content while ownership is changing. This is the opposite of a graduating student's self-transfer, where the student must still be able to sign in: that tool is theirs, this one is yours.

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.