Migrating to a New School ERP: The Three Numbers That Decide Whether It Worked

Most school software rollouts that fail do not fail because the software was bad. They fail because the school ERP migration was done quickly, checked afterwards, and never quite trusted again. Once the office believes the outstanding figure is wrong, they keep the old spreadsheet running "just to be sure" — and at that point you are paying for two systems and getting the benefit of neither.

This guide sets out the sequence that avoids that, the three numbers that decide whether the migration worked, and the four data problems every school discovers about itself along the way.

The three numbers

Everything in this guide reduces to this. Before anything goes live, three figures must match your own records:

1. Student count, per class. Not the school total — per class. A total can be right while two classes are wrong in opposite directions.
2. Total outstanding fees. As at a stated date, to the rupee.
3. Opening ledger balance. Cash, bank and the receivable, as at the same date.

If those three reconcile, the rest of the import can be trusted, because everything else hangs off the same records. If any one of them is out, stop and find out why before go-live. The discrepancy is always real and it is always cheaper to resolve now.

Ask any vendor, in the evaluation, which figures they will reconcile with you and when. "Our team handles migration" is not an answer.

The sequence that works

Step 1 — Export whatever you have, in whatever shape it is in

Do not clean it first. This is the single most common piece of wasted effort in a migration: schools spend three weeks tidying a spreadsheet before sending it, using rules the new system does not share, and the tidying has to be partly undone.

Send it as it is. An Excel per class is the usual form. A Tally export for the ledger. A printout is workable if that is genuinely all there is. Any competent vendor would rather see the mess and map it than receive something pre-processed by somebody guessing at the target schema.

Step 2 — Import onto a copy, never into the live system

The import goes into a copy of your workspace that nobody is using. This matters because the first import is always partly wrong, and the second one is much better for having seen the first. On a copy you can discard and repeat; on a live system you are now doing data repair with staff watching.

Step 3 — Reconcile the three numbers

The vendor shows you the figures. You check them against your own records — the register, the fee book, the trial balance. This meeting takes twenty minutes if the import went well and is the most valuable twenty minutes in the whole project if it did not.

Step 4 — Staff only, for a week

Go live for staff and nobody else. Teachers mark attendance; the office takes fees. That week finds the two classes whose list was wrong, the fee head somebody mis-assigned, and the three teachers who need a second walkthrough.

All of those are ordinary. All of them are considerably less ordinary once four hundred parents can see them.

Step 5 — Parents last, one class first

Release to a single class whose parents will tell you honestly what confused them. Give it a week. Fix the wording — it is almost always wording rather than software. Then go wide.

Doing this in the opposite order is the single most reliable way to give a good system a bad reputation in a WhatsApp group before it has had a chance to work, and that reputation is much harder to repair than any of the underlying problems were.

What to migrate, and what to leave behind

The general rule: migrate what you need to operate, keep the old system read-only for what you need to look up. A transfer certificate from four years ago can be produced from an archived copy; it does not need to be in the new database.

The four problems every school discovers

These are not criticisms. Every school has some of them, and finding them is a benefit of migrating rather than a cost.

Duplicate students. Siblings entered twice, a child re-admitted after a gap, a name spelled two ways. The reconciliation catches these because the class count comes out one too high.

Outstanding that does not tie to the ledger. The fee register says one thing and the accounts say another, usually because a concession was recorded as a smaller invoice rather than as a reversal, or a bounced cheque was deleted rather than reversed. Resolving it is genuine accounting work and it is worth doing once, properly.

A fee structure that was never written down consistently. Three classes have an arrangement somebody remembers. This surfaces the moment structures have to be defined explicitly, and it is usually an hour of decisions rather than a problem — but it is an hour far better spent before go-live than in November.

Stale parent phone numbers. Discovered when the first absence alert campaign returns a delivery rate well under 90%. Worth a data-collection drive at the start rather than after parents start complaining they were not informed. If your delivery rate is near zero rather than merely low, read why SMS fails silently in India — that is a different problem.

When to switch

Best: the gap between academic sessions. Clean balances, no marks in flight, staff have time.

Good: the start of a term, or immediately after a fee instalment date when balances are cleanest.

Workable: mid-session, bringing current balances and starting clean from the current term. Most schools that call us are in this position, and it is fine.

Avoid: admission season. The office has no spare attention, and the enquiry pipeline is the worst thing to be rebuilding while it is running.

Should you run both systems in parallel?

For one module, for a few weeks, yes — accounting is the usual candidate, and it buys confidence cheaply.

Across the whole system, no. Parallel running doubles data entry, and the moment the office is busy, one of the two stops being updated. You then have two systems that disagree and no way to know which is right, which is worse than either alone. Pick a cut-over date, reconcile properly before it, and commit.

Questions to ask before you sign

1. Is migration included in the price, or quoted separately?
2. Which three figures will you reconcile with us, and at what point?
3. Will the import be done on a copy first?
4. What formats can you accept — and what will you do with a printout?
5. If the outstanding does not reconcile, what happens next?
6. Can we export everything ourselves afterwards, in open formats, at any time?

That last one is about the next migration, which is exactly when it will matter and exactly when nobody thinks to ask.

For what changes week by week after go-live, see the worked rollout scenarios. For the evaluation that comes before all of this, see how to choose school management software.