The Google Workspace summer rollover checklist for K-12

Rollover is four populations, one hard deadline, and an ordering constraint that will merge two grade levels if you get it backwards. Most of the work is decisions made in May, not clicks made in July.

Summer rollover is the largest single set of changes a district makes to its Google Workspace tenant all year, it happens once, and the person doing it usually has not done it since the last time.

It is also mostly not a technical problem. The clicking is straightforward. What makes rollover go wrong is doing the right operations in the wrong order, and discovering in September that two grade levels are now indistinguishable.

The short answer

Four populations, each needing a decision rather than a task: students moving up, students leaving, staff leaving, and everybody arriving.

One deadline that actually bites: students who are leaving can only take copies of their own work while they can still sign in. Suspension is reversible, so this is recoverable — but recovering it means unsuspending a cohort that has already scattered.

One ordering rule that matters more than the rest: process the cohort that is leaving before you advance anybody, and advance from the top down. Get this backwards and you merge two grade levels into one.

Everything else can be reconsidered in August.

Start in May

The parts of rollover with real deadlines are all decisions, and they all want to be made before the last day of school.

Decide what departing students may take, and test it. Google provides a documented route for students to copy their own Drive and Gmail into a personal account, and it depends on two settings that are commonly off in schools. Test it with one real student account before you announce anything — the tool can look available and move nothing.

Decide your retention rule, in writing. How long departing students' accounts and data are kept is a records question governed by district policy and applicable law. Settle it once, with whoever owns retention, and apply it identically every year.

Decide the naming and OU structure before you move anyone. Rollover is when structural mistakes get multiplied by several thousand.

Get your enrolment data early. Almost every rollover delay is really a waiting-for-the-SIS delay.

The ordering rule

This is the one that bites, and it is worth stating concretely.

Suppose your organizational units are by graduation year, or by grade. If you begin by advancing your oldest current students into the next grade, and then try to move the graduating cohort out, you have already mixed them with the year below. The distinguishing attribute is gone. Recovering it means going back to the SIS and rebuilding the split by hand.

So:

  1. Move the leaving cohort out first, to wherever graduates go.
  2. Then advance the remaining cohorts from the top down — the oldest remaining group first, then the next, and so on downwards.
  3. Then bring in the new intake, into a structure that is now empty and waiting for them.

Top-down, always. Moving from the bottom up walks each cohort into the one above it.

If your OUs are named by graduation year rather than by grade, most of this disappears — the students never move, the meaning of the OU changes on its own, and only the graduating cohort needs touching. That is a genuinely better design, and rollover is the only sensible time to migrate to it.

Students moving up

Organizational unit moves are policy changes. This is the thing to hold in mind. An OU is not a folder; it is where policy, app availability, and licensing are decided. Moving a student between OUs changes what they can do — which is the entire point, and also the risk. A student moved into the wrong OU gains or loses capability silently.

Move a small batch first and check one account properly before running the rest.

Expect Google to take its time. Directory changes are not instant, and the lists you check them against lag behind the accounts themselves — we measured about eleven seconds for a single-attribute change to one account, and longer for other operations. If a count taken immediately after a bulk move looks wrong, wait and look again before concluding anything.

Groups do not follow OUs. If your distribution lists are per-cohort, moving the students does nothing to the groups. That is a separate job, and it is the one most often forgotten.

Students leaving

Covered in full in suspend, transfer, archive, or delete, but the rollover-shaped version:

  • Publish the transfer window while they still have access. The one step whose sequencing really matters.
  • Suspend at the end of the window, not before it.
  • Where your retention policy allows it, consider running deletion a cohort behind rather than deleting the class that just left. That buys an extra recovery window and keeps the annual cleanup predictable. Whether you can is a records question, not a technical one — retention schedules, applicable law, and any litigation or records hold decide it.
  • Do not deprovision their Chromebooks if the devices are staying in your fleet. Deprovisioning ends management of the device; the upgrade and licensing consequences depend on whether it carries a standalone fixed-term, standalone perpetual, or bundled upgrade. That decision is its own guide.

