A school that has decided to change platform has usually already done the hard thinking. The features were compared, the demo was run, the price was checked at the size the school expects to be in three years. Then the project stalls for a year, and the reason is almost never the new product. It is that nobody can face the idea of moving two hundred students, a timetable, a term of attendance and a payment history, and nobody is sure what happens to the records if it goes wrong halfway.
That fear is reasonable, and the way through it is unglamorous: decide what genuinely has to move, accept that some of it will not, move between terms rather than during one, and keep the old system readable for a year rather than deleting it in a fit of optimism. This cluster is that sequence. It also states our own limits, because a cluster about getting data out of a platform is worthless if it goes quiet about the platform publishing it.
School data falls into six groups, and they behave very differently in a migration. People — students, parents and staff with their contact details — almost always move, because every platform can take a list of names and email addresses. Structure — courses, levels, classes and the timetable — is usually rebuilt rather than imported, because no two products model a class the same way and the rebuild is often faster than the mapping. Curriculum — your materials, assessments and lesson content — moves only if you can get it out in a usable format, which is the question that decides whether a migration is a fortnight or a summer.
The other three are the ones schools argue about. History — past attendance, past grades — very rarely moves cleanly, and usually should not: it is reference data, not operating data. Money — invoices, payments, arrears — should stay where it was raised, because the accounting record of a period belongs to the system that produced it and your accountant will thank you for not merging two ledgers. Live balances — who currently owes what — do have to move, but as a short list you carry across by hand, not as a data import.
The instinct to bring everything is what makes migrations fail. A school that insists on importing four years of attendance will spend six weeks on data that nobody has opened since it was recorded, and will still be doing it when term starts.
The single most useful thing a school can do about migration is ask the question years early, of the platform it is about to join: how do I get my data out, in what format, how quickly, and who has to run it? A vendor that answers precisely is telling you something about the whole relationship. A vendor that says "you can export your data" and changes the subject is describing a support ticket, one table, and a wait.
Do it at the evaluation stage, in writing, for every product on the shortlist including ours. It costs nothing while you are being courted and is nearly impossible to obtain later. The red flags article lists the phrasings that signal a thin answer, and the vendor questions article turns it into an email you can send.
Applying our own test to ourselves, plainly. Coming in: SprintUp imports student accounts from a CSV whose header carries a name and an email column, with an optional password column, and it can enrol every student in the file into one class as it creates them. Your plan's student limit is checked once for the whole file before a single account is created, so you are told you are over the cap at the start rather than halfway through. That is the whole of the bulk import. Courses, classes, the timetable, attendance history and payment history are not imported from another platform; you rebuild the structure, which for most small schools is an afternoon, and you leave the history where it is.
Going out: this is the limit worth knowing before you choose us rather than after. There is no self-service export for a school administrator today. A full export of everything held about one person exists and is run by us on request, not by your administrator — the same constraint described in the GDPR cluster, and it applies to leaving as much as to a subject access request. If a school wants its data out, it asks us and we produce it. Most platforms in this market work the same way and few say so on a marketing page; we would rather you knew now and asked us about turnaround than discovered it in the month you decided to leave.
One more, for completeness: invoices are kept even when a person is erased, because accounting law requires it, and no platform can honestly promise otherwise.
The instinct is a clean break over a weekend, and it is the riskiest option available. The alternative that works for small schools is a parallel term: the new platform runs a real part of the school — one level, one site, one programme — while the old one continues for everything else. You learn the product with real students and a small blast radius, and if it is wrong you have lost one group's administration rather than the school's.
Parallel running turns into chaos under exactly one condition: when the same fact is being maintained in both places. So the rule is that each kind of data has one authoritative home at any moment, written down, and everyone knows which. Attendance for the pilot group lives in the new system only. Invoices live in the old one until the cut-over date. Nothing is dual-keyed, because dual-keyed data is data that will disagree, and when it disagrees nobody will know which to believe. The second article covers how to choose the pilot and what the term genuinely costs in staff hours, which is the part that gets underestimated.
Attendance, enrolment and billing all have a natural boundary, and a migration that lands on it inherits a clean start: no half-recorded registers, no course invoiced in one system and delivered under another, no family holding a receipt the new platform has never heard of. A migration in the middle of a term has to reconcile all three, by hand, during the weeks the office is busiest.
Which means the real constraint is your calendar, not the software. Count backwards from the boundary: the export request, the structure rebuild, the student import, a fortnight of testing with staff, and the announcement to families. If that does not fit before the next boundary, go at the one after. A school that waits a term to do it properly loses nothing; a school that rushes it loses the term it was trying to save.
Get your data out of the old platform, run both for one term without letting them disagree, and cut over on a date you chose. Each article ends with a checklist.