A new school ERP is judged on its first fee cycle.
If a parent opens the new app and sees a due they already paid, nothing else about the system matters. The office stops trusting the numbers, someone quietly reopens the old spreadsheet "just to check," and within a term the school is running two systems instead of one.
That's why migration — moving your existing records into the new system — is where most ERP projects are really won or lost. It's also the part vendors talk about least in the demo.
Here's the checklist we use. It assumes you're moving from some mix of registers, Excel files and an older system, because almost every school is.
Step 1: Find every place the data actually lives
Before anyone talks about formats, list the sources. In a typical school they look like this:
| Data | Where it usually lives | What goes wrong |
|---|---|---|
| Student records | Admission register, an old system, a class-wise Excel | The same child spelled three ways |
| Guardians | Admission forms, a phone list | Siblings entered as separate families; outdated numbers |
| Fee structures | The accountant's head and a master sheet | Concessions agreed verbally and never written down |
| Fee payments | Receipt books, bank statements, a payment gateway | Payments recorded against the wrong installment |
| Hostel allocation | The warden's register | Bed numbers that don't match the floor plan |
| Transport | The transport office's sheet | Stops and routes that changed mid-year |
| Documents | Physical files, a shared drive | No link between the file and the student record |
The table is the start of your migration plan. Every row needs an owner on your side who knows where the bodies are buried.
Step 2: Decide what moves, and what stays behind
Not everything needs to come across. A sensible default:
- Must move: every current student and guardian, current class and section, the fee structure and installment plans for this year, every open due and every payment made this year, current hostel and transport allocations.
- Should move: two to three years of history for current students — past payments, results, attendance summaries — so the office can answer questions without opening the old system.
- Can stay archived: alumni, rejected applicants and older years. Export them to a clean, read-only archive and keep them only as long as you need to. Under the DPDP Act, holding children's data forever "just in case" is no longer a harmless habit.
Write this decision down. It prevents the argument three weeks later about why 2019's transport records didn't come across.
Step 3: Clean before you move, not after
Moving messy data into a new system just gives you messy data with a nicer interface. The usual clean-up list:
- Duplicate students. Same child, different spellings, sometimes a different date of birth. Match on more than the name.
- Siblings. Two children, one family, entered as two separate guardians. Link them now, or the parent app will show one child per login.
- Guardian phone numbers. These become the login and the notification channel. A wrong number means a parent never gets the fee reminder.
- Class and section names. "VIII-A", "8A" and "Std 8 (A)" must become one thing.
- Fee heads. Map every old fee head to the new structure. Tuition, hostel, transport, admission and exam fees each need a home.
- Concessions. Every sibling discount, staff-ward concession and scholarship written down, with who approved it.
Don't aim for perfect. Aim for every record having one owner who has looked at it. And remember the spreadsheet is a spec: every odd column exists because someone needed it, which is why good systems are built from your spreadsheets rather than on top of them.
Step 4: Reconcile the fees, student by student
This is the step that decides whether the project succeeds. Before go-live, you should be able to put two numbers side by side for every student and have them match:
- Total billed this year, per the old records, against total billed in the new system.
- Total paid this year, per the old records and the bank, against total paid in the new system.
- Balance due, which must then match automatically.
Then do the same totals by class, and for the whole school. Your accountant should sign off on the final reconciliation in writing.
Where numbers don't match, don't adjust the new system to force agreement. Find out why. It's usually a payment posted against the wrong installment, a concession that was applied in practice but never recorded, or a cheque that bounced after the receipt was issued. Every one of those is a future parent dispute you've just prevented.
It's also the commitment we publish on our school ERP page: students, applications and fee history come across checked and balanced before you go live. If a vendor won't describe how they do this step, treat that as your answer.
Step 5: Pick the right week
The worst time to switch systems is when the office is busiest. Avoid:
- The weeks around a fee installment due date
- Admissions season
- Exams and result publication
The best windows are usually the summer break, or the first weeks of a term before the next installment falls due. Work backwards from that window: migration, reconciliation and training take longer than anyone budgets.
Step 6: Run both systems for one cycle
For one fee cycle, run the new system as the source of truth while keeping the old one available, read-only, for checking. Agree in advance which system wins in a disagreement — it should be the new one, once the reconciliation is signed off — and log every discrepancy you find. There should be very few. If there are many, go back to Step 4.
Keep read-only access to the old records for as long as your auditors might ask for them.
Step 7: Go-live day
A short checklist for the day itself:
- Old system set to read-only, so nobody enters new data there by habit
- Every staff member can log in with their own account and sees what their role needs
- Test one real payment end to end: link sent, payment made, receipt issued, ledger updated
- Parents told what's changing, what the new app or payment link looks like, and who to call
- Someone from the vendor on call all day, not "raise a ticket"
Step 8: The first thirty days
Migration isn't over at go-live. In the first month, expect:
- A handful of parents questioning a balance. Answer each one with the reconciliation, and fix the underlying record, not just the screen.
- Staff reverting to paper for one or two tasks. Find out why — it's usually a missing report or an awkward screen, and it's cheap to fix early.
- New requests. The office will think of things the old system never did. That's a good sign.
This is also when it becomes clear whether your vendor stays involved after launch. If every small change is a paid change request, the system will slowly drift away from how your school works — we've written about that cost before.
The short version
Find every source. Decide what moves. Clean it. Reconcile every rupee before anyone else sees it. Switch in a quiet week. Keep the old records readable. Stay close for a month.
None of it is glamorous, and none of it shows up in a demo. It's also the difference between an ERP your office trusts and one they work around.
Planning a move off registers and spreadsheets? Our free audit maps where your data lives today and what a clean migration would take. Book 30 minutes. If you'd rather see the destination first, here's the school ERP we run.