Migration
Switching ERP without losing a fee record
Schools stay on software they dislike because changing it feels like risking the fee ledger, and that fear is reasonable: a migration that loses a payment is a conversation with a parent you cannot win. But the risk is manageable and almost entirely about sequence. This guide covers when to cut over, what to actually move, how to prove the money reconciles, and what to extract from the old system before you stop paying for it.
Get your data out first — before you decide anything
Do this at the start, not at the end. The export tells you what you actually have, and an old vendor's cooperation is never better than while you are still a paying customer.
- Request a full export in a readable format: CSV or Excel, not a proprietary backup
- Learners, staff, fee structure, the full fee ledger with every transaction, attendance, marks and documents
- Check what is MISSING from the export — that is your real migration scope
- Keep the export, untouched, as your reference copy after cutover
- If there is no export, you have learned the most important thing about your next contract
There are two safe cutover points in a year
Both are moments when the fee and academic cycles are naturally closed. Anywhere else means running two systems across an open term, which is where reconciliation errors come from.
- The academic year boundary — cleanest by far. Close the year in the old system, start the new year in the new one, and carry only balances forward.
- A term or instalment boundary — workable, if the previous instalment is fully collected and reconciled before you move.
- Mid-term is the one to avoid: an open instalment collected partly in each system is the single most common source of a lost payment.
- Admissions season is a bad time regardless of the boundary: the office has no spare capacity for a parallel run.
Migrate the current state, not the archive
The instinct is to move everything. It is the wrong instinct: historical detail is what makes a migration long, and almost none of it is needed operationally. Keep the archive as the export, and move what the office uses.
- Move: active learners and staff, the current fee structure, OUTSTANDING balances per learner, current class and section, documents still needed
- Move if cheap: the current year's attendance and marks, so this year's report cards can be produced
- Do not move: closed years, transaction-level history of settled dues, leavers beyond your retention policy
- Keep the export as the archive, and say in writing where it lives and who can read it
- A leaver whose dues are settled is an archive record, not a migration record
Prove the ledger balances before you cancel
This is the step that makes a migration safe, and it is a half-day of work. Do it before the old system is switched off, while both can still be queried.
- Total outstanding across all learners: old system against new, to the rupee
- Learner count by class: old against new
- Pick ten learners deliberately — one with a concession, one with a part payment, one mid-year joiner, one leaver with dues — and check each by hand
- Reconcile the current month's collection against the bank, in the new system
- Only then cancel, and keep the export regardless
Run the first month deliberately
The month after cutover is where adoption is won or lost. Budget attention for it rather than declaring the project finished at go-live.
- Train the clerk and the class teacher, separately, on their own tasks only
- Have one named person internally who owns questions in week one
- Run the first fee day with someone watching, not reporting afterwards
- Keep the old system readable, not writable, for one cycle
- At the end of the month, reconcile again — the second reconciliation catches what the first could not
Everything in one place
What the platform covers
Import help included
Learner, staff and fee data imported with the Classfold team rather than billed as an implementation project.
Balances, not archives
Outstanding amounts per learner carried onto one ledger, so the first fee day reconciles.
Your data stays yours
Published plans, no implementation fee, and an export you can take out again.
Questions, answered
Frequently asked questions
When is the best time to switch school ERP?
The academic year boundary, by a wide margin: the fee cycle and the academic cycle are both closed, so only balances carry forward. A term or instalment boundary works if the previous instalment is fully collected and reconciled first. Mid-term is where payments get lost.
What if the old vendor will not give us an export?
Ask in writing, referring to your contract, and escalate early rather than at cancellation. Meanwhile, extract what you can from the screens you do have — fee ledgers and learner lists first. And put the export clause in your next contract, because this is the moment it would have paid for itself.
Do we have to migrate historical fee transactions?
Usually not. What the office needs operationally is the OUTSTANDING balance per learner; settled history is an archive need, served by the export. Insisting on transaction-level history is the most common reason a two-week migration becomes a two-month one.
How long does a migration take for a 600-learner school?
The data work is days, not weeks, once the export exists and the scope is current-state only. What takes longer is the decision-making — the cutover date, what to migrate, who owns week one — which is why doing the export first is useful: it turns an open-ended question into a bounded one.
Do families need to install an app to receive this?
No. Classfold has no parent app and no parent login. Notices, fee dues, attendance alerts and results go to families over WhatsApp, SMS and email under your institute's own name, so there is nothing for them to download or remember a password for.
What does Classfold cost?
Plans are published in full and priced by learner count, starting at ₹180/month for up to 90 learners. There is no implementation fee and no quote-only tier except the custom one for very large networks. See the pricing page.