Two very different projects get called the same thing. A school replacing one ERP with another is migrating data between systems. A school adopting an ERP for the first time is capturing data that has never existed in digital form — and that is a larger, slower and more manual undertaking.
Most Indian schools we work with are the second case. Their records are in hard-copy registers, and the honest answer to "how long will this take" depends almost entirely on how that data gets into the system.
Starting from paper
There is no import. Somebody has to type it, and the only real decisions are who, and how much.
Ask for the minimum, not the complete record
The instinct is to capture everything the school holds on each student. Resist it. A complete student record has dozens of fields, most of which nobody will use in the first year, and asking a school office to key all of them from registers is how a project stalls before go-live.
We send an Excel template with only the fields required to make fees and admissions work. The school fills that in — it is a shape the office already understands, and several people can work on it in parallel.
Everything else waits.
Let students and parents complete their own records
Once the minimum set is loaded, students can log into their own panel and fill in the rest — addresses, contact details, the fields the office would otherwise have typed from a register.
This works better than it sounds, for two reasons. The workload moves off the office entirely, which is what was blocking the project. And the data is more accurate, because the person entering a phone number is the person who knows it — where a clerk copying from a register introduces errors that surface months later as an SMS to a dead number.
Expect data cleaning to be part of it
Registers contain duplicate admission numbers from a year someone restarted the counter, siblings recorded under different parent entries, and names that differ between the admission register and the exam sheet. None of this is visible until it is in a spreadsheet and sorted.
Fix it in the spreadsheet, before import. Correcting it afterwards means correcting it in a live system that people are already using.
Migrating from an existing system
A different problem: the data exists, but it has to arrive complete and reconciled. The default advice is to move at the start of the academic session, and that advice is good and often impossible — the decision gets made in August, and waiting until April means eight months of running the old system badly.
Mid-session works. It has to be sequenced differently.
Decide the cutover boundary first
Not the date — the boundary. Almost always it should be a fee instalment boundary rather than a calendar date. Collect one full instalment in the old system, close it, reconcile it, and start the next instalment in the new one.
Cutting over mid-instalment means part-paid students exist in both systems, and every receipt afterwards needs a human to decide which balance is true. That single decision causes more pain than everything else combined.
What has to come across, in order of difficulty
| Data | Difficulty | The catch |
|---|---|---|
| Student master | Moderate | Duplicate admission numbers, siblings under separate parent records |
| Fee structure | High | Concessions and exceptions that live in the accountant's head |
| Outstanding arrears | High | Must reconcile to the rupee against the old system on cutover day |
| Staff and payroll | Moderate | Can usually wait for the next module |
| Historic receipts | Low | Often better left in the old system, read-only |
| Attendance history | Low | Rarely worth migrating mid-session |
Resist the urge to bring everything. Historic receipts and attendance are the bulk of the data and the least used. Keeping the old system available read-only for a year is cheaper and safer than migrating records nobody will open.
The arrears reconciliation is non-negotiable
On cutover day, total outstanding in the new system must equal total outstanding in the old, student by student. Not approximately — exactly. If it does not, find the difference before going live, because after go-live every mismatch becomes an argument with a parent holding a receipt.
Budget a full day for this with the accountant present. It is the single highest-value day in the project.
Run parallel for one cycle, then stop properly
One instalment collected in both systems and reconciled, then the old system goes read-only on a stated date. Parallel running that drifts on indefinitely is worse than not doing it: staff use whichever is convenient, and neither is trustworthy.
Announce the date the old system stops accepting entries, and enforce it.
Parent app onboarding needs an event
A circular will get you low adoption. What works is a fixed moment where someone helps: a PTM with a desk, or class teachers walking through it in the first ten minutes of a period, with a follow-up list of families who did not complete it.
Lead with whatever parents actually want. Usually the fee receipt and the exam result — not the notice board.
What to leave until the session boundary
Promotion and roll number regeneration should happen in the new system at the natural year end, not as part of the migration. Trying to do both at once means debugging a rollover in a system nobody is fluent in yet.
Worth being precise about which boundary, because it is not April everywhere. CBSE schools start in April, Maharashtra in June, Kashmir in September. The rollover has to be timed to your board's session, and a vendor who has only implemented for one board may not have had to think about that.
How long staff take to settle
Between seven and thirty days, in our experience, and the software being easy makes less difference than people expect. The variable is habit, not complexity.
A clerk who has issued receipts from a register for eleven years is not slow because the screen is confusing. They are slow because the sequence is unfamiliar, and under a queue they revert to what they know. That resolves with repetition, and it resolves faster for the people using the system every day than for those touching it weekly.
Plan for it rather than being surprised by it. Expect the first fortnight to be slower than the paper process it replaced, and do not schedule the go-live against a deadline that assumes otherwise.
Support has to match school hours, not office hours
Schools open at 7am. Most software companies open at 10.
That gap covers the busiest three hours of a school's day — the morning fee counter, the admission enquiries, the attendance marking — and it is precisely when a school new to a system needs someone to answer. A problem at 7:15am that gets a reply at 10:30 is a problem that ruined a morning.
We are available from 7am during school hours for the first few months after go-live, because that is when the questions actually arise. It is not a complicated commitment. It is just one nobody makes, and for a school that has never run software before, it is the difference between the system being adopted and quietly abandoned.
Worth asking any vendor directly: what time do you answer the phone?
All of this is done remotely
Worth stating plainly, because it is the part prospective schools find hardest to believe: we have never met most of our school clients in person.
Three of them, to be specific about the spread:
- Naval Academy, Kushinagar, Uttar Pradesh
- Glitters Kids, Anishabad, Patna, Bihar
- Jonaki Jatio Bidyalaya, Borokalia Nashkara, Dhubri, Assam — running for the last eight years
Three states, and not one site visit. We talked, the data went in, the schools started using it. The Assam school has been running for eight years on a system nobody from our team has ever seen in person.
That is not a claim about how good the software is. It is a claim about the method. The Excel template works because the office already understands spreadsheets. Students completing their own records works because it needs no supervision. And answering the phone at 7am works because a question answered in five minutes does not require anyone to be in the room.
The practical consequence for a school outside a metro: distance is not a reason to choose a worse vendor. A school in Dhubri has the same access to support as one in Patna, and neither is paying for travel time.
Expect configuration, because every school is different
India is not a single market and schools are not a single template. Almost every implementation involves changing something, and fees are where it concentrates.
A real example of the kind of rule that has to be modelled rather than worked around: a school offering a concession to a second child where an older sibling is already admitted — which means the system has to know that two students share a parent, know which was admitted first, and apply the discount to the right one automatically. Nobody wants that decided by a clerk remembering.
Beyond siblings, we routinely configure different fee structures for different categories of student within the same school. That is normal, not exceptional, and a system that cannot express it produces a set of students billed manually — which is exactly where reconciliation breaks.
When evaluating, bring your most awkward fee rule to the demo and ask for it to be built in front of you. A vendor who has implemented for schools like yours will do it. One who says it can be customised is describing a development request you will pay for later.
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
