How is a student information system different from a learning management system?
The SIS is the institutional record of record; the LMS is where teaching happens. The SIS holds who a person is, what programme they are registered on, what they have paid, what they attended, and what the official transcript says. The LMS holds the course content, the activity, and the working gradebook. The two must exchange data in a defined direction: enrolments from the SIS to the LMS, final results back from the LMS to the SIS. Problems begin when both systems believe they own the same fact, which is why we fix the authority boundary before either integration is built. Our learning management system page covers the teaching side.
Should we build an SIS or buy one?
For a conventional institution, buying is usually correct and we will say so before scoping. Mature SIS products encode decades of administrative, regulatory, and reporting detail, and displacing a vendor that carries statutory reporting certification for your jurisdiction is expensive and rarely justified. Building becomes rational when you operate a model no product serves properly, when you are a group needing a coordination layer above several existing systems, when an installed system cannot be integrated or extended at any reasonable cost, or when you are building a platform to sell to other institutions. A failed SIS replacement is one of the more damaging projects an institution can undertake, so we assess this honestly.
Can you build around the SIS we already run?
That is the more common and usually the wiser engagement. Institutions rarely need a new record system; they need capability the incumbent does not offer, delivered around it. Applicant-facing admissions journeys, self-service portals for students and staff, timetabling that the core product handles badly, analytics beyond native reporting, and integration layers to finance or learning platforms can all be built as additions that read from and write to the record system through defined interfaces, leaving it authoritative and intact.
What does admissions and registration actually involve?
More variation than any other part of an SIS, because it is where institutional policy is least standardised. An applicant journey spans enquiry, application with document upload, qualification and eligibility assessment, interview or test scheduling where required, offer with conditions, acceptance, deposit, and conversion into a registered student without re-entering anything. Conditional offers are the part most often underbuilt: an offer contingent on results that arrive months later needs the condition tracked, evidenced, and cleared, with automatic consequences when it is not met. We model the applicant and the student as the same identity throughout, so history is continuous.
How are student records and transcripts handled?
The transcript is the most consequential artefact an institution produces, so the record behind it must be immutable in the right places and correctable through a controlled path in others. That means results recorded with the assessment period, the attempt number, and the marker or board that confirmed them, grade changes possible only through an authorised amendment with reason and audit, academic standing and progression decisions recorded as events rather than derived on the fly, and awards and classifications calculated by rules that can be reproduced years later. An institution must be able to reissue a transcript from ten years ago identically, including under the regulations in force at the time.
How does timetabling and scheduling work?
Timetabling is a constrained resource problem, and it is the part institutions most often want fixed. A session needs a room with adequate capacity and the right facilities, a member of staff who is qualified and available, a time that does not clash for any enrolled student, and often equipment or laboratory access. We model those constraints explicitly and surface conflicts at the point of scheduling rather than in week one, support both centrally planned and departmentally devolved timetabling since institutions differ, and handle room changes and cancellations with visible knock-on effects and notification. Full automated optimisation is achievable but should follow a trusted manual process, not precede it.
How are fees, finance, and funding handled?
This varies more by market and institution type than any other module, so we build against your actual arrangements rather than a generic model. That can include tuition schedules by programme and cohort, instalment plans, scholarships and bursaries, government or sponsor funding with its own reporting obligations, third-party invoicing where an employer or agency pays, refunds on withdrawal calculated against a published policy, and outstanding-balance consequences for registration or results release. The design essential is that charges arise from registration events rather than being re-keyed by finance staff, and that the SIS and the finance system agree at period end.
What about attendance and statutory reporting?
Attendance is operationally mundane and often legally significant, particularly for institutions with international students, funded programmes, or compulsory-age learners, where under-attendance carries reporting duties. We build capture that works in the room and in seconds, whether by register, card, or self-check, with exception handling for authorised absence and correction. Statutory returns are then produced from operational data rather than compiled manually each cycle, and we build them to your jurisdiction's specific submission requirements. We do not claim accreditation with any education regulator; we build to the return specifications you are obliged to meet.
How do you migrate historical student data?
Carefully, and usually more slowly than clients expect, because student data is legally consequential decades after the student leaves. Migration involves reconciling identity where the same person appears multiple times across years, mapping historical qualifications and grading schemes that have since changed, preserving the regulations under which each award was made, and validating that a sample of reissued transcripts matches the originals exactly. We keep the legacy system readable until nothing outstanding depends on it, and we reconcile by count and by value rather than declaring success on a completed import.
How long does an SIS project take?
Longer than most education software, because the scope crosses admissions, academic records, timetabling, finance, and reporting, each with institutional policy embedded in it. A first release covering a defined set of functions, typically admissions and registration or records and transcripts, is usually six to twelve months including discovery, integration, migration, and validation. Full coverage is a multi-phase programme. We sequence function by function rather than attempting a single institution-wide launch, because a simultaneous cutover across an institution carries risk that is difficult to justify against a term calendar.
How do you handle student data, security, and retention?
Student records contain identity, financial, and often health and disability information, held for long retention periods, frequently concerning minors. We build role-based access reflecting that a registry clerk, a tutor, and a finance officer need very different views, complete audit logging of record access, encryption in transit and at rest, defined retention and disposal schedules per record class, and subject access and correction mechanics. Our information security management is certified to ISO 27001:2013 and quality management to ISO 9001:2015. We do not describe ourselves as a FERPA or GDPR certified vendor, because no such certification exists for software suppliers; those obligations rest with the institution and we build so you can meet and evidence them.
