Evaluation framework
How to Choose a School Management System in 2026: A Buyer's Guide for Indian Schools
Every school ERP demo looks good. Every brochure checks every box. This guide is the framework we wish every school had before talking to any vendor — including us. Use it against SquareCampus too; if a vendor can't survive its own buying guide, that tells you something.
Start with the institution, not the feature list
Feature-matrix shopping is how most school ERP evaluations begin, and it is why most of them fail. Every serious vendor in India will show you admissions, fees, attendance, exams, transport, and a parent app. If your comparison spreadsheet has fifty feature rows, expect every vendor to tick all fifty. The matrix cannot separate them, because features are not where these products differ.
Where they differ is structure: whether the modules share one record of each student or sync copies between databases, whether permissions model how a real institution delegates authority, whether the vendor can migrate your existing data without losing a term, and whether anyone will put infrastructure answers in writing. Those differences decide what your staff's daily life looks like in year two — long after the demo is forgotten.
So before any demo, write down your institution's actual operating problems. Not 'we need a fee module' but 'reconciling fees across our three campuses takes our accountant four days every month'. Specific problems make demos falsifiable. Generic requirements make every demo look like a win.
The five questions that actually separate vendors
If you ask only five things in an evaluation, ask these — and require the answers in writing, because written answers survive procurement, audits, and vendor account-manager changes.
- Is it one data model or stitched modules? Ask: 'When an admission is confirmed, what updates automatically — and what needs re-entry or a sync job?' Re-entry and sync jobs are where data drift is born.
- How does the permission model map to our structure? A trust with campuses, principals, department heads, and shared finance staff needs scoped, hierarchical access — not three flat roles named admin, teacher, and parent.
- What is the migration and rollout process, exactly? Who cleans the data, what runs in parallel, what is the rollback plan, and who owns the timeline? 'We'll handle it' is not a process.
- Where does our data physically live, and what happens if we leave? Region and provider in writing, export formats in writing, deletion policy in writing.
- What does the price include, and what triggers a new invoice? Per-module pricing, per-user pricing, and 'the parent app is an add-on' are the three most common sources of year-two budget surprises.
Red flags worth treating as disqualifying
Some patterns show up so reliably before bad outcomes that procurement teams should treat them as disqualifying rather than negotiable.
- Self-declared rankings and adoption counts with no evidence. Ask for the source; watch what happens.
- Uptime or reliability promises that do not appear in the contract. A number a vendor won't sign is a decoration, not a commitment.
- Refusal to answer infrastructure questions in writing — 'it's secure, trust us' is an answer about their sales process, not their security.
- A demo that cannot deviate from the script. Ask them to run one of your real workflows live; polished rails around a fixed path usually mean the product is thin off the path.
- No named implementation owner. If rollout is 'the support team', your go-live is a ticket queue.
- Exit friction: no export commitment, no deletion commitment, or contracts that make leaving expensive. Vendors confident in their product make leaving easy.
The 25-question evaluation checklist
Take this into every vendor conversation. Score each answer: in writing, verbal only, or refused. The pattern across vendors will be more informative than any single answer.
- Data & migration — 1. What historical data can you migrate, and what will be lost? 2. Who maps our current data structure to yours? 3. Is there a parallel run before cutover? 4. What is the rollback plan if go-live fails? 5. Can we export everything, in standard formats, at any time?
- Governance & access — 6. Can policy be set at trust level with campus-level execution? 7. Can access be scoped by campus, department, and workflow? 8. Is every change attributable to a user with a timestamp? 9. Can we see an audit trail for any record, on demand? 10. How are staff departures and role changes handled?
- Finance & compliance — 11. Can it model our actual fee structures: terms, concessions, transport slabs, arrears? 12. How does reconciliation work across campuses and payment channels? 13. Are receipts and approvals audit-ready without manual assembly? 14. What GST and statutory reporting does it produce? 15. How does it support our obligations under Indian data protection law?
- Communication & daily use — 16. How do parents receive updates, in which languages? 17. Can communication be tied to context — class, fee status, incident? 18. What does a teacher's daily attendance-and-marks flow actually look like? 19. What happens during exam weeks and admission season, when load spikes? 20. What training do staff get, and for how long?
- Infrastructure & commercials — 21. Which cloud region and provider host our data, in writing? 22. What is the backup and recovery design, in writing? 23. What exactly does the quoted price include, and what costs extra? 24. What does support look like after go-live — named person or ticket queue? 25. If we leave in three years, what do you commit to, in writing?
How to run the evaluation
Shortlist three vendors at most — evaluation quality drops fast beyond that. Send the checklist before demos and require written answers; a vendor's handling of the questionnaire is a preview of their handling of your rollout.
Then run scripted demos on your workflows, not theirs: bring a real (anonymised) fee structure, a real timetable problem, a real multi-campus reporting need, and ask each vendor to walk through the same three scenarios. Comparable demos beat impressive ones.
Finally, insist on a parallel run for at least one critical workflow — usually fees or attendance — before full cutover. The vendors who welcome parallel runs are the ones whose products survive them.
Where SquareCampus fits — and where it may not
SquareCampus is built as one governed system of record for Indian schools and school groups: a unified institutional data model, trust-level governance with campus-level autonomy, guided migration with parallel runs, and infrastructure questions answered in writing as part of every evaluation. Pricing is headcount-based with all modules and mobile apps included.
We are not the right fit for everyone. If your priority is classroom content and LMS depth rather than institutional operations, or you want open-source software your own IT team hosts and modifies, other vendors serve those needs better — our comparison pages say so by name. We would rather lose an evaluation honestly than win it with a checkbox matrix.
Whoever you evaluate, use the checklist. It will make every vendor — including us — earn the decision.
Run this checklist against us
Book a demo and bring the 25 questions. We answer all of them in writing — it is how we think evaluations should work.