School ERP Migration Checklist (Nepal)

If you’re running a school in Nepal on an aging ERP — the one with the timeout-prone fee module, the parent portal nobody logs into, and the report you have to email the vendor to regenerate — you’ve probably been told a migration “takes a year.” It doesn’t have to. A disciplined School ERP migration takes 10–14 weeks if you do the boring work upfront. This is the checklist we run with every school we move.

Before you pick a new vendor

1. Audit what you actually have

Most schools underestimate their current data surface by 40%. Before you talk to a single new vendor, write down:

Every student table and how many rows it has.
Every fee structure, scholarship rule, and discount type currently in use.
Every report someone runs more than once a month — and who runs it.
Every integration: SMS gateway, biometric attendance, payment gateway, government reporting (NEB, SEE, EMIS).
Every workflow that goes through email or WhatsApp because the ERP can’t do it.

This is unglamorous, but it’s the document the entire migration runs against. We’ve never seen a school overstate this list. We’ve seen many understate it and find out at week 8.

2. Decide what is data, what is policy, and what is custom code

A migration is not a like-for-like clone. Three categories of “stuff” need different treatment:

Data — student records, fee history, exam results, attendance. Must migrate.
Policy — scholarship rules, fine structures, exam grading formulas. Must be re-encoded in the new system. If your current ERP has these in code, you’ll have to rewrite them.
Custom code — vendor-specific quirks, school-specific scripts, undocumented workflows. Audit, then decide: keep, replace, or kill.

Most school migrations fail because policy and custom code get treated as data. They aren’t.

3. Lock the data ownership question in writing

The single contractual term that matters most in a new School ERP deal: can you take your data out without paying us, asking us, or waiting on us? If the answer isn’t “yes, daily, in an open format,” renegotiate or walk. Data Platforms thinking applies here — ERPs are data platforms with workflows on top, and any vendor that gates your data is selling you a hostage situation.

The 12-step migration

4. Build a parallel environment, not a replacement

Cutting over on a single weekend is how schools lose a term. The pattern that works: stand the new School ERP up alongside the old one. Both write to their own databases. Migrate data forward in batches. Run them in parallel for at least 4 weeks during a low-stakes period.

5. Migrate identity first

The first migration step is student identity. Every student gets a stable ID in the new system, mapped 1:1 to the old. Every subsequent migration (fees, attendance, exams) joins on this ID. If you skip this and try to migrate fees first, you’ll be reconciling student records for the rest of the project.

6. Migrate historical data in time-bounded slices

Migrate the current academic year first. Validate. Then the previous year. Validate. Then everything older. This lets you ship value early (the current year is what teachers and parents actually care about) while giving you reversible failure modes on the older data.

7. Reconcile, then reconcile again

For every migrated entity — student, fee, exam, attendance — produce a reconciliation report: count in old system, count in new system, delta. Investigate every delta. The first reconciliation will find issues. The fifth one is where you start trusting the migration.

8. Encode policies, don’t hardcode them

When the new ERP encodes your scholarship rules and fine structures, push the vendor (or your in-house team) to make them editable without code changes. A modern School ERP should let your accounts office tweak a late-fee rule without filing a ticket. If yours can’t, you’ve bought another legacy system.

9. Plan the integration cutover separately

SMS gateway, payment gateway, biometric devices, government reporting — each is its own cutover, with its own validation. Stage them. Don’t try to flip everything in the same weekend. The biometric reader at the school gate has its own clock and its own failure modes; treat it like a small migration of its own.

10. Mock the cutover before the cutover

Two weeks before the planned cutover, run a full mock: pretend it’s go-live day, walk the entire process, identify what breaks. The cost of finding a problem in the mock is “fix it in two weeks.” The cost of finding the same problem in the real cutover is “students can’t pay fees on Monday morning.”

11. Keep the old system read-only for 3 months

After cutover, don’t decommission the old ERP. Make it read-only and keep it accessible for 12–13 weeks. Two reasons: (a) auditors and parents will ask for old records and you need to be able to produce them; (b) every migration has long-tail bugs that surface only when an unusual workflow runs once a term — you need the source of truth to compare against.

12. Run the post-mortem and write the runbook

Three weeks after cutover, run a post-mortem: what slipped, what broke, what nobody warned you about. Write the runbook for the next school in your network (or for yourself, in five years). Operational Automation begins with documented operations, not magical software.

The non-obvious win

A migration is the only time you can fix the policy decisions that were baked into your last ERP. You don’t have to migrate the broken scholarship rule, the fine structure nobody understands, or the report nobody uses. Migration is your chance to rebuild the policy surface — not just the data.

Most schools waste this. They migrate every quirk forward, then complain that the new ERP “feels the same.” Don’t.

If you’re scoping a School ERP migration in Nepal — or evaluating vendors and the proposals keep saying “12 months” — we can help. Talk to us about a School ERP build in Nepal or tell us about your migration and we’ll share the actual timeline we’d run.