How to Choose School Management Software in India

Buying school management software in India is unusually hard for a category this mature. There are hundreds of vendors, feature lists are near-identical on paper, and the differences that matter — whether it is really one database, what happens at renewal, who does the migration — are the ones demos are designed not to surface.

This is a guide to the questions that actually separate one system from another, written by a team that sells one. Read it with that in mind; every point below is checkable against any vendor, including us.

First, decide what you are replacing

Institutions usually describe the problem as needing software. It is more useful to write down the specific artefacts you want to stop maintaining. A typical list looks like this:

• The attendance registers, and the monthly summary someone types up from them
• The fee ledger, and the reconciliation against bank settlements
• The mark sheets, and the report card mail-merge
• The parent WhatsApp groups, and whoever owns the phone number they run on
• The admission enquiry notebook at the front desk
• The three spreadsheets that exist only to join the others together

This list is your requirement document. It is far more useful than a feature checklist, because it is specific to your institution and because you can test any demo against it directly: show me this artefact disappearing.

How do I know if it is really one database?

Many products in this category are several applications behind a single login, joined by nightly syncs. They demonstrate beautifully module by module and fail the moment you ask a question that spans two of them.

There is a simple test. Ask the vendor to produce, live in the demo, a report of students who have both an attendance shortfall and a pending fee balance. In an integrated system this is a filter. In a stitched one you will get an explanation.

If a vendor cannot join attendance to fees in front of you, your staff will be joining them by hand for the next five years.

A second version of the same test: change a student's section, then check whether the timetable, the attendance register, the gradebook and the fee structure all reflect it without a second edit.

What does school management software cost in India?

Per-student-per-month pricing is the norm, which makes headline comparison easy and total-cost comparison misleading. Four costs routinely appear after signature.

1. 1Per-message communication charges. If SMS or push notifications are metered, a school sending daily absence alerts to a thousand families will find messaging costs rivalling the licence.
2. 2Integration and middleware. Every gap in coverage becomes a connector someone has to build and maintain.
3. 3Setup and data migration, often quoted separately and often the largest first-year line.
4. 4Support tiers. Check whether the response commitment you were shown in the demo is the one included at your price point.

For reference, CampusTrue starts from ten rupees per student per month on a minimum of one hundred students, exclusive of GST, with messaging included rather than metered. The point of stating it is not the number — it is that you should be able to get an equivalently specific answer from every vendor on your shortlist before the demo, not after it.

Data ownership and exit

This is the question most likely to be skipped and most expensive to get wrong. You are handing a vendor the academic and financial record of every student in the institution.

• Can you export the complete dataset yourself, without raising a ticket?
• In what format — a usable structured export, or a PDF dump that cannot be imported anywhere?
• How long do you retain access after cancellation?
• Is there a notice period, and what does it cost to leave mid-session?

A vendor confident in the product answers these plainly and puts the answers in the contract. CampusTrue's terms specify thirty days' notice and ninety days of data export access afterwards; whatever the numbers are for the vendor you choose, they should be written down somewhere you can point at.

Availability, stated properly

Almost every vendor site claims 99.9% uptime. Very few state what it is measured against, what is excluded, or what happens when it is missed. Those three details are the difference between a commitment and a decoration.

Ask for the measurement window, the exclusions and the remedy. A commitment reads something like: measured monthly, excluding announced maintenance, with service credits for shortfalls — and it lives in the terms of service, not on a marketing page. If the figure appears only in a badge on the homepage, treat it as a badge.

Does school software need to be GDPR or DPDP compliant?

A surprising number of vendors selling to Indian institutions advertise GDPR compliance. GDPR is European law. If your students are in India, the regime that governs their data is the Digital Personal Data Protection Act, 2023.

This is worth checking not because GDPR compliance is bad, but because a vendor advertising the wrong jurisdiction has probably copied the claim rather than done the work. Ask instead how consent is captured for minors, what the retention policy is, where the data is hosted, and who inside the vendor can read a student record.

Mobile access, and who actually gets it

Mobile is where most of the daily use happens — teachers marking registers, parents checking fees — so it deserves more than a yes or no.

• Which roles get an app? Student and parent only, or staff too?
• Is it a real application or a mobile-sized wrapper around the web interface?
• Are notifications included, or is push a paid add-on?
• How are accounts provisioned, and can anyone self-register?

On the last point: self-registration is a red flag for this category. Accounts should come from the institution's own records, because that is what prevents a parent from ever seeing another family's child.

The migration is the project

More implementations fail on migration than on features. The software is usually fine; the institution discovers halfway through that nobody had written down how fee concessions are actually decided, or that the student list exists in four inconsistent versions.

Plan for it explicitly. A workable sequence for an Indian academic year looks like this:

1. 1Pick a boundary — the start of a session or a term, never mid-examination
2. 2Clean the student master list first, before it is imported anywhere
3. 3Move attendance and communication first; they have the fewest dependencies and the highest visible payoff
4. 4Move fees at the start of a billing cycle, never mid-instalment
5. 5Run the old process in parallel for one full cycle, then stop deliberately rather than by drift
6. 6Train by role, not by module — a teacher does not need the fee desk walkthrough

A shortlist that survives contact with reality

Three vendors is enough. For each, insist on a demo against your own data — your class structure, your fee heads, your academic calendar — rather than the vendor's sample institution. Generic demos are designed to avoid exactly the edge cases your institution will hit in week two.

Then ask each of them the same six questions: one database or several, what the total first-year cost is including messaging and setup, how you export your data, what the uptime commitment and its remedy are, which regulation they are built around, and who does the migration. Compare the answers, not the feature grids.

The vendor that answers all six plainly is usually the right one, almost independently of which has more features. Features are easy to add later. A vendor that cannot tell you how you would leave is a different kind of problem.