Optional School Year Rollover with Historical Graduation Year Retention

Summary
Make the annual school year rollover an optional process rather than a required one, and preserve past graduation years in the system when rollover is performed. Districts using a roster server as their source of truth should be able to skip rollover entirely and let roster data drive all account state changes. Districts that do choose to run rollover should retain past graduation years for auditing, historical reporting, and alumni device recovery.

Problem
The current rollover behavior creates issues for two distinct groups of districts:

Districts with a roster server (majority case). Most districts rely on a roster server (Clever, ClassLink, Infinite Campus, PowerSchool, Skyward, etc.) as the authoritative source for student enrollment, grade level, building assignment, and status. When the platform's rollover runs on top of that, it either duplicates work the roster server is already doing or actively conflicts with it — bumping grade levels the roster server will overwrite, moving students to a "Graduated" building that the roster server doesn't recognize, and creating reconciliation problems that admins then have to clean up. For these districts, rollover isn't just unnecessary — it's counterproductive.
Districts without a roster server. For districts that legitimately need rollover, the current behavior erases historical context. Once rollover runs, existing students can only exist under future graduation dates; past graduation years disappear from the record. That breaks:

Auditing — no way to look back and confirm which cohort a former student belonged to at a given point in time.
Device recovery — chasing down devices still assigned to prior-year graduates becomes harder when their graduation year is no longer visible on the record.
Historical reporting — cohort-based reports (devices issued to the class of 2024, incidents by graduation year, etc.) become impossible or unreliable.
Compliance — retention policies and records requests often require preserving historical state, not overwriting it.



Proposed Solution

Make rollover optional at the district level. In settings, allow admins to designate the rollover process as:

Disabled — the roster server (or manual updates) drives all account state changes. The platform performs no automatic grade-level bumps, building moves, or status changes at year-end.
Enabled — the platform runs rollover as it does today, with the historical-retention improvements below.


Clear guidance in the UI explaining which option fits which situation, with a recommendation to disable rollover when a roster sync is active, and a warning if both are enabled simultaneously (to prevent the conflict described above).
Preserve past graduation years when rollover is enabled. Rather than restricting existing students to future graduation dates, the system should:

Retain the original graduation year on the student record as a historical value, even after they've been marked graduated or moved to the "Graduated" building.
Allow past graduation years to be selected, filtered on, and reported against in the UI — not just future years.
Continue to support marking students as graduated and moving them to a "Graduated" building, but treat those actions as additive history rather than as overwrites.


Rollover audit log. Each rollover run should produce a record of what changed — students promoted, students graduated, buildings updated, exceptions encountered — with a timestamp and the initiating user, and the option to review or reverse the run within a defined window.
Roster-server-aware behavior. When a roster sync is configured and active, surface a clear indicator on the rollover screen that automated rollover may conflict with roster data, and recommend disabling it. If the district still chooses to run rollover, log that decision.
Backfill for existing data. Provide a one-time utility to reconstruct or re-associate past graduation years for students whose historical values were lost to prior rollovers, where the data is recoverable from other fields (device assignment history, incident records, etc.).

Who Benefits

Districts using a roster server — eliminate a redundant, conflict-prone process and let the source of truth remain the source of truth.
Districts without a roster server — keep rollover working, but without losing historical context every year.
Asset managers and technicians — accurate cohort information makes end-of-year device collection and alumni recovery efforts much easier.
Auditors and compliance officers — historical graduation data remains available for records requests, retention policies, and audits.
Reporting and data teams — cohort-based reporting (class of 2023, 2024, etc.) becomes reliable across years.
System admins — fewer reconciliation headaches, clearer expectations about what the platform will and won't do automatically each summer.
District leadership — confidence that year-end transitions won't overwrite institutional history.

References / Comparable Implementations

Clever, ClassLink, Infinite Campus, PowerSchool, Skyward — roster/SIS platforms that already act as the authoritative source for enrollment and grade-level changes; the platform integrating with these should defer to them rather than duplicate their behavior.
Google Workspace for Education and Microsoft 365 Education — treat SIS/roster data as authoritative and don't perform their own grade-level rollover.
Incident IQ, GoGuardian, Securly, and similar EdTech tools — many offer roster-driven account state with rollover as an optional layer rather than a required annual event.
General records-retention practice in K-12 (FERPA-aligned) — precedent for preserving historical student state rather than overwriting it.