How to Migrate Student Data to New School Software Without Losing a Rupee
A field-tested migration sequence for moving students, fee ledgers, arrears and results into new school software — including the reconciliation step most projects skip.
Migration is where school software projects quietly fail. The new system works perfectly on new data and disagrees with your registers on everything historical, so staff keep both alive and the project never finishes.
This is the sequence we use. It is deliberately unglamorous.
1. Freeze a cut-off date
Pick a date — ideally the start of a fee cycle or term. Everything before it is historical and read-only. Everything after it is entered in the new system only. Without a cut-off, you migrate a moving target forever.
2. Extract before you clean
Pull raw exports of every source: the old system's database, the fee Excel files, the admission register, the result sheets. Keep the untouched originals. Every later question ("where did this arrear come from?") is answered against these.
3. Clean students first, nothing else
One student, one record. Deduplicate siblings entered twice, students re-admitted after a gap, and name spelling variants. Assign a permanent student ID that never changes, even across class, section or campus.
Do not touch fees or results until the student list is final. Every downstream record hangs off these IDs.
4. Migrate fee ledgers as transactions, not balances
The common shortcut is importing a single opening balance per student. It saves a week and costs you every future dispute, because nobody can explain how the balance arose.
Import charges, payments, discounts and arrears as dated transactions. The balance then derives itself, and any parent query is answerable in seconds. Our fee management approach is built around exactly this ledger model.
5. Reconcile against three known numbers
Before anyone trusts the system, it must match:
- Total students enrolled, per class and section.
- Total outstanding fees, per class and in total.
- Last month's collection figure.
If any of the three disagrees with your registers, stop and find out why. This step is what separates a migration from a data dump.
6. Bring results and attendance across selectively
Full historical attendance is rarely worth the effort. Final results and promotion history usually are, because transcripts and leaving certificates depend on them. Decide deliberately rather than importing everything by default.
7. Run in parallel for one cycle
One full fee cycle in both systems. It is duplicate effort for a few weeks and it is the only real proof. When the two agree at month end, switch off the old one — properly, not "just in case".
8. Keep the archive
Store the original exports and the migration mapping somewhere safe and documented. Two years later, an audit or a certificate request will need them.
What this looks like in practice
On most projects, migration is 30–40% of total effort and almost all of the risk. Budget it explicitly, and be suspicious of any quote where it appears as a single small line.
If you are moving off Excel or a legacy system, book a consultation and bring one class's worth of real data. We will show you the mapping before you commit to anything. See also our student information system work, where this record model comes from.