When a course ends, student websites should move through a deliberate lifecycle rather than a binary keep-or-delete: accounts are suspended at module end (access stops, everything is preserved, easily reversed for resits and extensions), retained through marking and appeals windows, archived for the period institutional policy sets, and only then deleted — with students given clear notice and a real window to download their work before each irreversible step. The three operations are different tools: suspension protects assessment, archiving satisfies retention policy, deletion honours data minimisation — and a university needs all three, on paper, before the first cohort graduates.
Suspension, archiving, deletion — what is the difference?
Three operations with three different jobs, and most retention mess comes from using one where another was meant:
The design principle across all three: reversible operations happen on calendars, irreversible ones happen on policy plus notice. Nothing should ever be deleted because a script ran on a date nobody remembered agreeing.
| Comparison area | Suspension | Archiving | Deletion |
|---|---|---|---|
| What happens | Access and serving stop; content untouched | Content preserved in inactive storage; account leaves the live estate | Content destroyed |
| Reversible? | Trivially — reopening is routine | Yes, deliberately — restore from archive | No |
| Protects | Assessment integrity, the option to return | Retention policy, appeals, records | Data minimisation, storage, students' privacy |
| Typical trigger | Module or block end date | Appeals window closing | Retention period expiring |
| Student notice | Expected in module materials | With a download window | With final notice and a download window |
Should accounts be suspended or deleted at course end?
Suspended — deletion at course end is almost always premature. The weeks after teaching are exactly when the site still matters: marking may consult it, appeals can reopen months later, resits and extensions are routine, and withdrawn students have return rights. Suspension gives the estate what it needs (no further changes, no live attack surface, no active cost of serving) while keeping every option open at near-zero cost.
Deletion has its rightful place at the end of the retention clock, not the teaching clock. An estate that deletes on results day will eventually destroy the evidence an appeal needed; an estate that never deletes is hoarding personal data — the sections below walk the middle path.
How much notice should students receive, and how do they download their work?
Notice at three moments, none of them a surprise: in module materials from the start ('your account is suspended at module end and archived after appeals — here is the timeline'), when suspension happens (confirming what is preserved and what happens next), and before anything irreversible (a real final notice ahead of deletion, with a working download route). The download window is the load-bearing part: students should be able to export their site — files and database, since dynamic coursework is mostly database — through a self-service route, before archival and again before deletion.
Group projects add the plural: archival and deletion notices go to every member, each of whom may want a copy for their portfolio. The recurring failure in the genre is notice sent to expired university mailboxes — final-notice routes should account for graduates having left the email estate too, which argues for notice before graduation rather than after.
Read next: Web hosting for university student group projects
Should sites remain publicly accessible after the course?
By policy, briefly, and read-only if at all. There are respectable reasons for a short public afterlife — external examiners, portfolio continuity while a student arranges their own hosting, showcase pieces — and equally respectable reasons against a long one: unmaintained sites accumulate vulnerabilities, coursework contains personal data, and 'still online' quietly becomes 'still the university's responsibility'. A restricted (read-only) period through marking, followed by suspension from public serving, is the defensible middle.
Whatever the choice, make it uniform and stated: a policy where some students' sites linger for years because nobody suspended them is not generosity, it is drift — and it is where the security guide's abandoned-application problem comes from.
How should resits, extensions and returning students be handled?
As routine reopenings, because they are routine: a resit student's account (or its archived copy) is restored for the resit window and re-suspended after; an extension moves one student's suspension date without moving the class's; an interrupted student's timeline pauses rather than running down; and a student returning next year simply has their account reactivated with new module memberships. Reopening being cheap is the whole argument for the suspend-first lifecycle.
The one discipline reopenings need is the same as everything else in this guide: recorded operations against the structure, not quiet favours — an account reopened for a resit should say so, so the estate's state always has an explanation.
Read next: How to organise student hosting by module, class and cohort
How should graduating students be treated?
As the case worth designing generously, because it is every student eventually and the last impression the service makes. The honest position: teaching infrastructure is not a lifetime hosting commitment, and graduate sites left indefinitely on coursework hosting become unmaintained liabilities — but a hard stop on results day is needlessly poor. The good pattern: clear pre-graduation guidance ('here is how to take your portfolio with you'), a defined grace period, an export route that works, and a pointer to where the portfolio should live next — their own domain and hosting, or an alumni arrangement where the institution offers one.
Education Host institutions have a concrete version of that pointer: Alumni Hosting exists precisely for graduates who want to keep a web presence after teaching accounts close. The portfolios guide covers the whole graduation boundary, including personally-owned domains as the portability mechanism.
Read next: Hosting student portfolios and client web projects
How long should coursework be retained, and what about personal data?
On the institution's records-retention schedule, not on hosting's convenience: universities already hold policies for how long assessed work and its evidence are kept (through appeals windows and beyond, varying by institution and award), and hosted coursework is assessed work — the hosting lifecycle should execute the existing schedule rather than invent a parallel one. The archive from the backups guide (submissions captured at deadline) is usually the thing the schedule actually governs; the live-site copy can often go earlier.
Personal data sharpens the deletion end: student sites contain personal data (the student's, and sometimes others' — client projects, user-research artefacts), and retention without purpose sits badly with data-minimisation principles under UK GDPR. Practically: involve your data-protection team in setting the periods, delete on schedule rather than by exception, and remember deletion means the backups and archives too — the retention clock governs every copy, which is a question to settle with any provider explicitly.
How should the year-end rollover run this lifecycle?
As one calendared operation against the structure: ended modules' accounts suspend on their block dates; last year's suspended accounts advance (archive after appeals close); archives past their retention date queue for deletion behind final notice; continuing students roll forward untouched; and the whole pass leaves an audit trail. Run in the quiet weeks with the data-quality reconciliation, it is an afternoon of review rather than a term of tickets — the modules-and-cohorts guide places it in the annual rhythm.
The rollover is also when the policy proves itself: if the operation needs per-account human decisions, the policy was never really written. Bulk lifecycle against academic structure is the test that it was.
An illustrative policy framework
A worked example of the shape — explicitly illustrative, not a recommendation for any institution; your academic regulations and data-protection team own the real numbers:
- Module end: accounts move to restricted (read-only) at the submission deadline; suspended at block end
- Marking and appeals: suspended accounts held untouched until the appeals window closes
- Archival: accounts archive after appeals close, with student notice and a download window beforehand
- Assessment archive: submission artefacts retained per the institutional records schedule, independent of the live account
- Graduates: a stated grace period post-award with export guidance, then the standard archive path
- Deletion: archived content deleted when its retention period expires, after final notice; backups and copies follow the same clock
- Exceptions: resits, extensions, interruptions and appeals reopen accounts through recorded operations at any stage before deletion
Every line above is a bulk operation against modules and dates — which is the practical takeaway: a retention policy is only real once the lifecycle machinery can execute it.
How does Student Web Host Manager run this lifecycle?
The lifecycle in this guide is Student Web Host Manager's native vocabulary: accounts carry lifecycle states — active, restricted, archived, reopened — and the suspension manager applies them in bulk around module dates, marking windows and institutional policy, with bulk actions, user removal and audit visibility across the estate. Because accounts belong to courses, modules and teaching blocks, 'suspend this block's accounts at its end date' and 'reopen this student for a resit' are recorded operations rather than manual projects, and the Statistics Manager keeps suspended and never-logged-in accounts visible instead of forgotten.
Retention periods and download arrangements are institutional policy, agreed during scoping — the platform's job is to make executing them boring.