Student Information System Cost: You Are Paying For History And For Reporting
Two institutions ask for the same thing in the same month. One receives a quote for $48,000. The other receives one for $190,000. Both quotes are honest, and both are for a student information system.
The gap is not padding. Student information system cost is set by how much history you carry forward and how many bodies you report to, and neither of those appears on a feature comparison. A school with four years of clean digital records and one statutory return is a different project from a college with nineteen years of records in three formats and six returns, even though the screens look identical.
An SIS is the system of record for a person's relationship with an institution. Everything else reads from it.
That distinction matters more than it sounds. A learning platform holds coursework. A finance system holds invoices. A library system holds loans. All three ask the SIS the same question, which is whether this person is currently enrolled, in what, and under whose care. When the answer is wrong the errors surface somewhere else, which is why SIS defects are usually reported as bugs in other systems.
The record itself is small. A student, a programme, a set of enrolments, a set of results. The work is in the fact that every one of those is true only within a period. A student was enrolled in this course in that term. A grade belongs to an attempt, which belongs to a sitting, which belongs to an academic year that may have had different rules from the current one.
An SIS that cannot answer a question as of a date is a database with a school theme.
This is the constraint that surprises every buyer and appears in no vendor proposal.
You cannot cut over a student information system in the middle of a term. Attendance is being taken daily, assessment is in flight, and the register is the legal document that says who was present. Running both systems side by side for a period is normal migration practice at a term boundary. Doing it inside a term is different, because only one register can be the legal record, and every member of staff taking attendance has to know which one that is on any given morning.
That leaves a small number of usable windows in a year. Most institutions have two, sometimes three, and they are short. A summer window between an academic year ending and the next admissions cycle completing is typically six to ten weeks wide, and admissions is often still running inside it.
The consequence is a schedule that is fixed by somebody else. If the build runs four weeks late against a window that is eight weeks wide, the project does not slip by four weeks. It slips to the next window, which may be seven months away. Delay cost in this sector is discontinuous, and that changes how a plan should be built: earlier decisions, less parallel work at the end, and a migration rehearsal that happens long before the real one.
It also changes the honest answer to "when can you start". Working backwards from a cutover window is the only planning direction that survives contact with an academic year.
Ask what happens to the old records and the room usually goes quiet.
An SIS holds the permanent record. Transcripts, awards, disciplinary history and attendance evidence are retained for years and in many cases for decades, because a graduate can request a transcript twenty years after leaving and an institution is expected to produce it. That obligation does not transfer to the new vendor by signing a contract. Someone has to move the data.
Migration cost is driven by three things, and none of them is row count.
The first is how many distinct formats the history sits in. Nineteen years of records frequently means three systems, two of which are no longer supported and one of which exports only to a fixed-width text file that a retired member of staff designed.
The second is whether historical rules match current rules. A grading scale that changed in 2019 means a transcript printed today has to render a 2017 result under 2017 rules and a 2024 result under 2024 rules, on the same page. Systems that store the calculated grade rather than the inputs and the scale cannot do this at all, and the fix is not a migration script. It is a data model that keeps the scale alongside the mark.
The third is how far back the record has to be queryable rather than merely retained. Retaining a PDF of a transcript is cheap. Making 1998 results searchable, reportable and correctable is a different project. A great deal of money is saved by asking which years genuinely need to be live and which need to be retrievable, and most institutions have never been asked the question.
A reasonable split is that migration lands somewhere between 60 and 400 hours. The low end is four years of clean data from one supported system. The high end is two decades across three formats with a grading scale change in the middle.
Reporting is where custom builds are won and lost, because the specification belongs to a third party.
A school reports to a district, a board or a ministry. A university reports to a funding body and an accreditor. The return has a schema, a deadline and a validator that rejects the file for reasons that are frequently about formatting rather than substance. None of that is negotiable, and none of it is stable. Return formats change, usually annually, usually with a few months of notice.
This has two cost implications that vendors rarely spell out.
The first is that each distinct return is a small project of its own, in the range of 60 to 140 hours, because it needs extraction, mapping, validation against the publisher's rules and a correction path for when it fails. A returns pipeline that cannot show the operator which record broke it is a pipeline that gets abandoned within two cycles.
The second is recurring. Every year the format moves, and somebody maintains that. Budgeting a build without budgeting the annual return maintenance produces a system that is accurate for eighteen months and then quietly stops being filed on time.
There is a related compliance surface that shapes architecture rather than cost. Under FERPA, which has governed the education record in the United States since 1974, an outside service provider handling personally identifiable information does so under the school official exception, which requires the institution to retain direct control over use and maintenance of the data and forbids re-disclosure for unauthorised purposes. Directory information can be disclosed, but only after public notice of what is included and a reasonable opt-out period. The amended COPPA Rule broadens what counts as personal information for younger students and requires separate parental consent before third-party disclosure alongside a written retention policy.
Institutions in the Gulf work to a different set. Oman's PDPL, from Royal Decree 6/2022, gives data subject rights inside 45 days, requires breach notification inside 72 hours and a named data protection officer, and requires a permit before processing children's data at all. Saudi Arabia's PDPL, regulated by SDAIA, expects a data protection impact assessment for high-risk processing and a transfer risk assessment before student data leaves the Kingdom, which is why in-Kingdom hosting is a routine requirement rather than an unusual one.
There is an important asymmetry here that saves real money once it is understood.
Getting roster data out of an SIS and into a learning platform is a solved problem with a published specification. OneRoster 1.2, from 1EdTech, is supported by roughly 70 per cent of learning platform vendors and moves people, classes and enrolments either as CSV files or over a REST API using OAuth 2.0 client credentials. OneRoster 1.1 is being sunset for new certification, and its OAuth 1.0a body-hash signing is worth avoiding in anything built now. LTI Advantage covers the launch and grade path, and the pieces procurement usually names are Core, Deep Linking, Names and Role Provisioning, and Assignment and Grade Services. Single sign-on is normally SAML 2.0, federated through InCommon or eduGAIN in higher education, where the practical failure mode is certificate rotation breaking every login because metadata was not refreshing automatically.
In United States K-12 the other common shape is Ed-Fi, where an Ed-Fi ODS acts as the system of record and a service in front of it can serve a OneRoster API from the same data.
Because that path is specified, it prices predictably. A first roster sync with single sign-on is usually 130 hours or so, and a second learning platform against the same specification is a fraction of the first rather than a repeat of it.
The record itself has no equivalent standard. Admissions logic, progression rules, condonement, resits, credit transfer and award classification are institutional policy expressed as software. Two universities in the same city will differ, and the differences are not preferences. They are in the academic regulations, which are approved by a committee and change on a schedule nobody in IT controls.
Buyers frequently assume the ratio runs the other way, that integration is bespoke and the record is standard. Pricing on that assumption produces a quote that is wrong in both directions.
Session scoping is the requirement that a single line of a specification hides and a whole build carries.
Every meaningful record is versioned by academic year and by term. A student's programme, their fee status, their tutor, the curriculum they are following and the regulations they are assessed under are all true within a period and false outside it. Reports have to be correct as of a date, not as of now, because an audit asks what was true in March.
A concrete version of the problem helps. A student appeals a mark awarded in the spring of 2023. Answering the appeal requires the mark, the scale in force that term, the regulations approved for that academic year, the tutor responsible at the time, and the attendance evidence supporting or undermining a mitigating circumstances claim. Four of those five have almost certainly changed since. A system holding only current values can produce none of them, and the institution ends up reconstructing the answer from email.
The practical effect is that scoping adds roughly 15 to 25 per cent across every affected module rather than appearing as its own line. It changes the schema, it changes every query, it changes the tests, and it is close to impossible to retrofit once a system holds real data. A build that skips it looks cheaper for one academic year and then cannot answer the first question an auditor asks.
Accessibility carries a similar shape. WCAG 2.1 AA is the level public sector institutions are generally held to, and keyboard order, focus management and screen reader semantics cost far less designed in than retrofitted across finished screens.
Here is the rate, the hours and the multiplication, so any line can be argued with.
The rate band for education work is $40 to $100 per hour by role. Administrative screens and reporting sit near the floor. Timetable constraint solving and assessment integrity sit near the ceiling. A mixed team blends to about $65.
The scope priced below is the student record core. It excludes fees and finance, and it excludes a parent portal.
|
Module |
Hours |
|
Discovery and data audit |
80 |
|
Student record core, session scoped |
190 |
|
Admissions and enrolment |
170 |
|
Attendance and register |
150 |
|
Assessment, grades and progression |
220 |
|
Transcripts and permanent record |
110 |
|
Statutory reporting, first return |
150 |
|
Roster sync out and single sign-on |
130 |
|
Core total |
1,200 |
Twelve hundred hours runs $48,000 at $40, $120,000 at $100, and $78,000 at the $65 blend.
Migration sits outside that, between 60 and 400 hours, which is $3,900 to $26,000 at the blend. Each additional statutory return adds 60 to 140 hours. That gives a realistic span of $81,900 to $104,000 for a single-return institution with straightforward history, and materially more where the history is long or the returns are many.
Set that against a per-student licence. Take $12 per student per year as a worked example. An institution with 2,000 students pays $24,000 annually, which crosses $78,000 in a little over three years, before counting the migration that a licence does not include either. Below a few hundred students the licence almost always wins. Above a few thousand, with unusual academic regulations and several returns, the arithmetic reverses. The honest recommendation for a small school with ordinary rules is usually to buy something.
Order matters here more than in most builds, because the calendar is not negotiable.
Start with the record and session scoping, because nothing else can be built correctly on top of a model that cannot answer as of a date. Add admissions next, since it is the entry point for real data and it exposes the rules that were described informally in discovery.
Take attendance third. It produces daily use, and daily use is what surfaces the design errors that a demonstration hides.
Run the migration rehearsal early, against real extracted data, at least two months before the cutover window opens. A rehearsal is not a test of the script. It is the only reliable way to discover that the 2017 grading scale was never recorded anywhere except in a spreadsheet on a shared drive.
Leave assessment and transcripts until the record and the history are both trustworthy, and file the first statutory return in parallel rather than after, because the return is what proves the data model is correct.
A core slice of this shape reaches a usable state in about 16 to 24 weeks with a small team, which is what a summer window can absorb if the work starts in the winter.
Two questions make quotes comparable. How many years of history move, and in how many formats do they currently sit. And how many statutory returns does this institution file, to whom, and when did each format last change. A vendor who cannot answer those has not scoped your project. They have priced somebody else's.
A student record core runs about 1,200 hours, which is $48,000 at $40 per hour, $120,000 at $100, and $78,000 at a $65 blend. Migration adds 60 to 400 hours and each statutory return adds 60 to 140. Most single-return institutions with clean history land between $81,900 and $104,000.
Two things that never appear on a feature list: how many years of history you migrate and in how many formats they sit, and how many statutory returns you file. Screens are broadly similar between institutions. History and reporting are not.
Only between terms. Attendance and assessment are live during a term and the register is a legal record, so a mid-term cutover means two registers and no authoritative one. Most institutions have two or three windows a year, each six to ten weeks wide.
Buy, if you have a few hundred students and ordinary academic regulations. Building becomes defensible with several thousand students, unusual progression rules and multiple statutory returns. At $12 per student per year, 2,000 students crosses a $78,000 build in a little over three years.
Every record is true only within an academic year and term, so reports must be correct as of a date rather than as of now. It adds roughly 15 to 25 per cent across every affected module, and it cannot be retrofitted once the system holds real data.
Usually not. Rostering has a published standard in OneRoster 1.2, supported by around 70 per cent of learning platform vendors, with LTI Advantage for launch and grades. The expensive part is the record, because admissions and progression rules are institutional policy with no standard.
They have to move, and they have to render under the rules that applied at the time. A grading scale that changed part way through means one transcript page carries two scales, which only works if the system stores the mark and the scale rather than the calculated grade.
Vikas has around fifteen years of experience building software and now builds generative AI systems at Zyneto. His work covers retrieval augmented generation, agentic AI, knowledge graphs, AI memory, and the evaluation and guardrails that decide whether any of it is safe to put in front of customers. He has shipped enterprise copilots, document AI, chatbots and predictive analytics for e-commerce, fintech and marketing teams, and works day to day in Python, JavaScript and SQL. He follows multimodal models, business process automation and enterprise AI security closely, and mentors engineers moving into AI. He writes about architecture, inference cost and the failure modes that only show up at production scale.
Share your details and we will talk soon.
Be the first to access expert strategies, actionable tips, and the trends actually shaping the digital world. No fluff - just practical insights delivered straight to your inbox.
Dive into our blog and stay ahead of the curve with expert perspectives, future-ready trends, and tech tips written for decision-makers and doers alike.
