How do I move school data to a new system?

Reference data — students, teachers, groups, subjects — normally exports to a spreadsheet and imports cleanly. Attendance history and class-pack balances rarely do; balances are best recorded by hand as of the switchover date.

What gets lost in a migration?

Attendance history, the link between individual payments and specific lessons, and class-pack balances. That is why balances should be frozen manually rather than recalculated after the fact.

When is the best time to switch?

On a period boundary — between terms, or at a month end with settlements closed. Migrating mid-month almost guarantees discrepancies in pack balances.

How long does it take?

For a small school, a few days to a couple of weeks of administrator time, depending on how much history you choose to carry. Treat the first full month as transitional.

Should I run both systems in parallel?

Partially. Run one or two real groups in both for a month and reconcile. Nobody sustains full duplication of an entire school.

What do I check before switching the old system off?

That the export is downloaded and stored by you, that pack balances match name by name, that the first month of teacher payouts reconciles, and that you keep read access to the old system for another month.

School CRM migration checklist

Export your data before you decide, not after. The export is what tells you what can actually be taken with you, and it not infrequently changes the decision. Second rule: do not migrate class-pack balances — freeze them by hand as of the switchover date. Recalculating them afterwards almost never comes out right.

Step 0. Export before deciding

Request an export from your current system before you start shortlisting new ones. Check what actually comes out:

students with contacts and dates of birth;
teachers and their subject assignments;
groups and their rosters;
payment history;
attendance history;
class-pack balances.

If the last two do not come out in a usable form, that is not a reason to stay — but it is a reason to plan differently. It is also the question to put to the new vendor before you enter anything: "how do I get my data out if I leave?"

What travels well, and what does not

Data	Travels	What to do
Students, teachers, groups	Well	Export to spreadsheet, import
Subjects, locations, rooms	Well	Usually re-entered by hand; there are few
Payment history	Fair	Carry totals, not individual operations
Class-pack balances	Badly	Record by hand as of the switch date
Attendance history	Badly	Leave in the old system as an archive
Future schedule	Fair	Faster to rebuild than to fix a broken import

Read the balances row twice. It is the one dataset where an error immediately becomes a conflict with a parent: they believe three lessons remain, the system shows one.

Step 1. Pick the date

A period boundary, month end, settlements closed. Not mid-term, and not the first week of a new intake when everything is already moving.

In practice: close the month in the old system on its last day, start the new one on the first day of the next. Anything in between is where discrepancies come from.

Step 2. Move in dependency order

Reference data: subjects, locations, rooms.
Teachers and their assignments.
Students with contacts.
Groups and rosters.
Schedule for the coming period.
Pack balances — by hand, reconciling each one.
Documents: contracts and consents.

Step 3. One parallel month

Full duplication is unsustainable and unnecessary. Run one or two real groups in both systems for a month and reconcile three things:

charges for lessons taught;
the teacher payout calculation;
pack balances at month end.

If all three match, the migration worked.

Checklist before switching the old system off

[ ] Full export downloaded and stored by you, not only in a vendor cloud
[ ] Pack balances reconciled name by name
[ ] First month of teacher payouts reconciles
[ ] Next period's schedule fully entered
[ ] Parents know where to see their lessons and balances now
[ ] Read access to the old system retained for another month
[ ] Checked where student personal data now physically lives

That last item is easy to forget: changing systems changes where your students' personal data is stored, and in some jurisdictions that matters legally.

When not to migrate at all

The current system broadly works and one small thing annoys you.
You implemented it less than two months ago — that is still the cost of learning it.
The problem is in your processes. Undocumented cancellation and expiry rules will not be fixed by new software.

About UniMe here

Two things relevant to this topic: your data stays yours, and cancelling a subscription moves the school to the free tier rather than locking it. Schools in Russia are stored in Russia, which is a data-residency requirement solved by where the server physically sits, not by a setting.

We have no automated importer from any specific competitor. Migration goes through spreadsheets and manual balance reconciliation, exactly as described above. Promising a one-click move would not be true.

Reviewed September 2026.

Migrating a school to new management software without losing data