School ERP demos all look the same. Every vendor shows you a dashboard with attendance charts and a fee-collection graph. None of that tells you whether the system will survive an admission season or a board-exam result upload.
These are the questions that separate software a school will still be using in five years from software the office quietly abandons by year two.
Start with the modules that earn their keep
Almost every school ERP offers twenty modules. Four of them carry the value; the rest are usually nice-to-have.
| Module | Why it matters |
|---|---|
| Fees and accounting | The single highest-value automation. Receipts, dues tracking, concessions, online payment reconciliation. |
| Admissions | Peak-load workflow. If it breaks in March, nothing else matters. |
| Attendance | Daily use by every teacher. Determines whether staff adopt the system at all. |
| Examination and results | Grade entry, weighted computation, report card generation, board-format exports. |
If those four are excellent and the rest are average, you have a good system. If those four are average and there are sixteen other modules, you have a demo.
The questions vendors do not want on the agenda
1. What happens on results day?
Every parent logs in within the same hour. Ask specifically what concurrent load the system has handled in production, not what it theoretically supports. A system that is fine at 50 users and collapses at 2,000 is a system that fails on exactly the day it matters most.
2. Who owns our data, and how do we get it out?
Ask for a full export in a documented format before you sign, not after you want to leave. If the answer is "we will provide a dump on request", clarify the format, the cost and the turnaround. Student records are not something you want held hostage.
3. How does fee reconciliation actually work?
Online payments fail, get duplicated and arrive at the gateway but not the ledger. Ask to see the reconciliation screen, the failed-transaction workflow and the refund path. This is where accounts staff spend their time and where most systems are weakest.
4. What does the parent see?
Parent adoption determines perceived value. Look at the mobile experience specifically — notifications for fees and attendance, and whether it works on a mid-range Android phone on 4G, because that is the real device.
5. What is included in support, and what is billable?
Session rollover, new report card formats, board-format changes and a new fee structure are annual realities, not exceptions. Get in writing which of those are included.
Data migration is the phase that goes wrong
Schools arrive with years of records spread across Excel sheets, a previous ERP and paper. Migration is where implementations slip, every time. Insist on:
- A trial migration into a staging environment, with your real data, before go-live.
- Reconciliation reports — student counts per class, total outstanding fees — that you verify against your own figures.
- A parallel run of at least one fee cycle before switching off the old system.
- An agreed position on historical depth. Migrating ten years of transaction detail is often unnecessary; migrating current students, balances and last year's results usually is not.
A vendor who says migration will take two days has not seen your data. One who asks for your files before quoting has done this before.
Integration, not one giant system
A single vendor covering everything sounds simpler and rarely is. Most schools end up with a small set of connected systems, and the connections are what matter:
- School ERP for administration, fees and staff
- Student Information System for the academic record
- LMS for coursework and digital content
- Online exam system for assessments
Ask how these exchange data. "We have an API" is not an answer; ask which specific records sync, in which direction, and how conflicts resolve. Double data entry between two systems is how schools end up back on Excel.
Product, or custom build?
A configurable product is the right starting point for most single schools and small groups — you get proven workflows immediately and configure around them. A custom build becomes worth considering when you are running a multi-campus group with genuinely unusual academic structures, or when you need deep integration with systems a product will never support. That is a conventional ERP development project, and the same phased approach applies as in any ERP decision.
A shortlist checklist
- Demo with your own data, not the vendor's sample school.
- Ask for two reference schools of similar size, and call them.
- Confirm peak-load behaviour on results and admission days.
- Get data export terms in the contract.
- Agree the migration plan and parallel run before signing.
- Clarify what annual support covers.
- Test the parent app on a mid-range Android phone.
We build education software for schools, colleges and coaching institutes — see the School Management System, or browse all our products. Tell us about your institution and we will show you a demo using your own data rather than ours.