How to move 300 students' fee records to new software without breaking admission season

Ask a coaching institute owner why they are still on software they complain about weekly and you will usually hear something about price. Push a little and it turns out not to be price at all. It is that moving three hundred students' fee records into something new, in the middle of a running session, is a genuinely frightening thing to do — and nobody has ever explained to them what the process actually looks like.

This is that explanation. It applies whichever system you are moving to, including one that is not ours.

First: pick the right eight weeks

Timing matters more than any other decision here, and it is the one most institutes get wrong by defaulting to “as soon as possible”.

• The worst time is admission season. New students arriving daily, fees being collected hourly, and your front desk already at capacity. A migration here is how data gets lost.
• The best time is the quiet stretch after a fee cycle closes and before the next intake begins. Balances are settled, the number of students in flux is at its lowest, and staff have the attention to learn something.
• The second-best time is a batch boundary — the end of a course, when one cohort has finished and the records for it are final.

If you cannot find eight clear weeks, wait for the next window rather than compressing it. A rushed migration in October costs more than six more months on a system you dislike.

What to export, before you agree to anything

Do this before you sign with a new vendor, because it tells you whether leaving your current one is even possible.

Ask your current provider for a full export of:

• Student records — names, guardian names, phone numbers, admission dates, batch
• Fee structures per course, including any discount arrangements
• Payment history, transaction by transaction, not just current balances
• Outstanding dues per student, with instalment due dates
• Staff records and salary structures
• Attendance history, if you need it — many institutes decide they do not

Transaction-level payment history matters more than people expect. Current balances alone tell you what is owed today but nothing about what a parent paid in July, which is exactly the thing that gets disputed.

Reconcile before you import, not after

This is the step institutes skip and then regret. Whatever is wrong in your old system will be faithfully carried into the new one, and it is far easier to fix in a spreadsheet than after it has been loaded.

Go through the export and settle:

• Students who have left but were never marked inactive. Every institute has them. They inflate your student count and, worse, they will start receiving automated reminders.
• Duplicate records — the same student entered twice, usually with a slightly different spelling or a second phone number.
• Verbal discount arrangements that exist nowhere in writing. The sibling concession agreed with a parent two years ago and remembered only by you. If it is not written down before the migration, it will be wrong afterwards, and you will find out when the parent calls.
• Phone numbers that are out of date. A migration is the one natural moment to clean these, and messaging is worthless without them.

Run both systems in parallel for one week

Not one month — staff will not sustain double entry that long, and they will quietly abandon one. One week, deliberately, with everything recorded in both.

At the end of the week, check three numbers against each other:

• Total collected that week
• Total outstanding across all students
• Headcount of active students

If all three match, the import was clean and you can switch. If any of them disagree, you have found the problem while the old system is still running — which is the entire point of the exercise.

Tell parents nothing, and tell staff everything

Parents do not need to know you changed systems. They need their receipts to keep arriving and their balances to stay correct. If the migration is visible to them, something has gone wrong.

Staff are the opposite case. The person at the front desk is the one who has to make the new system work, and they usually had no say in choosing it — which is a bigger cause of failed migrations than any technical problem. That is worth its own conversation, and we have written one.

The short version

• Pick a quiet window. Never migrate during admissions.
• Get a full export first — it tests your current vendor as much as it prepares you.
• Clean the data before importing, especially inactive students and unwritten discounts.
• Run both for one week and reconcile three numbers.
• Keep the old system readable for a year.

Ask any vendor you are considering to walk you through their version of this. The ones who have actually done migrations will have opinions about timing and reconciliation. The ones who say “we'll handle it” and change the subject are telling you something too.

Related reading: why running four disconnected tools costs more than it looks, and what coaching software actually costs in India.