The 90 days before a SITS upgrade: a playbook for registrars and CIOs

Every registrar knows the feeling: the vendor release is scheduled, the testing window is already shorter than anyone would like, and somewhere in the background is an immovable deadline — enrolment, Clearing, a HESA return — that turns a slip from an inconvenience into a reputational event.

Most upgrade failures are not caused by the upgrade itself. They are caused by everything around it: undocumented local customisations, integrations nobody fully owns anymore, reports built directly against tables that are about to change shape, and manual workarounds that only exist in the memory of one long-serving member of the registry team.

The 90 days before cutover are where you buy back control. This playbook lays out what to do in each 30-day block — in the order that protects the academic calendar first and everything else second.

Before anything freezes, you need a truthful map of what the upgrade will actually touch. Not the diagram in the last project board pack — the real estate, as it runs today.

This is the block where discipline pays. Two decisions matter more than all others: a genuine scope freeze, and a rehearsed rollback that people have actually seen work.

Freeze scope with teeth. Every late addition to an upgrade window is a wager against the academic calendar. Establish a change board — even an informal one — that can say no, and give the registrar the casting vote on anything touching student records.

Protect the integrations. If upstream systems (Salesforce, Canvas, timetabling) continue writing to SITS during cutover, you get the worst of both worlds: partial data and confused records. Decide which feeds pause, which buffer, and which can safely queue behind an integration layer — this is exactly where an event-driven bus earns its keep, absorbing writes while the core system is offline.

Rehearse the rollback. A rollback plan that exists only as a document is a hope, not a plan. Run the restore in the test environment, time it, and write down the decision point: the hour by which you either proceed or roll back, agreed in advance with the people who own the deadline.

The final month is about communication and containment, not new work. Publish a plain-English freeze notice to affected teams: what stops working, when, and who to call. Schedule the cutover in the lowest-impact window the calendar allows — and staff the go-live weekend with the people who built the inventory in days 90–60, not whoever happens to be on rota.

Define "done" before you start: a short list of smoke tests that prove the student record lifecycle still works end to end — registration, module association, fee assessment, one statutory extract. If any of them fails, the rollback decision is already made; nobody improvises at 3am.

Plan for two weeks of heightened support after go-live, even when the cutover is clean. A daily fifteen-minute triage standup — registry, systems, and someone who can reach the vendor — catches the slow-burn issues: a report subtly miscounting, an integration replaying stale events, a workflow quietly falling back to spreadsheets.

Log every workaround that appears during this period. They are the honest signal of where the system still fights the organisation — and they become the backlog for the next phase of improvement rather than permanent folklore.

External help at this stage should reduce your risk, not add to it. The useful kind arrives with a fixed scope, works alongside your team rather than around them, and leaves behind the inventory, runbooks and integration maps as deliverables you own — not knowledge that leaves when the contract does.

This playbook reflects delivery inside UK university registry and systems teams — including student record migrations to SITS and multi-platform integration estates. See the context in our university systems modernisation work and the higher education practice.