The SIS migration field guide: 140 days, two rehearsals, one parallel term
A week-by-week account of how institutions move off a legacy student information system without losing a registration cycle — including the four decisions that cause most delays.
Key takeaways
- Data mapping, not software configuration, is the critical path
- Two rehearsal migrations catch 90% of reconciliation problems
- A parallel registration term is non-negotiable for institutions over 3,000 students
- Name a single institutional decision-maker for catalog rules before week four
Why migrations slip
Almost no SIS migration fails on technology. They slip because nobody can state, authoritatively, what the institution’s current rules are. Three people describe the residency requirement differently, and the project stops while a committee decides which description was ever true.
Institutions that finish on schedule do one thing differently: they treat discovery as a policy exercise with a named owner, not as a data export.
- Weeks 1–3: inventory every system of record, including spreadsheets
- Weeks 4–9: configure catalog, calendar, aid rules; two migration rehearsals
- Weeks 10–14: parallel registration term with record-level reconciliation
- Week 15+: cutover, legacy system to read-only archive
The four decisions to make early
First, who owns catalog rules. Second, how far back student records migrate in full fidelity versus archive. Third, whether advancement migrates with students or in a later phase — we strongly recommend together. Fourth, which reports are genuinely critical, which is usually a much shorter list than the one you are handed.
What to expect at cutover
Cutover weekend is quiet if the rehearsals were not. Expect a reconciliation report on every record, a registrar sign-off gate before go-live, and a support rota for the first registration window. Your legacy system should remain available read-only for at least 24 months for audit and transcript history.