Changing school software becomes difficult when the old system holds years of admissions, concessions and corrections that nobody has documented. Exporting a spreadsheet is the beginning of migration. The real task is preserving the meaning of each record so staff can trust the new system on the first working day.
Inventory records and name their owners
Ask admissions, accounts, examinations and administration to list the records they maintain. Include paper registers, spreadsheets and data in separate apps. For each source, identify the owner, the date it was last checked and the report used to verify it. This prevents two departments from supplying competing versions of the same student list.
- Student and guardian records, including withdrawn students and sibling relationships.
- Academic years, classes, sections, subjects and enrolment changes.
- Fee demands, receipts, concessions, refunds and opening balances.
- Attendance and results history that the school needs to retain and retrieve.
- Staff roles, permissions and approved communication details.
Resolve identifiers before importing
Names are not reliable identifiers. Two students can have the same name, and a spelling correction should not create a new account. Use a stable admission or student ID and document how it maps to identifiers in the old system. Keep an exception list for duplicates that need a human decision.
OneRoster provides a standard approach to exchanging education records such as roster information between systems. It is useful background when discussing data portability. Whether your migration uses a standard interface, an API or a spreadsheet depends on the source system and the agreed Academica implementation.
Create a field map the school can review
| Source field | Decision needed | Validation |
|---|---|---|
| Admission number | Preserve as a stable identifier | No unexpected duplicates |
| Class name | Map old labels to year and section | Class totals agree |
| Outstanding fees | Import balance or full transaction history | Accounts signs off totals |
| Guardian mobile | Normalise country codes and ownership | Sample access checks |
Keep the mapping document beside the import files. If the old system stores a result as text but the new system needs separate marks and grades, record the transformation explicitly. Unclear fields should remain unresolved until the responsible school employee explains them.
Run a representative trial migration
Choose a sample that includes a new admission, a withdrawn student, siblings, a concession, an unpaid balance and a corrected result. Easy records alone do not test the difficult rules. Compare the imported data with original receipts and reports, and retain a written list of discrepancies.
For an illustrative test, accounts might verify that a student's original demand minus approved receipts and adjustments equals the new opening balance. The exact calculation depends on the school's accounting policy. Test totals by class and fee head as well as individual records; matching a grand total can hide offsetting mistakes.
Agree a cutover and recovery plan
Set a final editing deadline for the old system and decide how transactions arriving during migration will be handled. Take a restorable backup, record the final export version and keep a read-only reference where appropriate. Define who can stop the launch if reconciliation fails.
A rollback must account for records created after the switch. Simply reopening the old application can lose new receipts or attendance. Agree how changes will be replayed or reconciled, and rehearse the process before the live cutover. The permitted interruption should be a school decision recorded in the plan.
Train people on their actual responsibilities
Admissions staff should practice correcting a guardian record; accounts should practice a concession and refund; teachers should practice attendance corrections. Give each role a short operating guide and a named support contact. Track unresolved issues through the first fee cycle and results cycle that use the new system.
Scope migration with Techimpace
Techimpace can help plan Academica ERP around your source records, board configuration and operational priorities. Share sample exports with personal data removed first. Ask for a proposal that separates data cleanup, imports, historical access, staff training and post-launch support so the school knows what completion means.
Frequently asked questions
Should we migrate every year of school data?
Decide which history must remain operational and which can be retained in a controlled archive. Confirm retention needs and retrieval requirements with the school before limiting the migration.
Can a school migrate ERP software during a term?
It may be possible with a scoped pilot, a controlled editing cutoff and a reconciled final import. The timing depends on exams, fee cycles, data quality and staff availability.
What should we send Techimpace for a migration estimate?
Send the old system name, approximate record counts, required history, sample export formats and important reports. Remove personal information from initial samples.
