SchoolStackA student information system (SIS) is the hardest piece of school software to replace. Attendance, timetables, grades, reports, safeguarding notes and state or national returns all live in it, and every other app reads from it. Schools tend to change SIS once a decade, so a bad choice stays with you for years.
This guide walks through how to run the selection so the system still fits after the first year. You can compare current options in our student information system ranking.
Start with the jobs, not the feature list
Vendor demos are built around features. Your requirements should be built around jobs people do every week. Before you talk to any vendor, sit with each group for an hour and write down what they actually do:
- Office staff. Enrolling a mid-year transfer, recording a late arrival, printing an emergency contact list during a fire drill.
- Teachers. Taking a register in under a minute, entering grades, writing report comments, seeing a student’s support plan before a lesson.
- Leaders. Pulling attendance by year group, spotting students whose grades dropped this term, preparing the census or state report.
- Families. Seeing attendance and grades, updating a phone number, paying for a trip.
Turn each job into a test script. In the demo, ask the vendor to perform the task live, on their product, with your scenario. A slide that says “flexible reporting” tells you nothing. Watching someone build the year 9 attendance report in four minutes tells you a lot.
The requirements that cause the most pain later
Most systems handle registers and grade entry well. The problems show up at the edges.
Statutory reporting. In the United States that means state reporting. In the UK it means the school census and other Department for Education returns. Ask which returns the vendor supports in your region, who updates them when the format changes, and how many schools in your area submit through the product today.
Timetabling. Some systems build the timetable themselves. Others import it from a separate scheduling tool. If you have a complex secondary timetable, test it with your real data, including split classes and rotating days.
Integrations. Count the apps that need student and class data from the SIS: the LMS, the parent app, library, catering, transport. Ask whether the vendor supports open standards such as OneRoster, or works with rostering services like Clever, ClassLink or Wonde. Each integration that relies on a manual CSV export becomes someone’s weekly chore.
Permissions. A teaching assistant should see the students they support and nothing else. A safeguarding lead needs notes that most staff cannot see. Ask the vendor to show you how they set up role-based access, and test a few edge cases.
Data export. Ask how you would get all of your data out if you left. A full export in a documented format is a sign the vendor expects to keep you by being good, not by making leaving painful.
Questions to ask every vendor
- Which schools like ours, in our region, have moved to your system in the last two years? Can we call two of them?
- Who does the data migration, and what is included in the price?
- How many hours of training are included, and is it live or recorded?
- What does support look like during the first census, state report or reporting season?
- What are the price increases in years two and three?
- Where is our data stored, and who are your sub-processors?
- What happens to our data if we end the contract?
Write down the answers. The reference calls in question 1 are worth more than any demo. Ask the reference school what they wish they had known before they signed.
A realistic timeline
Most schools underestimate the time a migration takes. A typical plan for a single school looks like this:
| Phase | Time | What happens |
|---|---|---|
| Requirements and shortlist | 1 to 2 months | Job scripts, shortlist of three, demos |
| Decision and contract | 1 month | Reference calls, pricing, data processing agreement |
| Data migration | 1 to 3 months | Clean old data, test imports, check reports |
| Training | 1 month | Office staff first, then teachers, then families |
| Go live | At a natural break | Ideally the start of a school year or term |
Plan to run the old and new systems side by side for at least a few weeks. Check that registers, grade totals and contact details match before you switch the old one off.
Clean your data before you move it
Migration is the best chance you will get to fix years of messy records. Duplicate contacts, old addresses, students who left but were never archived, and free-text fields used in five different ways will all move across unless someone deals with them first. Give one person ownership of data cleaning and a deadline.
Decide who owns the system
The SIS needs a named owner after go-live, usually a data manager or an assistant head. That person decides how fields are used, approves new integrations and trains new staff. Without an owner, every department invents its own conventions and within two years the reports stop matching.
Summary
Write requirements as weekly jobs, test them live in demos, call schools that already made the move, and put an owner in place before launch. Spend most of your scrutiny on reporting, integrations and data export, because those are the areas where a poor fit costs the most.