A few years ago I called in at a local school — around 400 students, no appointment, I happened to be passing. The office told me they had lost all their data. Their ERP had simply stopped working: the software had been blocked, and with it went admissions, fees, student records, everything they had entered over the years.
They were fortunate in one respect, although nobody felt fortunate that morning. Their ERP was an offline system, installed on a machine in their own office. The software was locked, but the data was still physically there. I was able to get it out and move it onto ours.
Change one detail and that story ends differently. Had it been a cloud system, with the records sitting on a server belonging to the vendor, there would have been nothing on the premises to recover. No amount of skill retrieves data you cannot reach. The school would have lost years of records, permanently, and the only people who could have helped were the ones who had switched it off.
That is the failure worth covering first. Most writing about school ERP concentrates on training and change management, and those matter — but they are recoverable. This one is not.
The mistake that costs everything: buying on price alone
School budgets are tight and ERP quotes vary enormously, so price does the deciding. What the cheapest quote usually does not disclose is where your data lives and who controls access to it.
The pattern that follows is consistent enough to plan against:
- The provider controls access, and can withdraw it. A commercial dispute, a missed renewal, a vendor who stops responding — and the login stops working. The school is not a party to a technical problem; it simply cannot get to its own admission records, fee ledgers and student history.
- There is no copy outside the vendor's system. If the only place your data exists is a platform you cannot log into, you do not have your data. Schools discover this at the worst possible moment, usually mid-session or during admissions.
- Cheap infrastructure carries its own risk. Low-cost providers run on low-cost servers, and what that means for backups, isolation and who can see student records is rarely spelled out. Schools hold a lot of personal data about minors — names, addresses, parent contact details, photographs, sometimes medical notes. That is not data to place somewhere nobody has asked questions about.
The damage is asymmetric. The vendor loses a customer. The school loses its records, and it is the school that has to explain that to parents and to its board.
The three questions that prevent it
Ask these before comparing prices, and treat evasive answers as answers:
- "If we are in a payment dispute with you, what happens to our access?" A vendor who will not commit to anything in writing here is telling you they intend to keep the option of switching you off.
- "How do we get a copy of our data, without asking you?" The right answer is an automatic, regular export that arrives somewhere the school controls. A copy that requires the vendor's cooperation is worth nothing in exactly the situation you need it.
- "Where do the servers sit, who has access, and what is backed up?" You are asking about the personal data of children. It is a reasonable question and a serious provider will have a straight answer.
None of this makes an expensive vendor automatically safe. It makes the question answerable, which price comparison alone does not.
Then there are the rollout failures
These are survivable, and they are why schools quietly go back to the register by August. Roughly in the order they bite.
1. Going live with every module at once
Admissions, fees, attendance, exams, transport, library, payroll — all switched on in the same week, usually in April because "the new session is a clean start". It is the opposite of a clean start. Every department is learning simultaneously, every complaint lands on the same two people, and nothing gets fixed because nothing is stable long enough to debug.
Fees first, alone, for a full cycle. It is the module with the clearest value, the fastest payback, and the smallest number of users to train. Once one collection cycle has run end to end, everyone believes the system works — and that belief is what carries the next module.
2. Importing the student master as-is
The existing data has duplicate admission numbers from a year someone reset the counter, siblings entered under different parent records, phone numbers in four formats, and names that differ between the admission register and the exam sheet.
Import that and every downstream problem traces back to it — fee receipts to the wrong sibling, SMS to a dead number, a transfer certificate that will not generate. Clean the data in a spreadsheet before import, and make the admission number genuinely unique even if it means a mapping column for the old one.
3. Underestimating the fee structure
This is the single most common reason a school ERP implementation runs long. What the school describes as "our fee structure" is usually:
- Different heads per class, changing at certain grade boundaries
- Staff-ward and sibling concessions, sometimes as a percentage, sometimes a flat amount
- Transport by distance slab or route, with a mid-year change when a family moves
- Optional heads — lab, activity, exam — that only apply to some students
- Late fee rules with a grace period, and a principal who waives them case by case
- RTE or scholarship students billed differently
Map all of it on paper first, including the exceptions the accountant handles manually today. A system that models 90% of the structure means 10% of receipts are still manual, and manual receipts are where reconciliation breaks.
4. Treating the parent app as a launch-day feature
The app gets built, a circular goes out, and three weeks later 20% of parents have installed it. Now the office is running two systems — the app for some families, phone calls for the rest.
Adoption needs a reason and a moment. The reason is usually the fee receipt or the exam result; the moment is a PTM where someone sits at a desk and installs it on parents' phones for them. A class-teacher-led push works better than a circular, because the teacher can follow up with the families who did not.
5. Buying attendance hardware before agreeing the process
Biometric devices get installed, then nobody has decided what happens when a student forgets, when the device is offline, or who marks the correction. Within a month the register is back as the source of truth and the device is decoration.
Decide the exception path first — who can edit, within what window, and whether a correction is logged. The hardware is the easy part.
6. Not testing the year-end rollover until year-end
Promotion, section reallocation, roll number regeneration, carrying forward fee arrears, archiving the outgoing batch. This runs once a year, which means it gets tested once a year — in March, under pressure, with no time to fix what breaks.
Run it on a copy in December. Whatever goes wrong will go wrong quietly, months before it matters.
7. Training the wrong people
Training usually goes to the principal and the IT coordinator. The people who actually use the system all day are the front-desk clerk and the accounts assistant, and they often learn by watching someone else guess.
Train the daily users, on their own data, doing the tasks they actually do — issue a receipt, add a mid-session admission, generate a defaulter list. One hour with the right two people is worth a day with the wrong ten.
The pattern underneath
Six of these seven are sequencing problems, not software problems. The schools where this goes well are not the ones with the best-resourced IT teams; they are the ones that put one module fully into daily use before starting the next, and that treated data cleaning as part of the project rather than something to do later.
The ones that struggle almost always tried to do everything in April.
How we handle the part that worries schools most
We built our own answers to the access question, because we have seen what happens to schools that get caught by it.
The backup goes to the school's own email, automatically. Not a copy held on our servers that we would restore for you on request — one that arrives in the school's inbox on its own, on infrastructure we do not control. If our relationship ended tomorrow, the school still has its data. That is the only version of a backup that answers the hostage problem, because it does not depend on us cooperating.
The schedule is the school's to set — hourly, daily, or whatever fits. A school collecting fees all day is not in the same position as a small pre-primary, and neither should be stuck with an interval a vendor picked for them.
How long those copies last is the part worth reading carefully. On our servers we keep the last seven and replace the oldest automatically, which is an operational window — enough to undo a bad import. The copies in the school's mailbox have no window at all. They stay until the school deletes them, and nobody else can. That is the difference between a retention policy and actually holding your own records: one is a promise from a vendor, the other is a file in your inbox.
Our servers are our own rather than resold space, and we take a daily offline copy of them as a precaution — one that is not reachable over the network, because a backup sitting online shares the fate of whatever compromises the system it is attached to.
We do not switch schools off over payment. If an invoice goes unpaid, the software keeps working. After three or four payment reminders it moves to read-only: new entries pause, and nothing else changes. Admission records, fee history, student data — all of it stays visible and exportable.
This matters because the alternative punishes the wrong people. A school in a payment dispute still has parents at the counter and admissions to process. Cutting off access does not accelerate payment; it creates an emergency for people who had nothing to do with the invoice.
Directors get a daily report by email, without asking. Collections, arrears, admissions — sent automatically. Two reasons this matters more than it sounds. Management sees the position daily rather than requesting a report and waiting. And it is a second continuous record of the school's own numbers, arriving somewhere the school controls.
Support is immediate, not ticketed into a queue. Fee collection week is when a school finds out what its vendor's support is actually worth. A problem on a collection day is not a problem that can wait until tomorrow.
About the author. Kislay Chandan has worked with schools since 2014. Rather than gathering requirements from the outside, he worked inside a school to see what actually goes wrong day to day, and built what he found into the software. He still works with Shemrock Glitters in Patna — most changes to the product start with something that came up there.
Gallery