Staff leaving

Staff departures are individually more complicated than student ones — delegation, shared drives, calendar ownership, and Drive transfers that do not behave the way people expect. The full sequence is its own guide.

The rollover-specific point: do the departures before the moves. A departing teacher who is still the sole manager of a shared drive, or the owner of a recurring meeting, is much easier to deal with while everything is still where they left it.

Devices

Summer is when device decisions get made in bulk, which makes it when device mistakes get made in bulk.

  • Disable and deprovision do very different things, and there is no delete for an enrolled device. The deprovision reason you choose can be a license decision.
  • Devices being kept do not need touching. Deprovisioning ends management of the device, and re-enrolling it later is work you did not need to do — what it costs you in license terms depends on whether the device carries a standalone fixed-term, standalone perpetual, or bundled upgrade.
  • Do not trust a device count to tell you the job is done. Deprovisioned devices stay in their organizational unit, so totals from different places will not agree — which is expected, not a fault.

Groups

Cohort groups accumulate one per year, permanently, unless somebody does something about it.

Rollover is the natural time to identify dead groups and the worst possible time to delete them — the quiet period is when usage evidence is thinnest and the person who knows what a group was for is away. Start the observation in July; do the deleting during the school year. Full method here.

Storage

Education editions come with a baseline of 100 TB of pooled storage for the institution, and rollover is when districts discover where they are against it.

The thing worth knowing before you plan around it: suspending accounts is not a storage measure. Google's own guidance on freeing up storage is about deleting accounts and shared drives, and about alumni specifically:

By removing inactive alumni accounts, you might free up a significant portion of your shared storage pool

If storage is your pressure, the lever is deletion on a retention schedule, not suspension. Suspension buys time, not space.

Admin roles and security

The once-a-year jobs that have no other natural home:

  • Review who holds delegated admin roles. People change jobs; roles do not expire.
  • Check for admin accounts belonging to people who have left. Rollover is when this is most likely to be true and least likely to be noticed.
  • Review third-party app access granted at the domain level.
  • Check your super administrator recovery details are current and belong to people still employed.

None of this is urgent in July. All of it is much worse to discover in February.

Verify afterwards

Rollover is a bulk operation and bulk operations fail partially.

Check a sample properly rather than checking totals. Open two or three real accounts from each population and confirm what you expect: correct OU, correct groups, correct license, correct app access. This finds more than any count will.

Be careful with counts. Numbers from different places legitimately disagree — deprovisioned devices, suspended users, and child organizational unit roll-ups all make two correct answers look like a discrepancy. Know which question you are asking before you treat a number as a fault.

Check the things that are silent when they break: group membership, calendar resource permissions, and anything external that sends to a group address.

Common mistakes

Advancing cohorts bottom-up, or advancing before removing the graduating cohort. Merges grade levels and is genuinely painful to undo.

Suspending departing students before the transfer window. Recoverable, but unnecessarily painful — the accounts have to be unsuspended and students may need to be re-contacted after the cohort has dispersed. Complete the transfer or export before you suspend.

Deleting on convenience rather than on your retention schedule. Running a cohort behind is a useful default where policy permits it.

Deprovisioning devices you are keeping. No benefit, and depending on the upgrade type it may cost you something to put them back.

Suspending to free storage. It does not free storage.

Treating an OU move as filing. It is a policy change.

Doing it all in one pass with no sample check. Bulk operations fail partially, and partial failures are invisible in a total.

Leaving no record of what you did. Next summer, that record is the whole plan.

What to do about it

Write the sequence down the first time you do it, including the order and the reasoning, and keep it with the dates you actually did each step. Rollover happens once a year, which is exactly the interval at which nobody remembers anything.

The decisions belong in May. The clicking belongs in July. Most rollovers that go badly are ones where those two happened in the same week.

Sources

Rollover is the week that made the case for building ORINEX Workspace: thousands of changes, in a required order, done once a year by people who cannot reasonably be expected to remember last July. What ORINEX Workspace does.